DE60220259T2 - Datenreferenzsystem - Google Patents

Datenreferenzsystem Download PDF

Info

Publication number
DE60220259T2
DE60220259T2 DE60220259T DE60220259T DE60220259T2 DE 60220259 T2 DE60220259 T2 DE 60220259T2 DE 60220259 T DE60220259 T DE 60220259T DE 60220259 T DE60220259 T DE 60220259T DE 60220259 T2 DE60220259 T2 DE 60220259T2
Authority
DE
Germany
Prior art keywords
data
transmission
file
operator
decoder
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.)
Expired - Lifetime
Application number
DE60220259T
Other languages
English (en)
Other versions
DE60220259D1 (de
Inventor
Christophe Canal+ Techn COLAS NOBLECOURT
Setra Canal+ Techn RAKOTOMAVO
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=8182660&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE60220259(T2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of DE60220259D1 publication Critical patent/DE60220259D1/de
Application granted granted Critical
Publication of DE60220259T2 publication Critical patent/DE60220259T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4782—Web browsing, e.g. WebTV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/44—Receiver circuitry for the reception of television signals according to analogue transmission standards
    • H04N5/445—Receiver circuitry for the reception of television signals according to analogue transmission standards for displaying additional information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/163—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing by receiver means only
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/165—Centralised control of user terminal ; Registering at central

Description

  • Diese Erfindung bezieht sich auf ein Datenbezugnahmesystem. Insbesondere, aber nicht ausschließlich, findet die Erfindung in einem digitalen Übertragungssystem Anwendung, wobei sich bevorzugte Beispiele der im Folgenden beschriebenen Erfindung auf ein Datenbezugnahmesystem und -verfahren und insbesondere auf eine Vorrichtung und auf ein Verfahren zum Bezugnehmen auf Daten, die zu einem Empfänger/Decodierer heruntergeladen werden sollen, und auf ein Verfahren und auf eine Vorrichtung zum Auflösen der Daten, auf die Bezug genommen wird, und auf ein Verfahren und auf eine Vorrichtung zum Vorbereiten der Daten für die Übertragung beziehen.
  • Der hier verwendete Begriff "Empfänger/Decodierer" kann einen Empfänger zum Empfangen entweder codierter oder nichtcodierter Signale, z. B. Fernseh- und/oder Rundfunksignale, die mit irgendwelchen anderen Mitteln übertragen oder gesendet werden, bedeuten. Außerdem kann der Begriff einen Decodierer zum Decodieren empfangener Signale bedeuten. Ausführungsformen solcher Empfänger/Decodierer können einen Decodierer, der einteilig mit dem Empfänger ist, um die empfangenen Signale zu decodieren, z. B. in einer "Set-Top-Box", wie etwa einen Decodierer, der in Kombination mit einem physisch getrennten Empfänger arbeitet, oder einen solchen Decodierer, der zusätzliche Funktionen enthält, wie etwa einen Web-Browser, einen Videorecorder oder ein Fernsehgerät, enthalten.
  • Das Erscheinen digitaler Übertragungssysteme, die hauptsächlich für die Übertragung von Fernsehsignalen bestimmt sind, insbesondere, aber nicht ausschließlich, von Satellitenfernsehsystemen, hat die Möglichkeit der Verwendung solcher Systeme für andere Zwecke eröffnet. Eine von diesen ist die Bereitstellung von Interaktivität beim Endnutzer. Wie er hier verwendet wird, enthält der Begriff "digitales Sendesystem" irgendein Sendesystem zum Senden oder Übertragen z. B. hauptsächlich audiovisueller Daten oder digitaler Multimediadaten. Während die vorliegende Erfindung insbesondere auf ein Übertragungs-Digitalfernsehsystem anwendbar ist, kann die Erfindung ebenfalls auf ein festes Telekommunikationsnetz für Multimedia-Internet-Anwendungen, auf eine interne Fernsehanlage usw. anwendbar sein.
  • Eine Art der Wechselwirkung mit dem Nutzer ist das Ausführen einer Anwendung in dem Empfänger/Decodierer, durch den das Fernsehsignal empfangen wird. Der Code für die Anwendung könnte dauerhaft in dem Empfänger/Decodierer gespeichert sein. Allerdings wäre dies recht einschränkend. Vorzugsweise sollte der Empfänger/Decodierer den Code für eine geforderte Anwendung herunterladen können. Auf diese Weise kann mehr Vielfalt bereitgestellt werden und können Anwendungen ohne irgendeine Aktion von Seiten des Nutzers nach Bedarf aktualisiert werden.
  • In einem MPEG-System kann Anwendungscode in MPEG-Tabellen heruntergeladen werden, die in einem MPEG-Bitstrom gesendet werden. Der Begriff MPEG bezieht sich auf die Datenübertragungsnormen, die durch die internationale Normenorganisations-Arbeitsgruppe "Motion Pictures Expert Group" entwickelt wurden, und insbesondere, aber nicht ausschließlich, auf die MPEG-2-Norm, die für Digitalfernsehanwendungen entwickelt wurde und die in den Dokumenten ISO 13818-1, ISO 13818-2, ISO 13818-3 und ISO 13818-4 dargelegt ist. Im Kontext der vorliegenden Patentanmeldung enthält der Begriff alle Varianten, Abwandlungen oder Entwicklungen von MPEG-Formaten, die auf das Gebiet der Digitaldatenübertragung anwendbar sind.
  • Die Software zum Herunterladen der MPEG-Tabellen ist dauerhaft in dem Empfänger/Decodierer gespeichert. Zum Herunterladen von Daten wie etwa Anwendungscode oder einer aktualisierten Version einer Laufzeitmaschine ist komplizierte Software erforderlich, wobei diese Software üblicherweise eine große Menge Speicher einnimmt.
  • Beispiele der Erfindung beziehen sich auf die Erzeugung und Anwendung eines Datenbezugnahmesystems, das den Austausch und die Manipulation von Daten ermöglicht, die von heterogenen Systemen kommen und zu interaktiven Diensten wie etwa zu interaktiven Fernsehsystemen gehen.
  • Für Endnutzer werden immer mehr Informationsdienste bereitgestellt. Für einen Betreiber, der die Informationen für den Endnutzer bereitstellt, werden die Informationen häufig durch eine große Anzahl von Informationsanbietern bereitgestellt, die hier als Inhaltsanbieter bezeichnet werden. Zum Beispiel können Finanzinformationen durch einen oder durch mehrere verschiedene spezialisierte Finanzinhaltsanbieter bereitgestellt werden und können Sportinformationen durch einen oder durch mehrere spezialisierte Sportinhaltsanbieter bereitgestellt werden. Die Anzahl und die Art verschiedener Inhaltsanbieter wachsen und ändern sich ständig.
  • Jeder Inhaltsanbieter kann die Informationen firmenintern in einem anderen Format produzieren. Die Sendung der verschiedenen Informationsformate an den Nutzer ist häufig unpraktisch, wobei der Betreiber tatsächlich häufig eine einheitliche Darstellung von Informationen für den Nutzer haben möchte.
  • Der Inhaltsanbieter muss nun den Informationsinhalt für den Betreiber in dem vom Betreiber geforderten Format bereitstellen. Falls der Informationsinhalt durch den Inhaltsanbieter bereits für einen anderen Zweck, z. B. für einen anderen Betreiber entweder für dasselbe oder für ein anderes Medium (z. B. für das Internet), erzeugt worden ist, ist das Format möglicherweise nicht kompatibel mit dem, das von dem neuen Betreiber gefordert wird, wobei die Informationen häufig in dem gewünschten Format wiederhergestellt werden müssen. Dies kann die Anforderung des Neueingebens von Textabschnitten des Informationsinhalts einschließen. Dies ist natürlich nachteilig, da es sehr zeitaufwändig ist und die Verbreitung von Informationen an ein breites Publikum beeinträchtigen kann.
  • Außerdem kann der Informationsinhalt selbst dann, wenn er durch den Betreiber bereitgestellt worden ist, aktualisiert werden. Die Aktualisierungen können häufig, z. B. alle wenigen Minuten, stattfinden. Falls das Format des ursprünglichen Informationsinhalts durch den Betreiber festgesetzt worden ist, kann es sehr zeitaufwändig sein sicherzustellen, dass die Aktualisierungsinformationen mit dem ursprünglichen Format kompatibel sind. Wenn nicht, kann eine falsche Anzeige der aktualisierten Informationen auftreten, wobei z. B. das Ende des aktualisierten Texts bei der Sendung weggelassen werden kann, wenn der aktualisierte Text der Informationen länger als der ursprüngliche Text ist.
  • In einem Übertragungssystem kann der Betreiber Informationen über ein MPEG-Stromsystem an den Endnutzer senden wollen. Häufige Informationsaktualisierungen könnten zu einer großen Menge an Verarbeitung der Informationen zur Anzeige für den Nutzer am Nutzer-Ende, z. B. des Empfängers/Decodierers, führen. Bei der beschränkten Verarbeitungskapazität, die in dem Empfänger/Decodierer verfügbar ist, wäre dies nachteilig. Außerdem könnte der Empfänger/Decodierer Fehlersituationen, die sich auf die Informationen beziehen, nicht bewältigen können, ohne dass noch mehr von dem beschränkten Speicher und von der beschränkten Verarbeitung verwendet werden, die in dem Empfänger/Decodierer verfügbar sind.
  • Die europäische Patentanmeldung EP 0 810 790 bezieht sich auf ein Datenkommunikationssystem, auf eine Datensendevorrichtung und auf eine Datenempfangsvorrichtung. Dieses Dokument offenbart eine Sendevorrichtung (110) für ein interaktives Kommunikationssystem, das eine Übertragungswelle verwendet, wobei die Sendevorrichtung eine erste Ablageeinheit, eine zweite Ablageeinheit und eine Sendeeinheit verwendet. Die Datensendevorrichtung (110) fordert Daten zu einer externen Datenbank an.
  • Die Erfindung ist durch die Ansprüche definiert.
  • Es werden nun bevorzugte Merkmale der vorliegenden Erfindung lediglich beispielhaft mit Bezug auf die beigefügten Zeichnungen beschrieben, in denen:
  • 1 eine Übersicht eines typischen Digitalfernsehsystems zeigt;
  • 2 ein Blockschaltplan eines Empfängers/Decodierers ist;
  • 3 die Architektur eines Empfängers/Decodierers zeigt;
  • 4 die Anordnung von Dateien innerhalb eines in den Speicher eines interaktiven Empfängers/Decodierers heruntergeladenen Moduls zeigt;
  • 5 eine Wechselbeziehung zwischen einer Anzahl von Komponenten eines MPEG-Stroms veranschaulicht;
  • 6 veranschaulicht, wie eine Anwendung aus Modulen/Tabellen aufgebaut sein kann, die wiederum aus Abschnitten aufgebaut sein können;
  • 7 eine vereinfachte Übersicht ist;
  • 8 eine allgemeine Übersicht ist, die bestimmte Komponenten eines Systems, verschiedene Verbindungen zwischen ihnen und verschiedene Datenströme zeigt;
  • 9 den Durchgang von Daten durch das System aus 8 ausführlicher veranschaulicht;
  • 10 ein allgemeines Diagramm ist, das die Definition und Implementierung der Systembetriebsmittel durch eine Anwendung veranschaulicht;
  • 11 ein Folgediagramm ist, das sich ebenfalls auf die Definition und Implementierung der Systembetriebsmittel durch die Anwendung bezieht;
  • 12 ein allgemeines Diagramm ist, das die Erzeugung einer Bezugnahme auf eine Dateneinheit veranschaulicht;
  • 13 ein Folgediagramm ist, das ebenfalls die Erzeugung einer Bezugnahme auf eine Dateneinheit veranschaulicht;
  • 14 ein allgemeines Diagramm ist, das die Übertragung eines Szenariums veranschaulicht;
  • 15 ein Folgediagramm ist, das ebenfalls die Übertragung eines Szenariums veranschaulicht;
  • 16 ein allgemeines Diagramm ist, das die Übertragung einer externen Dateneinheit veranschaulicht, auf die Bezug genommen wird;
  • 17 ein Folgediagramm ist, das ebenfalls die Übertragung einer externen Dateneinheit veranschaulicht, auf die Bezug genommen wird;
  • 18 ein allgemeines Diagramm ist, das das Anhalten der Übertragung einer externen Datenbezugnahme veranschaulicht;
  • 19 ein Folgediagramm ist, das ebenfalls das Anhalten der Übertragung einer externen Datenbezugnahme veranschaulicht;
  • 20 ein allgemeines Diagramm ist, das das Beenden der Übertragung eines Szenariums veranschaulicht;
  • 21 ein Folgediagramm ist, das ebenfalls das Beenden der Übertragung eines Szenariums veranschaulicht;
  • 22 ein allgemeines Diagramm ist, das die Unterdrückung der Bezugnahme auf eine Dateneinheit veranschaulicht; und
  • 23 ein Folgediagramm ist, das ebenfalls die Unterdrückung der Bezugnahme auf eine Dateneinheit veranschaulicht.
  • Systemübersicht
  • In 1 ist eine Übersicht eines Digitalfernsehsystems 1 gezeigt. Die Erfindung enthält ein zum größten Teil herkömmliches Digitalfernsehsystem 2, das das bekannte MPEG-2-Kompressionssystem zum Senden komprimierter digitaler Signale verwendet. Ausführlicher empfängt ein MPEG-2-Kompressor 3 in einer Übertragungszentrale einen digitalen Signalstrom (üblicherweise einen Strom von Videosignalen). Der Kompressor 3 ist durch eine Verbindung 5 mit einem Multiplexer und Verwürfler 4 verbunden.
  • Der Multiplexer 4 empfängt mehrere weitere Eingangssignale, setzt den Transportstrom zusammen und sendet die komprimierten digitalen Signale über eine Verbindung 7, die natürlich eine breite Vielfalt von Formen einschließlich Telekommunikationsverbindungen annehmen kann, an einen Sender 6 der Übertragungszentrale. Der Sender 6 sendet über eine Aufwärtsstrecke 8 elektromagnetische Signale zu einem Satellitentransponder 9, wo sie elektronisch verarbeitet und über eine nominelle Abwärtsstrecke 10 zum Erdempfänger 12, herkömmlich in Form einer Schüssel, die der Endnutzer besitzt oder gemietet hat, übertragen werden. Natürlich sind für die Sendung der Daten weitere Transportkanäle wie etwa Erdrundfunk, Kabelübertragung, kombinierte Satelliten/Kabelverbindungen, Telephonnetze usw. möglich.
  • Die vom Empfänger 12 empfangenen Signale werden an einen integrierten Empfänger/Decodierer 13 gesendet, den der Endnutzer besitzt oder gemietet hat und der mit dem Fernsehgerät 14 des Endnutzers verbunden ist. Der Empfänger/Decodierer 13 decodiert das komprimierte MPEG-2-Signal in ein Fernsehsignal für das Fernsehgerät 14. Obgleich in 1 ein getrennter Empfänger/Decodierer gezeigt ist, kann der Empfänger/Decodierer Teil eines integrierten Digitalfernsehgeräts sein. Wie er hier verwendet wird, enthält der Begriff "Empfänger/Decodierer" einen getrennten Empfänger/Decodierer wie eine Set-Top-Box und ein Fernsehgerät mit damit integriertem Empfänger/Decodierer.
  • In einem Mehrkanalsystem behandelt der Multiplexer 4 Audio- und Videoinformationen, die von einer Anzahl paralleler Quellen empfangen werden, wobei er mit dem Sender 6 in Wechselwirkung steht, um die Informationen entlang einer entsprechenden Anzahl von Kanälen zu übertragen. Zusätzlich zu audiovisuellen Informationen können in einigen oder allen dieser Kanäle verschachtelt mit den übertragenen digitalen Audio- und Videoinformationen Nachrichten oder Anwendungen oder irgendeine andere Sorte digitaler Daten eingeführt werden.
  • Mit dem Multiplexer 4 und mit dem Empfänger/Decodierer 13 ist ein System 15 für bedingten Zugriff verbunden, das sich teilweise in der Übertragungszentrale und teilweise in dem Empfänger/Decodierer befindet. Es ermöglicht, dass der Endnutzer auf Digitalfernsehübertragungen von einem oder von mehreren Übertragungslieferanten zugreift. In den Empfänger/Decodierer 13 kann eine Chipkarte eingeführt werden, die Nachrichten entschlüsseln kann, die sich auf kommerzielle Angebote (d. h. auf eines oder auf mehrere Fernsehprogramme, die von dem Übertragungslieferanten verkauft werden) beziehen. Unter Verwendung des Empfängers/Decodierers 13 und der Chipkarte kann der Endnutzer entweder in einer Abonnementbetriebsart oder in einer Bezahlen-pro-Ansicht-Betriebsart kommerzielle Angebote kaufen.
  • Wie oben erwähnt wurde, werden die von dem System gesendeten Programme in dem Multiplexer 4 verwürfelt, wobei die auf eine gegebene Sendung angewendeten Bedingungen und Verschlüsselungsschlüssel durch das Zugriffssteuersystem 15 bestimmt werden. Die Sendung verschlüsselter Daten auf diese Weise ist auf dem Gebiet der Bezahl-TV-Systeme gut bekannt. Üblicherweise werden verwürfelte Daten zusammen mit einem Steuerwort zum Entwürfeln der Daten gesendet, wobei das Steuerwort selbst durch einen so genannten Nutzungsschlüssel verschlüsselt ist und in verschlüsselter Form gesendet wird.
  • Die verwürfelten Daten und das verschlüsselte Steuerwort werden daraufhin durch den Empfänger/Decodierer 13 empfangen, der Zugriff auf ein Gegenstück zu dem Nutzungsschlüssel hat, das auf einer in den Empfänger/Decodierer eingeführten Chipkarte gespeichert ist, um das verschlüsselte Steuerwort zu entschlüsseln und anschließend die gesendeten Daten zu entwürfeln. Ein Abonnent, der gezahlt hat, empfängt den zum Entschlüsseln des verschlüsselten Steuerworts notwendigen Nutzungsschlüssel z. B. in einer monatlich übertragenden EMM (Berechtigungsmanagementnachricht), um das Ansehen der Sendung zu ermöglichen.
  • Ein interaktives System 16, das ebenfalls mit dem Multiplexer 4 und mit dem Empfänger/Decodierer 13 verbunden ist und das sich wieder teilweise in der Übertragungszentrale und teilweise in dem Empfänger/Decodierer befindet, ermöglicht, dass der Endnutzer über einen Rückkanal 17 mit verschiedenen Anwendungen in Wechselwirkung tritt. Der Rückkanal kann z. B. ein Kanal eines öffentlichen Fernsprechwählnetzes (PSTN-Kanal) (z. B. ein Modemrückkanal) oder ein Außerbandkanal (OOB-Kanal) sein. Außerdem kann der Rückkanal für die Kommunikation verwendet werden, die in dem System 15 für bedingten Zugriff verwendet wird.
  • Empfänger/Decodierer
  • Anhand von 2 werden nun die verschiedenen Elemente des Empfängers/Decodierers 13 hinsichtlich Funktionsblöcken beschrieben.
  • Der Empfänger/Decodierer 13, der Z. B. eine digitale Set-Top-Box (DSTB) sein kann, umfasst einen Zentralprozessor 220, der zugeordnete Speicherelemente enthält und der dafür ausgelegt ist, Eingangsdaten von einer seriellen Schnittstelle 221, von einer parallelen Schnittstelle 222, von einem (mit dem Modemrückkanal 17 aus 1 verbundenen) Modem 223 und von Schaltkontakten 224 an der Frontplatte des Decodierers zu empfangen.
  • Zusätzlich ist der Empfänger/Decodierer dafür ausgelegt, über eine Steuereinheit 226 Eingaben von einer Infrarotfernbedienung 225 zu empfangen, während er außerdem zwei Chipkartenleser 227, 228 besitzt, die dafür ausgelegt sind, Bank- bzw. Abonnementchipkarten 242, 240 zu lesen. Der Abonnementchipkartenleser 228 gelangt mit einer eingeführten Abonnementkarte 240 und mit einer Einheit 229 für bedingten Zugriff in Eingriff, um an einen Demultiplexer/Entwürfler 230 das notwendige Steuerwort zu liefern, das ermöglicht, dass das verschlüsselte Übertragungssignal entwürfelt wird. Außerdem enthält der Decodierer einen herkömmlichen Tuner 231 und einen herkömmlichen Demodulator 232, um die Satellitensendung zu empfangen und zu demodulieren, bevor sie durch die Einheit 230 gefiltert und demultiplexiert wird.
  • Wie es in dieser Beschreibung verwendet wird, ist eine Anwendung vorzugsweise ein Stück Computercode zum Steuern höherer Funktionen, vorzugsweise des Empfängers/Decodierers 13. Wenn der Endnutzer z. B. den Brennpunkt der Fernbedienung 225 auf ein Schaltflächenobjekt konzentriert, das auf dem Bildschirm des Fernsehgeräts 14 zu sehen ist, und eine Überprüfungstaste drückt, wird die der Schaltfläche zugeordnete Anweisungsfolge ausgeführt.
  • Eine interaktive Anwendung schlägt Menüs vor, führt auf Anforderung des Endnutzers Befehle aus und liefert auf den Zweck der Anwendung bezogene Daten. Die Anwendungen können entweder residente Anwendungen sein, d. h. in dem ROM (oder FLASH oder in einem anderen nichtflüchtigen Speicher) des Empfängers/Decodierers 13 gespeichert sein, oder übertragen werden und in den RAM oder FLASH-Speicher des Empfängers/Decodierers 13 heruntergeladen werden.
  • Anwendungen werden an Speicherplätzen in dem Empfänger/Decodierer 13 gespeichert und als Betriebsmitteldateien dargestellt. Wie in den oben erwähnten Patentschriften ausführlicher beschrieben ist, umfassen die Betriebsmitteldateien Graphikobjektbeschreibungseinheits-Dateien, Variablenblockeinheits-Dateien, Anweisungsfolgedateien, Anwendungsdateien und Datendateien.
  • Der Empfänger/Decodierer enthält Speicher, der in einen RAM-Datenträger, in einen FLASH-Datenträger und in einen ROM-Datenträger unterteilt ist, wobei diese physikalische Organisation aber von der logischen Organisation verschieden ist. Ferner kann der Speicher in Speicherdatenträger unterteilt sein, die den verschiedenen Schnittstellen zugeordnet sind. Unter einem Gesichtspunkt kann der Speicher als Teil der Hardware betrachtet werden; unter einem anderen Gesichtspunkt kann der Speicher in der Weise betrachtet werden, dass er das gesamte von der Hardware getrennt gezeigte System unterstützt oder enthält.
  • Architektur des Empfängers/Decodierers
  • Der Empfänger/Decodierer enthält fünf Software-Schichten, die so organisiert sind, dass die Software in irgendeinem Empfänger/Decodierer und mit irgendeinem Betriebssystem implementiert werden kann. Anhand von 3 sind die verschiedenen Software-Schichten die Anwendungsschicht 250, die Anwendungsprogrammierschnittstellen-Schicht (API-Schicht) 252, die Schicht 254 der virtuellen Maschine, die Vorrichtungsschicht 256 und die System-Software/Hardware-Schicht 258.
  • Die Anwendungsschicht 250 umfasst Anwendungen, die entweder in dem Empfänger/Decodierer resident sind oder in ihn heruntergeladen werden. Sie können von Kunden verwendete interaktive Anwendungen sein, die z. B. in Java, HTML, MHEG-5 oder in anderen Sprachen geschrieben sind, oder sie können Anwendungen sein, die von dem Empfänger/Decodierer verwendet werden, um diese Anwendungen auszuführen. Diese Schicht beruht auf einer Menge offener Anwendungsprogrammierschnittstellen (APIs), die durch die Schicht der virtuellen Maschine bereitgestellt werden. Dieses System ermöglicht, dass Anwendungen fliegend oder auf Bedarf in den Flash- oder RAM-Speicher in dem Empfänger/Decodierer heruntergeladen werden. Der Anwendungscode kann unter Verwendung von Protokollen wie etwa Data Storage Media Command and Control (DSMCC), Network File Server (NFS) oder anderen Protokollen in einem komprimierten oder unkomprimierten Format gesendet werden.
  • Interaktive Anwendungen sind Anwendungen, mit denen der Nutzer in Wechselwirkung tritt, um z. B. Produkte und Dienste zu erhalten, wie etwa elektronische Programmführer, Telebanking-Anwendungen und Spiele. Für das Management interaktiver Anwendungen werden die folgenden residenten Anwendungen verwendet:
    • – Booten. Die Boot-Anwendung 260 ist die erste Anwendung, die gestartet wird, wenn der Empfänger/Decodierer eingeschaltet wird. Die Boot-Anwendung startet die verschiedenen "Manager" in der virtuellen Maschine, wobei der erste der Anwendungsmanager 262 ist.
    • – Anwendungsmanager. Der Anwendungsmanager 262 managt die interaktiven Anwendungen, die in dem Empfänger/Decodierer ausgeführt werden, d. h., er startet Anwendungen, hält Anwendungen an, hält Anwendungen wartend, nimmt Anwendungen wieder auf, behandelt Ereignisse und die Kommunikation zwischen Anwendungen. Er ermöglicht, dass mehrere Anwendungen gleichzeitig ausgeführt werden, und ist somit an der Zuordnung von Betriebsmitteln zwischen ihnen beteiligt. Diese Anwendung ist für den Nutzer vollständig transparent.
    • – SetUp. Der Zweck der SetUp-Anwendung 264 ist es, den Empfänger/Decodierer, hauptsächlich das erste Mal, wenn er verwendet wird, zu konfigurieren. Sie führt Aktionen wie etwa das Abtasten auf TV-Kanäle, das Einstellen des Datums und der Zeit, das Festsetzen von Nutzerpräferenzen usw. aus. Allerdings kann die SetUp-Anwendung von dem Nutzer jederzeit verwendet werden, um die Empfänger/Decodierer-Konfiguration zu ändern.
    • – Programmumschaltung. Die Programmumschaltungsanwendung 268 wird verwendet, um unter Verwendung der Programm-auf-Taste, der Programm-ab-Taste und der Zahlentasten die Kanäle zu ändern. Wenn, z. B. von einer Banneranwendung (Pilotanwendung), eine andere Form der Kanalumschaltung verwendet wird, wird die Kanalumschaltungsanwendung angehalten.
    • – Rückruf. Die Rückrufanwendung wird verwendet, um die Werte verschiedener in dem Empfänger/Decodierer-Speicher gespeicherter Parameter zu entnehmen und diese Werte über den Modemrückkanal 17 oder mit anderen Mitteln an den kommerziellen Betreiber zurückzugeben.
  • Die API-Schicht 252 stellt höhere Dienstprogramme für die Entwicklung interaktiver Anwendungen bereit. Sie enthält mehrere Pakete, die diese höhere API bilden. Die Pakete stellen die gesamte zum Ausführen interaktiver Anwendungen notwendige Funktionalität bereit. Die Anwendungen können auf die Pakete zugreifen.
  • In einer bevorzugten Ausführungsform ist die API dafür ausgelegt, Anwendungen auszuführen, die in der Programmiersprache Java geschrieben sind. Darüber hinaus kann sie HTML und andere Formate wie etwa MHEG-5 interpretieren. Neben diesen Interpretern enthält sie außerdem weitere Pakete und Dienstmodule, die, je nachdem, wie es die Anforderungen vorschreiben, lösbar und erweiterbar sind.
  • Die Schicht 254 der virtuellen Maschine ist aus Sprachinterpretern und aus verschiedenen Modulen und Systemen gebildet. Sie besteht aus allem Notwendigen, um in dem Empfänger/Decodierer interaktive Anwendungen zu empfangen und auszuführen.
  • Die Vorrichtungsschnittstellenschicht 256 enthält einen Vorrichtungsmanager und Vorrichtungen. Vorrichtungen sind Software-Module, die aus den logischen Betriebsmitteln bestehen, die für das Management externer Ereignisse und physikalischer Schnittstellen notwendig sind. Die Vorrichtungsschicht managt Kommunikationskanäle zwischen Treibern und Anwendungen und stellt eine verbesserte Fehlerausnahmeprüfung bereit. Einige Beispiele gemanagter Vorrichtungen sind: Kartenleser, Modems, Netz, PCMCIA (Personal Computer Memory Card International Association), LED-Anzeige usw. Da die API-Schicht die Vorrichtungen von oben aus steuert, brauchen sich Programmierer mit dieser Schicht nicht direkt zu beschäftigen.
  • Die System-Software/Hardware-Schicht 258 wird durch den Hersteller des Empfängers/Decodierers bereitgestellt. Wegen der Modularität des Systems und da die durch das BS bereitgestellten Dienste (wie etwa Ereignisplanung und Speichermanagement) Teil der virtuellen Maschine sind, sind die höheren Schichten nicht an ein bestimmtes Echtzeitbetriebssystem (RTOS) oder an einen bestimmten Prozessor gebunden.
  • Es wird nun eine ein Modul genannte spezifische Objektklasse im Kontext eines Empfängers/Decodierers beschrieben.
  • Anhand von 4 ist ein Modul 710 wie etwa ein Teleshopping-Modul eine Menge von Betriebsmitteldateien und von Daten, die Folgendes umfasst:
    eine einzelne Anwendungsdatei 712;
    eine unbestimmte Anzahl von Graphikobjektbeschreibungseinheits-Dateien 714;
    eine unbestimmte Anzahl von Variablenblockeinheits-Dateien 716;
    eine unbestimmte Anzahl von Anweisungsfolgedateien 718; und
    wo geeignet, Datendateien 720 wie etwa Symbolbibliothekdateien, Bilddateien, Zeichensatzdateien, Farbtabellendateien und ASCII-Textdateien.
  • Das Konzept der Module 710 ermöglicht zusammen mit dem Konzept des Herunterladens kleiner Codestücke die leichte Entwicklung von Anwendungen. Sie können als residente Software in den FLASH-Festspeicher des Empfängers/Decodierers 13 (nicht gezeigt) heruntergeladen werden oder können übertragen werden, um nur dann in den RAM des Empfängers/Decodierers 13 heruntergeladen zu werden, wenn sie von dem Endnutzer benötigt werden.
  • Im Fall des MPEG-Flusses wird ein Modul 710 in einer einzelnen MPEG-Tabelle transportiert. Im Fall von Modulen, die an den MPEG-Tuner (nicht gezeigt) gesendet werden, wird das lange MPEG-2-Format mit einem langen Anfangsblock und einem CRC-Code verwendet. Abgesehen davon, dass das "kurze" MPEG-2-Format mit einem kürzeren Anfangsblock und keinem CRC verwendet wird, ist dies auch bei den fünf anderen Schnittstellen des Empfängers/Decodierers (serielle Schnittstelle, parallele Schnittstelle, Modem und zwei Kartenleser – nicht gezeigt) der Fall.
  • Insbesondere anhand von 5 enthält der MPEG-2-Bitstrom bekanntlich eine Programmzugriffstabelle ("PAT") 810 mit einer Paketkennung ("PID") von 0. Die PAT enthält Bezugnahmen auf die PIDs der Programmabbildtabellen ("PMTs") 812 einer Anzahl von Programmen. Jede PMT enthält eine Bezugnahme auf die PIDs der Ströme der Audio-MPEG-Tabellen 814 und der Video-MPEG-Tabellen 816 für dieses Programm. Ein Paket mit einer PID von null, d. h. die Programmzugriffstabelle 810, stellt den Eintrittspunkt für alle MPEG-Zugriffe bereit.
  • Es sind zwei relevante Stromtypen definiert, um Anwendungen und Daten für sie herunterzuladen, wobei die relevante PMT außerdem Bezugnahmen auf die PIDs der Ströme von Anwendungs-MPEG-Tabellen 818 (oder von Abschnitten von ihnen) und von Daten-MPEG-Tabellen 820 (oder von Abschnitten von ihnen) enthält.
  • Um eine Anwendung 822 herunterzuladen, wird die Anwendung anhand von 6 in Module 824 unterteilt, die jeweils durch eine MPEG-Tabelle gebildet sind, von denen einige aus einem einzelnen Abschnitt 818 gebildet sind und andere aus mehreren Abschnitten 818 gebildet sind. Ein typischer Abschnitt 818 besitzt einen Anfangsblock 826, der eine Ein-Byte-Tabellenkennung ("TID") 828, die Abschnittsnummer 830 dieses Abschnitts in der Tabelle, die Gesamtzahl 832 der Abschnitte in dieser Tabelle und eine Zwei-Byte-TID-Erweiterung 834 enthält. Außerdem enthält jeder Abschnitt einen Datenteil 836 und eine CRC 838. Für ein bestimmtes Modul/für eine bestimmte Tabelle 824 haben alle Abschnitte 818, aus denen die Tabelle 824 gebildet ist, dieselbe TID 828 und dieselbe TID-Erweiterung 834. Für eine bestimmte Anwendung 822 haben alle Tabellen 824, die diese Anwendung 822 bilden, dieselbe TID 828, aber jeweils verschiedene TID-Erweiterungen.
  • Das oben erwähnte System zum Übertragen von Daten an einen Empfänger/Decodierer in einem digitalen Übertragungssystem ist vielseitig genug, um z. B. zu ermöglichen, dass Web-Seiten in Bezug auf bestimmte Programme oder Kanäle übertragen werden, die daraufhin zusammen mit den besagten Programmen oder Kanälen angesehen werden können.
  • 7 ist eine vereinfachte Übersicht. Es sind ein Programmanbieter 400, ein Inhaltsanbieter 402, ein Betreiber 404, eine Übertragungszentrale 406, ein Satellit 408 und eine Set-Top-Box (STB) 410 gezeigt.
  • Der Programmanbieter 400 umfasst einen Offline-Editor 420, eine Ablagevorrichtung 422, die XTVML-Dateien enthält, einen Anwendungs-Server 424, einen Online-Editor 426 und eine Datenablagevorrichtung 428.
  • Der Inhaltsanbieter 402 umfasst eine Datenablagevorrichtung 440 und eine Übertragungskonsole 442.
  • Der Betreiber 404 umfasst einen Web-Server 450, eine Datenablagevorrichtung 452 und eine Firewall 454.
  • Die Übertragungszentrale umfasst einen Abschnittsübertragungsinjektor (SBI) 460 und einen Satellitensender 462.
  • Die Verbindungen zwischen dem Programmanbieter 400, dem Inhaltsanbieter 402, dem Betreiber 404 und der Übertragungszentrale 406 und zwischen ihren verschiedenen Komponenten sind in dem Diagramm durch Pfeile dargestellt.
  • Der folgende Abschnitt stellt die Funktionsbeschreibungen und technischen Beschreibungen in Bezug auf die Verwendung von Datenbezugnahmen dar.
  • Der Begriff einer universellen Bezugnahme (Uniform Resource Identifier) ermöglicht, dass auf jedes Datenelement oder -stück innerhalb eines Anwendungssystems eindeutig Bezug genommen wird. Außerdem ermöglicht er, dass jedes dieser Elemente durch einen logischen Deskriptor definiert wird und nicht mehr direkt durch ein Systembetriebsmittel definiert wird. Jede physikalische Änderung von Daten führt nicht zu einer Änderung auf der Ebene der Anwendungen, die das Nutzungsformat beschreiben. Dies bietet für eine Anwendung den Vorteil, den Teil, der die Darstellung der Daten beschreibt (den 'Container'), und den Teil, der die Daten selbst betrifft (den 'Inhalt'), zu entkorrelieren.
  • Der Programmanbieter ist verantwortlich für die Erzeugung der Bildschirme, die ein Szenarium bilden. Diese Bildschirme sind aus Elementarobjekten gebildet, die ermöglichen, dass die Daten angezeigt und genutzt werden. Im Fall von Daten aus einer verwandten externen Quelle wird das Bezugnahmeprinzip verwendet, um sie zu entwerfen.
  • Der Inhaltsanbieter ist verantwortlich dafür, dass eine Sammlung von Daten, auf die Bezug genommen wird, an den Betreiber gesendet wird. Diese Daten werden gemäß veränderlichen Häufigkeiten gesendet, die von ihren redaktionellen oder Werbeinteressen abhängen.
  • Der Betreiber ist für die Übertragung der Daten verantwortlich. Die Daten werden in zwei Kategorien geteilt: in einem Teil der Beschreibung der Bildschirme und der XTVML-Objekte der Anwendung, die von dem Programmanbieter kommen, und in den anderen Teil der externen Daten, die von dem Inhaltsanbieter ausgehen.
  • Es wird daran erinnert, dass die verwendete URI-Struktur in Übereinstimmung mit der folgenden Struktur normalisiert ist:
    <Scheme> : <StreamLocator> : <DataLocator>
  • Das <Scheme>-Feld repräsentiert den Typ des Systembetriebsmittels (Dienst, Anwendung oder Daten), <StreamLocator> repräsentiert den Datenstrom und <DataLocator> repräsentiert das Datenpaket.
  • Um z. B. den Wert von CAC40 (französischer Aktienmarktindikator) nachzuschlagen, kann die folgende URI-Schreibweise genutzt werden:
    <dtv-d>:<Bourse_de_Paris>:<CAC40>
  • Es wird angemerkt, dass der StreamLocator hier den von dem Inhaltsanbieter ausgegebenen Datenstrom und nicht den Transportfluss der Daten auf der Übertragungsebene repräsentiert. Diese Einzelheit ist auf der Ebene der Zusammensetzung der Daten wichtig, die im Folgenden beschrieben wird.
  • Der logische Deskriptor ist die präzise und explizite Definition der Daten. Um zu dem Beispiel des CAC40 zurückzukehren, kann der logische Deskriptor in Bezug auf sich selbst durch 'Wert des CAC40' dargestellt werden.
  • Für größere Flexibilität in der Verwendung ist dies der Deskriptor, der auf der Ebene eines Editierhilfsmittels von einem Nutzer verwendet werden kann, der ein Datenstück ermitteln möchte, ohne seine URI zu kennen.
  • Der Container ist tatsächlich der XTVML-Dateiname, der die Beschreibung eines elementaren XTVML-Objekts repräsentiert, auf dessen Inhalt durch eine URI Bezug genommen wird. Diese XTVML-Datei wird in die Form einer MPEG-Tabelle umgesetzt, die durch eine PID, durch eine TID und durch eine TIDExt identifiziert ist.
  • Die externen Daten, auf die Bezug genommen werden kann, können von einem einfachen redaktionellen Typ, d. h. Text oder Bilder, sein. Sie werden durch den Inhaltsanbieter mit einer vorgegebenen, aber veränderlichen Häufigkeit an den Betreiber gesendet.
  • Es ist möglich, zwischen zwei Typen externer Daten zu unterscheiden, die hauptsächlich mit ihrer Auffrischhäufigkeit verknüpft sind:
    Der erste Typ sind Streaming-Daten: Die Daten werden durch den Inhaltsanbieter mit einer hohen Häufigkeit geändert und gesendet und müssen auf der Ebene des Decodierers automatisch aufgefrischt werden.
  • Der zweite Typ ist normal: Die Daten werden im Laufe der Zeit wenig geändert und erfordern keine automatische Auffrischung.
  • Wie zu sehen ist, ist es hier sehr wichtig, den externen Datentyp zu spezifizieren, da es für Streaming-Daten notwendig ist, für den Empfänger/Decodierer anzugeben, ob er ein System zum Abtasten der Version der Tabellen, die die Daten transportieren, einrichten sollte. Somit wird der Datentyp entweder auf der Ebene der XTVML-Objekte, die die Daten enthalten (z. B. durch den Programmanbieter) oder auf derselben Ebene wie die Daten (z. B. durch den Inhaltsanbieter) gesendet.
  • Die Bezugnahmeauflösung, d. h. der Mechanismus, der im Zuordnen eines physikalischen Datenstücks zu einer logischen Bezugnahme besteht, findet in Informationsflussrichtung vor den Übertragungsprozessen statt.
  • Wegen der fehlenden Verarbeitungskapazität bei dem Empfänger/Decodierer kann diese Phase normalerweise nicht bei dem Empfänger/Decodierer stattfinden.
  • Hinsichtlich der Übertragung einer Anwendung besteht die Auflösung im Ersetzen der logischen Bezugnahme durch eine physikalische Bezugnahme. Falls diese physikalische Bezugnahme nicht existiert, wird sie erzeugt.
  • Hinsichtlich der Übertragung von externem Inhalt besteht die Auflösung im Ersetzen der innerhalb eines Containers vorhandenen Bezugnahme durch denselben Wert wie die Daten (Textzeilen, Bild usw.).
  • Mit dem Ziel, alle Probleme defekter Verknüpfungen zu vermeiden, wenn in einem Empfänger/Decodierer eine Bezugnahme verwendet wird, ist es vorteilhaft, den Begriff eines Standardbezugnahmewerts einzuführen. Dieser besteht darin, für die Bezugnahme auf ein von dem externen Anbieter ausgehendes Datenelement den Wert zu definieren, der durch den Decodierer angezeigt werden muss, falls bei der Übertragung der Echtzeitdaten innerhalb der Zusammensetzungskette ein Problem auftritt. Diese Standardwerte, üblicherweise ein Textstück oder ein Bild, werden entweder global in Bezug auf eine Anwendung oder auf der gleichen Ebene wie die Daten definiert. Darüber hinaus werden diese Werte nicht weiter entlang der Linie als auf der Betreiberebene, d. h. vor der Übertragung des Anwendungsformats, übertragen, sodass im Fall eines Problems innerhalb der Container, die ihre entsprechende Bezugnahme verwenden, die Standardwerte eingefügt werden können.
  • Die von dem System verwendeten Daten können sensibel sein oder Rechten unterliegen; somit können zwei Sicherheitsebenen definiert sein, wobei die erste Zugriffsrechte auf Bezugnahmen und die zweite die Nutzungsrechte der Daten betrifft.
  • Jedes Editierhilfsmittel hat nur das Recht, ausschließlich bestimmte Elemente, auf die Bezug genommen wird, zu verwenden, die ihm zur Verfügung gestellt werden. Darüber hinaus ermöglichen diese Rechte, die Verantwortlichkeiten in Bezug auf die Übertragung oder das Ende der Übertragung von Daten zu managen. Um zu ermöglichen, dass dies erfolgt, ist es relevant, die Sammlung von Nutzern zu definieren, bevor der Zugriff auf eine gegebene Dateneinheit oder auf eine Datenkategorie gewährt wird. Diese Rechte werden durch den Betreiber gemäß den Eigenschaften der letztendlichen Nutzer definiert.
  • Außerdem ist es für ein Datenelement möglich, die Zeitperiode zu spezifizieren, innerhalb derer es übertragen wird. Es ist vorstellbar, dass diese üblicherweise für die Übertragung einer Werbung beginnt, die mit einem bestimmten Programm verknüpft ist. Am Ende der Übertragung wird die Übertragung automatisch angehalten.
  • Die von einem Inhaltsanbieter ausgehenden Daten können Nutzungsrechten unterworfen werden, wobei z. B. Bilder zum Gegenstand von Nutzungs- und Übertragungsrechten gemacht werden können.
  • Im Licht der verschiedenen oben dargelegten Punkte wird für die Datendateien die folgende XML-Struktur vorgeschlagen:
    Figure 00260001
  • Diese verschiedenen Datendateien werden durch den Inhaltsanbieter gemäß der eigenen Initiative des Inhaltsanbieters gesendet.
  • Die Funktionalitäten, die im Folgenden beschrieben werden, sind wie folgt aufgeführt:
    • – Definition und Zuordnung von Systembetriebsmitteln durch eine Anwendung
    • – Erzeugung der Bezugnahme für eine externe Dateneinheit
    • – Verwendung einer Bezugnahme in einem Editierhilfsmittel
    • – Übertragung eines Datenformats unter Verwendung einer Bezugnahme
    • – Übertragung einer Dateneinheit, auf die Bezug genommen wird
    • – Anhalten der Übertragung einer externen Dateneinheit, auf die Bezug genommen wird
    • – Anhalten einer Anwendung, die die externen Daten verwendet, auf die durch Bezugnahmen Bezug genommen wird
    • – Unterdrückung der Daten, auf die Bezug genommen wird.
  • Im Folgenden wird diese Liste von Funktionalitäten beschrieben.
  • Definition und Zuordnung von Systembetriebsmitteln durch eine Anwendung:
    Diese Funktionalität ermöglicht die Definition der Übertragungsströme, die für den Transport von Daten verwendet werden. Diese Operation findet auf der Ebene des Dienstplans statt und hat die Zuordnung einer bestimmten PID zu einer Datenkategorie als ihr Ziel. Diese Ströme können aus privaten MPEG-Tabellen gebildet werden, wobei es gleichfalls notwendig ist, die TID-Bereiche zu definieren. Im Prinzip entspricht ein TID-Wert einem bestimmten Datentyp (Bild, Text).
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
    • – Definition der Datenkategorien
    • – Laden von Informationen über die Stromlokalisierer in die Datenbank des Bezugnahmesystems
    • – Definition der TID-Bereiche für die verschiedenen Typen externer Daten
    • – Erzeugung einer Konfigurationsdatei, die eine Sammlung von Datentypen, die in dem Anwendungsrahmen nutzbar sind, und ihre Entsprechung mit den Transportelementen ihrer Bezugnahme umfasst.
  • Diese Funktionalität ermöglicht die Zuordnung einer eindeutigen Bezugnahme, die gemäß der normalisierten Struktur der URI definiert ist, zu einer Dateneinheit. Diese Bezugnahmendefinition wird zwischen dem Inhaltsanbieter, dem Programmanbieter und dem Betreiber gemeinsam erzeugt. Der Betreiber, der für die Speicherung und für das Management der Bezugnahmen verantwortlich ist, muss gleichfalls die globale Menge der Daten steuern, die durch die Anwendung übertragen werden.
  • Für jede der Dateneinheiten sind die folgenden Parameter definiert:
    • – Stromlokalisierer: Dies ist die Kennung der XML-Datei, die die Daten von ihrem Anbieter zu dem Betreiber transportiert.
    • – Datenlokalisierer: Dies ist der Ort der Daten in der XML-Datei. Seine Definition beruht auf den Xpath- oder XML-Abfrage-Normalisierungsprinzipien.
    • – logischer Deskriptor: Diese Beschreibung ermöglicht, dass das Editierhilfsmittel die Daten, auf die Bezug genommen wird, eindeutig identifiziert.
    • – Standardwert
    • – Eigentümer
    • – Nutzungsrechte
  • Wenn diese Bezugnahme definiert worden ist, werden diese Parameter auf der Ebene des Betreibers gespeichert, der daraufhin dafür verantwortlich ist, sie für das berechtigte Editierhilfsmittel verfügbar zu machen.
  • Aktionen
    • – Auswahl einer Dateneinheit
    • – Identifizierung ihres Typs
    • – Zuordnung eines Stromlokalisierers
    • – Erzeugung des Datenlokalisierers
    • – Definition der Parameter der Bezugnahme
    • – Speicherung der URI und ihres logischen Deskriptors in dem Bezugnahmesystem des Betreibers
    • – Speicherung der Beziehung zwischen einer Dateneinheit und ihrer Bezugnahme in der Datenbank ihres Erzeugers (d. h. des Inhaltsanbieters)
  • Verwendung einer Bezugnahme in einem Editierhilfsmittel:
    Diese Funktionalität ermöglicht, dass der Nutzer eines Editierhilfsmittels, der eine Dateneinheit verwenden möchte, auf die Bezug genommen wird, die Bezugnahme (URI) auf diese Dateneinheit innerhalb seines eigenen Anwendungsformats einfügt.
  • Hierfür stellt sie eine dedizierte GUI zur Verfügung, die es ihm ermöglicht, eine Bezugnahme aus einer Liste auszuwählen. Diese Liste kann gemäß dem Typ gesuchter Daten klassifiziert sein. Die Bezugnahmen werden gemäß den Rechten der Nutzer gefiltert. Die GUI stellt gleichfalls Informationen über den Übertragungszustand der Dateneinheit bereit, auf die Bezug genommen wird.
  • Wenn die Bezugnahme ausgewählt worden ist, wird die URI-Eigenschaft des für das Anzeigen der entsprechenden Dateneinheit verantwortlichen Objekts aktualisiert.
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
    • – Aktualisierung der Liste verwendbarer URIs
    • – Einfügen der URI auf der Ebene des Datenformats der Client-Anwendung
    • – Auswählen einer Dateneinheit, auf die Bezug genommen wird, aus ihrem logischen Deskriptor oder direkt aus ihrer URI
    • – Einfügen der URI auf der Ebene des Datenformats der Client-Anwendung
  • Übertragung eines Datenformats unter Verwendung einer Bezugnahme:
    Diese Funktionalität ermöglicht, dass ein Nutzer die Übertragung seines Datenformats an den Betreiber anfordert. Hierfür sendet der Nutzer seine Datendateien über eine Übertragungskonsole an den Betreiber. Der Nutzer spezifiziert bestimmte Parameter, die die Übertragung betreffen, wie etwa das Datum und die Zeit der Übertragung, sowie Managementregeln, die die Kontrolle der Integrität des Formats und der verwendeten Daten zulassen. Diese Regeln definieren insbesondere die Bedingungen, unter denen das Format einer Anwendung übertragbar ist. Ist es üblicherweise möglich zu übertragen, falls bestimmte Daten, die mit den in dem Format verwendeten Daten verknüpft sind, auf der Ebene des Übertragungssystems fehlen? Der Nutzer wird durch den Betreiber vor der Möglichkeit der Übertragung seines Datenformats gewarnt.
  • Für jede der Verwendungen einer Bezugnahme innerhalb des Anwendungsformats wird eine spezifische Analyse ausgeführt. Sie ermöglicht die Vorbereitung des Ziel-XTVML-Containers zum Empfangen der ihm entsprechenden Dateneinheit. Dieser Container wird mit dem zugeordneten Stromlokalisierer und Datenlokalisierer gefüllt, wobei der Datenlokalisierer die Wiedergewinnung der ihm entsprechenden Dateneinheit ermöglicht. Außerdem ermöglicht die oben erwähnte Idee eines Standardwerts in dieser Phase die Übertragung des gefüllten Containers, bevor der wahre Wert der Bezugnahme empfangen worden ist.
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
  • Übertragungskonsolenseite:
    • – Definieren der Managementregeln hinsichtlich globaler Kohärenz der Daten
    • – Definieren der Übertragungsparameter (Transport des Stroms, Datum und Zeit)
    • – Auswählen der Datei(en) zum Übertragen über die Übertragungskonsole
    • – Senden der Datei(en) an den Betreiber über die Konsole
  • Betreiberseite:
    • – Empfang der Dateien; Kontrolle der Übertragungsrechte und der Integrität der Sammlung von Dateien
    • – Analysieren der verwendeten Bezugnahmen und nach Bedarf Melden der Bezugnahmen, die das Senden der Daten erfordern, für die er sich selbst verantwortlich erklärt hat, an den Nutzer
    • – Anwenden der Übertragungskohärenzregeln auf der Ebene des Betreibers
    • – Melden des Kohärenzgrads seiner Daten an den Nutzer
    • – Erzeugung eines Containers oder Wiederverwenden eines vorhandenen Containers für die Bezugnahme auf die externen Daten
    • – Umsetzen der Anwendung vom XTVML-Format in das MPEG-Format des Empfängers/Decodierers
    • – Übertragung der Anwendung
    • – Umsetzung und Übertragung der mit den Standardwerten gefüllten Container
  • Übertragen einer externen Dateneinheit, auf die Bezug genommen wird
    Diese Funktionalität ermöglicht das Übertragen der Dateneinheit, auf die Bezug genommen wird. Hierfür sendet der Inhaltsanbieter an den Betreiber eine XML-Datei, deren Anfangsblock den Stromlokalisierer enthält. Gleichfalls enthält diese Datei die Dateneinheit, die spezifisch an den durch den DataLocator der URI definierten Standort gesendet wird (Xpath-Standard). Eine Analyse dieser Datei am Punkt ihres Empfangs durch den Betreiber ermöglicht durch Untersuchung des StreamLocator die Wiedergewinnung der Sammlung von Containern, die mit diesem Wert des Stromlokalisierers verknüpft sind. Für jeden der Container wird der Wert des DataLocator analysiert und mittels der Xpath-Technologie der Wert der Dateneinheit wiedergewonnen. Dieser Wert wird daraufhin in den Container eingefügt, der schließlich in das MPEG-Format umgesetzt und daraufhin an den SBI gesendet wird.
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
    • – Empfangen der Datei von dem Inhaltsanbieter
    • – Kontrolle der Übertragungsrechte
    • – Analysieren des Stromlokalisierers der Datei
    • – Anfordern der Liste von mit diesem Stromlokalisierer verknüpften Containern
    • – Lesen des Datenlokalisierers jedes Containers und Wiedergewinnen des Werts der Dateneinheit über Xpath
    • – Einfügen des der URI entsprechenden Werts in den Container
    • – Umsetzen des XTVML-Containers in das MPEG-Format des Empfängers/Decodierers
    • – Senden der MPEG-Datei an den SBI
  • Anhalten der Übertragung einer externen Dateneinheit, auf die Bezug genommen wird:
    Diese Funktionalität ermöglicht, dass der Inhaltsanbieter eine Dateneinheit zum Anfordern des Anhaltens seiner Übertragung bereitstellt. In diesem Fall wird der Container, dem die Dateneinheit zugeordnet ist, erneut übertragen, wobei zuvor der Standardwert der Dateneinheit eingefügt worden ist.
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
    • – Auswählen der Dateneinheit, die nicht mehr übertragen wird, über die Übertragungskonsole
    • – Ersetzen der Dateneinheit durch den Standardwert in dem Container unter Verwendung dieser Bezugnahme
    • – erneutes Übertragen der geänderten Container
    • – Benachrichtigen der Nutzer der URI über das Anhalten der Übertragung der Dateneinheit und über das erneute Übertragen des Standardwerts
  • Anhalten eines Szenariums, das eine Bezugnahme auf eine externe Dateneinheit verwendet:
    Diese Funktionalität ermöglicht, dass die Anwendungssteuereinheit das Anhalten der Übertragung der MPEG-Tabellen anfordert, aus denen ein Übertragungsszenarium besteht. Das Übertragungsmanagementsystem listet seine Sammlung von MPEG-Tabellen auf und analysiert, ob jede von ihnen von anderen Anwendungen in dem Prozess, übertragen zu werden, verwendet wird. Gemäß der Situation warnt ein Benachrichtigungssystem den Anforderer des Anhaltens der Übertragung vor der Unmöglichkeit, seine Anforderung zu erfüllen, oder die MPEG-Tabelle wird aus dem Übertragungsstrom entfernt. Im Fall von MPEG-Tabellen, die mit XTVML-Containern verknüpft sind, werden sowohl der Container als auch die Verknüpfungen auf die Bezugnahme, die er enthält, entfernt.
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
    • – Auswählen des Szenariums, das nicht mehr übertragen werden soll, über die Übertragungskonsole
    • – Analysieren der schließlichen Verwendung der MPEG-Tabellen durch andere Anwendungen
    • – Melden des Falls, in dem eine MPEG-Tabelle nicht aus dem Strom entfernt werden kann
    • – Anhalten der Übertragung der entsprechenden privaten Tabellen
    • – Entfernen der zugeordneten gefüllten Container
  • Entfernen einer Bezugnahme auf eine Dateneinheit:
    Diese Funktionalität ermöglicht, dass der Eigentümer einer Bezugnahme sie entfernt. Die Dateneinheit, auf die Bezug genommen wird, kann in der Weise betrachtet werden, dass sie zuvor aus dem Übertragungsstrom entfernt worden ist, was eine Kontrolle über die Übertragung der betroffenen Dateneinheit bedeutet.
  • Eine andere Kontrolle wird verwendet, falls die Bezugnahme gemeinsam genutzt oder gemeinsam nutzbar ist. Der Eigentümer der Bezugnahme wird vor ihrer schließlichen Verwendung durch andere Anwendungen gewarnt. Daraufhin kann er eine Warnung erteilen, diese Bezugnahme nicht zu verwenden, und daraufhin entweder auf grünes Licht für jeden warten oder ein genaues Datum und eine genaue Zeit für die Entfernung der Bezugnahme einstellen. Auf diese Weise kann die Anforderung für die Entfernung differenziert werden.
  • Der spezifisch gesendete Befehl für die Entfernung einer Bezugnahme besteht im Entfernen jeder Spur der Beziehung zwischen der Dateneinheit, ihrer URI, ihren Nutzungsrechten und ihrem logischen Deskriptor.
  • Diese Funktionalität kann die folgenden Aktionen umfassen:
    • – Auswahl einer Bezugnahme
    • – Analyse der Übertragung einer entsprechenden Dateneinheit
    • – Analyse der Verwendung ihrer Bezugnahme durch Anwendungen
    • – Benachrichtigung über die Verwendung
    • – Bestätigung des Datums und der Zeit der Entfernung
    • – Entfernung aller Elemente, die sich auf diese Bezugnahme beziehen
  • Allgemeines Schema der technischen Darstellung:
  • Dieses ist in 8 gezeigt.
  • 8 ist eine allgemeine Übersicht, die bestimmte Komponenten eines Systems, verschiedene Verbindungen zwischen ihnen und verschiedene Datenströme zeigt. Insbesondere sind ein Programmanbieter 500, ein Inhaltsanbieter 502, ein Betreiber 504 und eine Übertragungszentrale 506 gezeigt.
  • Der Programmanbieter umfasst ein Offline-Hilfsmittel 510, das mit einer Ablagevorrichtung 512 verknüpft ist, ein Editierhilfsmittel 514, eine Web-Server-Anwendung 516, eine Übertragungskonsole 518, eine Datenablagevorrichtung 520 und eine Extranet-Vorrichtung 522. Zwischen diesen Komponenten des Programmanbieters sind verschiedene Verbindungen 530, 532, 534, 536, 538 und 540 gezeigt. Der Online-Editor bildet zusammen mit einem Offline-Editor einen Teil des Editierhilfsmittels.
  • Der Inhaltsanbieter 502 umfasst eine Übertragungskonsole 560 und eine Extranet-Vorrichtung 562.
  • Der Betreiber umfasst einen Empfangsdienst 580, einen URI-XTVML-Verarbeitungsdienst 582, einen Übertragungsdienst 584, eine Datenbank für die Speicherung von URIs 586, eine Datenbank für die Speicherung von Containern 588, einen URI-Editor 590 und einen Web-Server 592. Zwischen diesen Komponenten des Betreibers sind verschiedene Verbindungen 600, 602, 604, 606 und 608 gezeigt.
  • Außerdem sind Verbindungen 610, 612 und 614 zwischen dem Web-Server 592 und in dieser Reihenfolge der Web-Server-Anwendung 2516 des Programmanbieters 2500, der Übertragungskonsole 2518 des Programmanbieters 2500 und der Übertragungskonsole 2560 des Inhaltsanbieters 2502 gezeigt. Die Sicherheit wird durch eine Firewall 620 des Betreibers 2504 sichergestellt.
  • Die Übertragungszentrale umfasst einen SBI 640 und einen Empfangsdienst 642. Eine TCP/IP-Verbindung verbindet den SBI 640 mit dem Übertragungsdienst 2584 des Betreibers 2504.
  • Es sind Datenströme 660 (stream(1)), 662 (stream(2)), 664 (stream(3)) und 666 (stream(4)) gezeigt, die im Betrieb zwischen verschiedenen Komponenten des Systems laufen. Die Datenströme werden im Folgenden ausführlicher diskutiert.
  • Es werden nun Aspekte des in der allgemeinen Übersicht gezeigten Systems ausführlicher diskutiert.
  • Das Ziel dieser Architektur ist es zu ermöglichen, dass alle Teilnehmer leicht und effizient kommunizieren. Global kommunizieren drei Teilnehmer untereinander für die Übertragung und für die Auflösung externer Bezugnahmen. Diese Teilnehmer sind der Programmanbieter, der Inhaltsanbieter und der Betreiber. Im ersten Teil dieses Dokuments wird die Rolle von jedem beschrieben.
  • Unter Berücksichtigung dessen, was bereits vorhanden ist, ist die am meisten intuitive Lösung die, die für die Kommunikation auf der COM-Technologie und auf dem HTTP-Protokoll beruht. Der Austausch von Dateien wird durch einen Web-Server ausgeführt, der unabhängig von der Architektur des Clients einfachen Zugriff bietet. Ein einzelner Web-Browser ermöglicht Zugriff auf die notwendigen Daten.
  • Die Rolle des Programmanbieters ist es, eine Sammlung von Daten, die eine interaktive Anwendung beschreiben, zu konstruieren und an den Betreiber zu senden.
  • Zum Editieren hat der Programmanbieter ein Editierhilfsmittel, auf das über einen Web-Browser zugegriffen werden kann, und ein Offline-Hilfsmittel, das größere Editierfunktionalität bietet, zur Verfügung. Es ist dem Programmanbieter überlassen, diejenige Architektur zu wählen, die für ihn die beste ist.
  • Eine dedizierte Konsole ermöglicht die Sendung der zu übertragenden Anwendungsdaten im XTVML-Format an den Betreiber für die Übertragung.
  • Der Inhaltsanbieter überträgt die Ursprungsdaten in einem vorgegebenen XML-Format (siehe oben) an den Betreiber. Diese Übertragung wird mit Hilfe der Übertragungskonsole ausgeführt. Diese Konsole ist eine verkleinerte Version derjenigen, die von dem Programmanbieter verwendet wird. Somit verwendet sie dieselben Kommunikationsbetriebsarten.
  • Um die Übertragung von Daten in regelmäßigen Zeitintervallen zu ermöglichen, kann mit diesem Hilfsmittel eine Ablaufsteuerung verknüpft sein.
  • Die Hauptrollen des Betreibers sind:
    • 1. Empfang und Verarbeitung der Daten. Diese Verarbeitung enthält die Auflösung externer Bezugnahmen.
    • 2. Übertragung der Daten.
  • Die Aufgabe des Empfangs und der Sendung der Daten ist in drei verschiedene Module getrennt
    • – Ein Empfangsdienst der die Rolle hat, Daten von dem Inhaltsanbieter und von dem Programmanbieter zu empfangen und sie nach Integritäts- und Sicherheitskontrollen an ein weiteres Modul zu übertragen.
    • – Ein Verarbeitungsdienst sucht nach Bezugnahmen auf externe Daten und versucht diese logischen Bezugnahmen durch physikalische Bezugnahmen aufzulösen. Hierfür werden eine Datenbank, die die URIs speichert, während sie verwendet werden, sowie eine Datenbank, die zum Speichern der Container dient, verwendet. Ein Container ist ein XTMLV-Container, der für den Empfang einer externen Dateneinheit von dem Inhaltsanbieter bestimmt ist.
    • – Ein Übertragungsdienst. Seine Rolle ist es, die Anwendung im XTVML-Format in das MPEG-Format des Empfängers/Decodierers umzusetzen und die Daten daraufhin an den SBI-Server zu senden.
  • Durch den SBI, der Daten im MPEG-Format und Übertragungsparameter empfängt und diese Daten an eine Übertragungszentrale sendet, wird die Übertragung der Daten sichergestellt.
  • Es werden nun Eigenschaften des Datenstroms ausführlicher diskutiert.
  • Bei der Sendung von Informationen von dem Programmanbieter an den Betreiber ist es die Rolle der Übertragungskonsole, die Daten an den Betreiber zu senden. Diese Konsole kann über einen Web-Server (HTTP/XML) kommunizieren. Die Sicherheit zwischen den zwei Netzen ist durch eine Firewall bei dem Betreiber sichergestellt. Der Web-Server bei dem Betreiber hat die Aufgabe, die Daten im XTVML-Format zu empfangen und sie an den Empfangsdienst zu senden.
  • Das Editierhilfsmittel des Programmanbieters kann ebenfalls die von dem Betreiber kommenden Daten empfangen. Üblicherweise empfängt es die Liste der URIs, die zu verwenden es das Recht hat. Diese Informationen werden an es über denselben Web-Server gesendet wie den, der für das Wiedergewinnen der für den Client geeigneten Bezugnahmen verantwortlich ist.
  • Bei der Sendung der Informationen von dem Inhaltsanbieter an den Betreiber ist die von dem Inhaltsanbieter verwendete Übertragungskonsole eine verkleinerte Version der Konsole, die bei dem Programmanbieter zu finden ist.
  • 9 veranschaulicht den Durchgang von Daten durch das System aus 8 ausführlicher.
  • Bei der Sendung von Informationen von dem Betreiber an die Übertragungszentrale empfängt der Empfangsdienst die Daten im XTVML-Format (in dem Schema stream(1)). Diese Daten kommen direkt von einem bei den Anbietern verwendeten Client oder von einem Web-Server, der daraufhin als eine Verknüpfung dient. Diese Daten werden analysiert und daraufhin erneut an den URI-XTVML-Verarbeitungsdienst gesendet (in dem Schema stream(2)), falls die Integritäts- und Sicherheitskontrollen positiv sind. Dieser 'Verarbeitungsdienst'-Server löst die externen Bezugnahmen auf, wobei der gesamte XTVML-Strom an den Übertragungsdienst gesendet wird (in dem Schema stream(3)), wenn alle aufgelöst worden sind. Dieser Übertragungsdienst wandelt diese XTVML-Daten in das für den Empfänger/Decodierer bestimmte MPEG-Format um und kommuniziert daraufhin über einen (TCP/IP)-Socket mit dem SBI-Server.
  • Im Folgenden werden ausführliche Beschreibungen in Bezug auf die Datenaustauscherfunktionalität, d. h. auf das Modul, das für die Auflösung von Datenbezugnahmen innerhalb XTVML-Dateien und innerhalb der Anwendung verantwortlich ist, gegeben.
  • Für jeden der innerhalb dieses Dokuments beschriebenen Nutzungsfälle wird ein allgemeines Nutzungsfalldiagramm als ein Folgediagramm dargestellt. Daraufhin wird jede Aktion genau geschildert und werden konkrete Beispiele für die Manipulation von Daten gegeben.
  • Im Kontext des Anwendungsrahmens kann der Begriff der Bezugnahme auf Daten in dem Sinn eine Schlüsselrolle spielen, dass er ermöglicht, dass der Inhalt von Daten (Text oder Bild) von ihrer Darstellung auf dem Bildschirm klar getrennt wird. Um eine Dateneinheit zuzuweisen, verwendet das Editierhilfsmittel (Programmanbieter) eine URI (Uniform Resource Identifier), die in das XTVML-Format das Objekt einfügt, das es anzeigen muss. An diesem Ende hat der Inhaltsanbieter die Rolle, Dateien zu senden, die die Daten enthalten, und sie mit Hilfe ihrer URI zu vereinbaren. Der Datenaustauscher ist selbst verantwortlich für die MPEG-Umsetzung und für die Übertragung von XTVML-Objekten und externen Daten. Darüber hinaus ist er verantwortlich für das Einfügen der Daten, auf die Bezug genommen wird, in die XTVML-Objekte, wobei dieser Mechanismus auf der Ebene des Empfänger/Decodierers wegen seiner beschränkten Verarbeitungskapazität nicht implementiert werden kann.
  • Es werden nun Nutzungsfälle beschrieben; zunächst die Definition und die Nutzung von Systembetriebsmitteln durch die Anwendung:
    10 ist ein allgemeines Diagramm, das die Definition und die Implementierung der Systembetriebsmittel durch die Anwendung veranschaulicht. Insbesondere und wie im Folgenden beschrieben wird, veranschaulicht sie die Beziehung zwischen dem Inhaltsanbieter 1100, dem TV-Betreiber 1102 und einem Programmanbieter 1104 sowie verschiedene Konzepte oder Prozesse, die eine Definition von Kategorien von Daten 1110, eine Definition des nutzbaren Durchlassbereichs 1112, eine technische Konfiguration der Übertragung 1114 und eine Zuordnung von Stromlokalisierern 1116 umfassen.
  • 11 ist ein Folgediagramm, das sich ebenfalls auf die Definition und Implementierung der Systembetriebsmittel durch die Anwendung bezieht. Es ist erneut die Beziehung zwischen einem Inhaltsanbieter 1200, einem TV-Betreiber 1202 und einem Programmanbieter 1204 veranschaulicht, wobei außerdem die Folge der Ereignisse gezeigt ist, die eine Definition von Kategorien von Daten 1210, 1212, eine Definition des Durchlassbereichs 1214, eine technische Konfiguration der Übertragung 1216 und eine Zuordnung von Stromlokalisierern 1218 umfassen.
  • Die obigen Merkmale, die sich auf die Definition der Kategorien von Daten, auf die Definition eines erforderlichen Durchlassbereichs und auf die technische Konfiguration der Übertragung beziehen, werden nun ausführlicher beschrieben.
  • Der Inhaltsanbieter bestimmt die Kategorien der Daten, die zu dem Betreiber gebracht werden. Diese Kategorien können mit Datentypen, aber gleichfalls mit Stoffen oder Themen verknüpft sein. Tatsächlich sind dies die Übertragungsbeschränkungen, die die Definition dieser Kategorien vorschreiben (physikalischer Ursprung der Daten, Übertragungshäufigkeit, Sammlung von Daten, die denselben Nutzungsrechten entsprechen).
  • Somit kann der Betreiber in Bezug auf die Programmanbieterdaten betrachten, dass es sich ergibt, dass in der Mehrzahl der Fälle die Gesamtheit der verschiedenen XTVML-Objekte zu verwenden ist.
  • Ein wichtiger Parameter im Kontext einer Anwendung, die externe Daten verwendet, liegt in der Vorhersage der Menge dieser Daten, die gleichzeitig übertragen werden. Somit ist es notwendig, die maximale Menge zu übertragender Daten sowie die Inhaltsseite des Programmanbieters zu kennen. Hierfür steht dem Programmanbieter ein Modul zur Verfügung, um die globale Menge von Dateien zu berechnen, die ein Szenarium bilden, was es ihm ermöglicht, die Größe eines Szenariums zu kontrollieren, das er erzeugt. Für die Kontrolle der Bitrate auf der Übertragungsebene ist der Datenaustauscher selbst verantwortlich.
  • Technische Konfiguration der Übertragung: Das Ziel dieser Phase ist das Speichern der Sammlung von Parametern, die für die Übertragung aller Tabellen notwendig sind, die sich auf eine Anwendung dieses Typs beziehen, in einer XML-Datei 'Diffusions.xml'. Hierfür wird eine Sammlung technischer Parameter vereinbart, die die Übertragung jeder Dateneinheit betreffen. Diese Sammlung von Daten ist in einem <diffusion>-Element enthalten, das durch den Wert des Attributs 'diff_id' identifiziert ist. Es ist wichtig anzumerken, dass die Datei 'Diffusion.xml' so viele verschiedene <broadcast>-Blöcke umfasst, wie es Typen von Übertragungen für eine Anwendung gibt. Üblicherweise kann eine Anwendung 2 Übertragungskanäle haben: den ersten für interne Tests und den zweiten für echte Übertragungen.
  • In Bezug auf den Abschnittsübertragungsinjektor: Für den Betreiber besteht der erste Punkt angesichts der zuvor definierten Kategorien von Daten im Wesentlichen darin, einen oder mehrere SBI für die Übertragung zu beeinflussen. Für jeden von diesen ist es notwendig, den Fluss auf optimale Weise zu überwachen und zu regulieren.
  • Für die Datei 'Diffusion.xml' wird z. B. die folgende Liste erhalten:
    Figure 00450001
  • Es wird auf die Anwesenheit eines Attributs 'sbi_id' hingewiesen, das zum eindeutigen Identifizieren eines SBI in der Menge von Dateien verwendet wird.
  • In Bezug auf die PID wird die in jedem SBI nutzbare Anzahl der PID wie folgt definiert:
    Figure 00450002
  • In Bezug auf die TID und auf jede Zykluszeit sind schließlich die Tabellentypen mit einem bestimmten TID- Wert, insbesondere mit einer bestimmten PID, verknüpft, was als ein konkretes Beispiel für die Sammlung von XTVML-Objekten Folgendes ergibt:
    Figure 00460001
  • Wenn diese Datei aktualisiert worden ist, wird sie durch den Betreiber in dem Index von Daten der betroffenen Anwendung gespeichert.
  • Erzeugung einer Bezugnahme auf eine Dateneinheit
  • Im Folgenden wird die Erzeugung der Bezugnahme auf eine Dateneinheit beschrieben.
  • 12 ist ein allgemeines Diagramm, das die Erzeugung einer Bezugnahme auf eine Dateneinheit veranschaulicht. Insbesondere sind die Beziehung, die zwischen einem Inhaltsanbieter 1300, einem Programmanbieter 1304 und einem Datenaustauscher 1306 besteht, sowie die verschiedenen Prozesse des Erzeugens oder Auswählens einer Datei, die die Bezugnahme enthält 1310, des Benennens des Datenelements 1312, der logischen Beschreibung 1314, der Auswahl eines Datenelements für die Bezugnahme 1316, des Definierens der Nutzungsrechte 1318, des Sendens der Datei 1320, des Speicherns der Bezugnahme 1322 und des Sendens der Bezugnahmen 1324, veranschaulicht.
  • 13 ist ein Folgediagramm, das ebenfalls die Erzeugung einer Bezugnahme auf eine Dateneinheit veranschaulicht. Es ist die Folge von Ereignissen gezeigt, die sich auf einen Inhaltsanbieter 1400, auf einen Programmanbieter 1404, auf einen Datenaustauscher 1406 und auf eine XML-Datendatei 1408 beziehen, wobei die Ereignisse insbesondere das Auswählen eines Datenelements 1410, das Zuordnen eines Stromlokalisierers 1412, das Auswählen oder Erzeugen einer XML-Datei für den Transport von Bezugnahmen 1414, das Einfügen der Bezugnahme und ihrer Attribute in das XML-Modul 1416, die Definition und das Einfügen der Nutzungsrechte 1418, die Überprüfung 1420, das Senden einer Datei 1422, die Speicherung 1424 und die Filterung der Rechte und das Senden 1426 umfassen.
  • Im Folgenden werden nun ausführlicher Merkmale beschrieben, die sich auf das Auswählen einer Dateneinheit, auf das Zuordnen eines Stromlokalisierers, auf das Auswählen oder Erzeugen einer XML-Datei für den Transport von Bezugnahmen, auf das Einfügen der Bezugnahme in das Modul, auf das Beschreiben der Daten, auf das Definieren der Nutzungsrechte, auf das Senden der XML-Datei, auf das Speichern der Bezugnahme und auf das Filtern und Senden der XML-Datei an das Editierhilfsmittel des Programmanbieters beziehen.
  • Auswahl einer Dateneinheit: Zuallererst entscheidet der Inhaltsanbieter über die Sammlung von Daten, auf die Bezug genommen werden soll. Diese Entscheidung kann teilweise mit dem Programmanbieter, der in Begriff ist, sie in das Szenarium integrieren zu müssen, und teilweise mit dem Betreiber, der die Menge der zu übertragenden Daten hinsichtlich der Bandbreite genehmigt, gemeinsam getroffen werden.
  • Zuordnung eines Stromlokalisierers: Das Datenelement wird mit einem der Stromlokalisierer verbunden, die dem Inhaltsanbieter zugeordnet sind. Hierfür besitzt der Inhaltsanbieter die Liste seiner Stromlokalisierer und wählt einen darunter aus.
  • Auswählen oder Erzeugen einer XML-Datei für den Transport von Bezugnahmen: Jedem Stromlokalisierer entspricht eine eindeutige Datei 'Reference_Definition.xml', für die das Wurzelelement ein 'stream_locator'-Attribut besitzt, das seinen Wert hat. Diese Datei wird in der Definition der Bezugnahmen zum Beschreiben der Sammlung ihrer Parameter verwendet, jedoch gleichfalls, um die zugeordneten Daten positiv an die Bezugnahmen zu senden.
  • Ihre Struktur ist wie folgt:
    Figure 00490001
  • Es werden nun die Elemente beschrieben:
    <licenses>: Es enthält die <license>-Elemente, die ein 'appli_id'-Attribut besitzen, das die Kennung einer Anwendung oder eines Programmanbieters angibt, die/der zur Verwendung der in der Datei enthaltenen Bezugnahmen berechtigt ist. Es sind so viele <license>-Elemente zu finden, wie es zur Verwendung dieser Bezugnahmen berechtigte Anwendungen gibt.
  • <data>: Es enthält so viele <datum>-Elemente wie Daten, auf die in der Datei Bezug genommen wird.
  • <datum>: Es besitzt mehrere Attribute. 'data_locator' enthält den zu dem Stromlokalisierer komplementären Wert, um die URI der Dateneinheit zu bilden. 'descr' enthält die logische Beschreibung der Dateneinheit. 'datatype' spezifiziert, ob es eine Dateneinheit des redaktionellen Datenlistentyps, ein MPEG-Bild oder ein Textblock (in dieser Reihenfolge 'datalist', 'picture' oder 'text') ist. 'frequency' spezifiziert, ob die Dateneinheit mit einer hohen Häufigkeit gesendet wird ("im Streaming-Betrieb" oder "normal"). Tatsächlich gibt dieses Attribut an, ob der Decodierer die Versionen des XTVML-Objekts untersuchen muss, das die Übertragungsdateneinheit enthält, um den Bildschirm ohne Aktion über die Fernbedienungseinheit direkt aufzufrischen. Falls die Bezugnahmedateneinheit ein Bild ist, muss der Inhaltsanbieter gleichfalls die Bildabmessungen, d. h. die Attribute 'width' und 'height', liefern.
  • CDATA-Abschnitt: Er enthält den Standardwert der Dateneinheit, entweder den gesamten Textblock oder den Namen der Datei, die das MPEG-Bild enthält. Dies ermöglicht, dass ein XTVML-Objekt auf eine Dateneinheit Bezug nimmt, um den Inhalt seiner ersten Übertragung, der Standardwerte sein können, anzeigen zu können. Aus diesen Gründen muss der Wert gefüllt sein, während die Bezugnahme ansonsten durch den Datenaustauscher vollständig zurückgewiesen wird und die Standardwerte verwendet werden.
  • XML-Block: In bestimmten Fällen, in denen die Objekte auf eine Liste von URIs Bezug nehmen, besteht der XML-Block aus verschiedenen Unterelementen, die jede der URIs beschreiben. Eine Verwendung des Typs Xpath oder XMLQuery ermöglicht dann die Navigation in diesem Block, um die Werte der URIs schnell aufzufinden. Es werden zwei Typen von Datenlisten unterschieden. Der erste ist der Typ 'DataList' und entspricht dem PageSet-Objekt:
    Das <datum>-Element besitzt mehrere Elemente <title>, <body>, <picture> und <picture_legend>. Jedes dieser Elemente enthält ein Element vom Typ Abschnittsdaten, das den Inhalt der Dateneinheit repräsentiert, auf die Bezug genommen wird.
  • Der Zweite ist der 'catalogue'-Typ und entspricht dem Menü-Objekt:
    Figure 00510001
    Figure 00520001
    Figure 00530001
  • Es wird hier auf die Anwesenheit mehrerer <item>-Elemente, die jeweils die gleichen Datentypen wie zuvor enthalten, und außerdem auf den Kopftext und auf die Anordnung des entsprechenden Menüs hingewiesen.
  • Einfügung des Bezugnahmeelements: Tatsächlich wird ein Bezugnahmeelement durch ein <datum>-Element dargestellt, das in dem <data>-Element der XML-Datei enthalten ist. Auf diese Weise begleitet jede Vereinbarung einer neuen Bezugnahme durch den Inhaltsanbieter die Einführung eines <datum>-Elements in die in den Speicher geladene Datei 'Reference_definition.xml'. Daraufhin aktualisiert sie die Sammlung von Attributen dieses Elements.
  • Dateneinheitsbeschreibung: Das <descr>-Attribut wird mit dem Text aktualisiert, der die Dateneinheit kurz beschreibt.
  • Definition der Nutzungsrechte: Diese Phase besteht im Einfügen eines <license>-Elements für jede Anwendung oder für jeden Programmanbieter, die/der berechtigt ist, die Dateneinheit zu verwenden. Es ist das <appli_id>-Attribut, das mit der Kennung der verwendenden Anwendung aktualisiert wird.
  • Es ist wichtig anzumerken, dass die Rechte für alle Dateibezugnahmen und nicht auf der Ebene der einzelnen Dateneinheiten gemanagt werden. Andererseits ist die erste Version des Datenaustauschers dafür bestimmt, immer nur durch eine Anwendung verwendet zu werden. Somit sind die von den Inhaltsanbietern kommenden Dateien a priori alle durch den Programmanbieter verwendbar.
  • Senden der XML-Datei: Wenn die Sammlung von Parametern aktualisiert worden ist, wird die XML-Datei durch den Betreiber gespeichert. Beispielhaft kann die Datei 'Reference_definition.xml' vorgeschlagen werden:
    Figure 00540001
    Figure 00550001
    Figure 00560001
  • Sie bildet gleichfalls jedes der <datum>-Elemente auf die Beschreibung seiner entsprechenden Dateneinheit ab, sodass die XML-Datei während der aufeinanderfolgenden Sendungen mit Hilfe der aufgefrischten Dateneinheit richtig aktualisiert werden kann.
  • Daraufhin kann der Inhaltsanbieter die so erzeugte Datei 'Reference_definition.xml' über das HTTP-Protokoll (Anforderung vom 'post'-Typ) an den Betreiber senden. Eine strenge Authentisierung des Inhaltsanbieters ermöglicht in den zwei Fällen, dass die Berechtigung des Datenaustauschers die Datei, die die Liste von Bezugnahmen enthält, berücksichtigt.
  • Speicherung der Bezugnahme: Jedes <datum>-Element wird beim Empfang der Datei 'Reference_definition.xml' durch den WEB-Server des Datenaustauschers analysiert. Daraufhin wird durch Verketten des Werts des 'stream_locator'-Attributs des Wurzelelements mit dem 'data_locator'-Attribut der <datum>-Elemente die URI der Bezugnahme rekonstruiert. Daraufhin wird gemäß dem <application>-Element, das ein 'appli_id'-Attribut besitzt, das gleich einem der Werte desselben Attributs der <license>-Elemente der Datei 'Reference_definition.xml' ist, ein <reference>-Element in die Datei 'References.xml' eingefügt. Dieses <reference>-Element besitzt ein 'uri'-Attribut, das die rekonstruierte URI enthält, ein 'descr'-Attribut, das die logische Beschreibung wiederholt, und schließlich im Fall von Bildern die zwei Abmessungsattribute 'width' und 'height'. Außerdem enthält es einen CDATA-Abschnitt, der den Standardwert der Dateneinheit repräsentiert. Beim Wiederholen der in der früheren Datei 'Reference_definition.xml' vereinbarten Bezugnahmen wird Folgendes erhalten:
    Figure 00570001
    Figure 00580001
  • Diese Datei 'References.xml' wird durch den Betreiber in dem Index der Bezugnahmen gespeichert. Diese Datei ist einzigartig und enthält die Sammlungen von durch alle Inhaltsanbieter vereinbarten Bezugnahmen.
  • Filtern und Senden der XML-Datei an das Editierhilfsmittel des Programmanbieters: Zum Senden der Liste verwendbarer Bezugnahmen an ein Editierhilfsmittel ist es anfangs empfehlenswert, auf die Datei 'References.xml' ein Filter anzuwenden und nur den XML-Block des <application>-Elements auszuwählen, das den richtigen Wert seines 'appli_id'-Attributs besitzt.
  • Somit werden die Standardwerte der Bezugnahmen an den Programmanbieter gesendet, der sie durch das Editierhilfsmittel darstellen kann. Die Dateien, die Bildern entsprechen, werden ebenfalls gesendet. Für diese ermöglicht ein iteratives Lesen des Werts des CDATA-Abschnitts der Elemente vom 'picture'-Typ, den Namen der Bilddatei zu erhalten und ihn an den Programmanbieter zu senden.
  • Übertragung eines Szenariums
  • Es wird nun die Übertragung eines Szenariums ausführlicher beschrieben.
  • 14 ist ein allgemeines Diagramm, das die Übertragung eines Szenariums veranschaulicht. Es sind ein Programmanbieter 1504 und ein Datenaustauscher 1506 sowie verwandte Prozesse, die das Empfangen von Szenariumdateien 1510, das Lesen der Daten, Betreiber 1512, das Lesen der XTVML-Dateien 1514, das Ersetzen der URIs des XTVML-Objekts durch ihre SBI-Parameter 1516, das Ersetzen der URIs der Daten durch ihre SBI-Parameter 1518, das Erzeugen von Datencontainern mit den Standardwerten 1520, das Aktualisieren des Datenleiters mit den Informationen 1522, das Umsetzen der XTVML-Dateien in das MPEG-Format 1524; Übertragen der MPEG-Tabellen 1526 und schließlich das Anhalten der Objekte des vorherigen Szenariums 1528 und das Senden einer Benachrichtigung über die Übertragung 1530 umfassen, gezeigt.
  • 15 ist ein Folgediagramm, das ebenfalls die Übertragung eines Szenariums veranschaulicht. Es ist die Folge von Ereignissen gezeigt, die sich auf einen SBI 1600, auf einen Betreiber 1602, auf einen Programmanbieter 1604, auf einen Datenaustauscher 1606, auf XTVML-Dateien 1608 und auf die Container 1610 beziehen, wobei die Ereignisse insbesondere die Einfügung 1620, das Senden 1622, die Identifizierung 1624, das Lesen der URI der Datei 1626, das Laden der XTVML-Datei 1628, die Analyse der URI 1630, die Zuweisung der Übertragungsparameter 1632, die Ersetzung der URI durch die Übertragungsparameter 1634, das Lesen des Inhalts einer XTVML-Objektdatei 1636, das Senden der URI der Dateneinheit, auf die Bezug genommen wird, 1638, die Analyse der URI 1640, die Erzeugung eines zugeordneten Containers des Typs der Dateneinheit 1642, die Einfügung des Standardwerts 1644, die Zuweisung der Übertragungsparameter 1646, den Ersatz der URI durch die Übertragungsparameter 1648, die Einfügung der Containerdatei in dem Betreiber, das Lesen [Suchen nach fertiger URI] 1652, die MPEG-Umsetzung 1654, die Übertragung der MPEG-Tabelle 1656, das Anhalten der Übertragung von Objekten des vorherigen Szenariums 1658 und die Benachrichtigung 1660 umfassen.
  • Im Folgenden werden ausführlicher Merkmale beschrieben, die sich auf das Empfangen von Szenariumdateien, auf die Identifizierung, auf das Lesen von Elementen des Datenbetreibers, auf die Analyse der URI eines XTVML-Objekts und auf die Zuweisung von Übertragungsparametern, auf den Ersatz der URI durch den Übertragungsparameter, auf das Lesen des Inhalts einer XTVML-Objektdatei, auf die Erzeugung und Änderung eines Containers, auf die Zuordnung von Übertragungsparametern, auf den Ersatz der URI durch Übertragungsparameter, auf die Einfügung des Standardwerts, auf die Einfügung eines Containers in dem Datenbetreiber, auf die MPEG-Umsetzung der XTVML-Dateien, auf die Übertragung an den SBI, auf das Anhalten der Übertragung von Objekten von einem früheren Szenarium und auf die Benachrichtigung beziehen.
  • Empfangen der Dateien eines Szenariums: Ein Szenarium besteht aus verschiedenen XTVML-Dateien, die in einer einzigen XML-Datei gespeichert sind. Diese Operation ist auf der Ebene des Editierhilfsmittels lokalisiert. Diese 'Conductor.xml' genannte Datei besteht aus so vielen <table>-Elementen, wie es XTVML-Dateien in dem Szenarium gibt. Jedem dieser <table>-Elemente werden ein 'uri'-Attribut, das die eindeutige Unterscheidung der Dateien ermöglicht, sowie ein Unterelement vom CDATA-Abschnitt-Typ, das die gesamte betroffene XTVML-Datei enthält, zugeordnet.
  • Dieser Leiter hat die folgende Form:
    Figure 00610001
  • Es ist diese Datei, die durch ein Schiebesystem über HTTP durch das Editierhilfsmittel an den Datenaustauscher gesendet wird. Bei ihrem Empfang wird diese Datei in den Speicher DOM geladen und daraufhin analysiert.
  • Weitere Dateien können gleichfalls an den Datenaustauscher gesendet werden, wobei diese die MPEG-Bilder sind, die den in bestimmten XTVML-Objekten verwendeten Standardbildern entsprechen. Diese Dateien werden direkt an den Datenaustauscher gesendet und daraufhin in einem Vorrat, der spezifisch für die Client-Anwendung ist, unter einem durch diesen selben Client vereinbarten bestimmten Namen gespeichert.
  • Falls für diese Anwendung bereits eine Datei 'Conductor.xml' vorhanden ist (d. h., falls ein Szenarium gerade übertragen wird), wird diese vorhandene Datei in 'Conductor.old.xml' umbenannt. Die Nützlichkeit dieser Aktion wird im Folgenden beschrieben.
  • Identifizierung: Wenn der Betreiber die Daten mittels eines XML-Parsers in den Speicher geladen hat, besteht eine erste Phase in der Analyse ihrer Herkunft, die durch das Lesen des 'appli_id'-Attributs bekannt ist, das Informationen über die Identität der Eigentümeranwendung der Daten gibt.
    <conductor appli_id="mag+"diff_id="mag+_test"name='test1'start_date="01/10/2000 20:00">
  • Daraufhin wird diese Kennung im Speicher gespeichert.
  • Lesen der Elemente des Datenleiters: Diese iterative Aktion besteht im Lesen jedes der <table>-Elemente des Leiters und direkter im Laden des Inhalts der XML-Datei dank des Werts des 'uri'-Attributs in DOM. Außerdem ermöglich das Lesen des 'uri'-Attributs angesichts seines Stromlokalisierer, seinen XML-Objekttyp zu kennen.
    <table uri="mag+/screen_1"/>
  • Analyse der URI eines XTVML-Objekt und Zuweisung von Übertragungsparametern: Beim Beurteilen der Datei 'Diffusions.xml' wird der XML-Block isoliert, der sich auf das <conductor>-Element bezieht, das einen Wert des 'diff_id'-Attributs besitzt, der gleich dem des 'diff_id'-Attributs des <conductor>-Elements der Datei 'Conductor.xml' ist. Daraufhin wird die erste der zwei Dateneinheiten wiedergewonnen, die für die Identifizierung dieses Objekts in dem Übertragungsstrom notwendig sind, um seine TID zu kennen. Hierfür wird nach dem 'object'-Element gesucht, das einen Wert des 'type'-Attributs hat, der gleich dem ist, der in dem Stromlokalisierer der URI des Objekts gefunden wird. Beim Lesen des Werts des 'tid'-Attributs wird daraufhin die TID erhalten.
  • Figure 00630001
  • Die TIDExt wird selbst durch einen internen Zähler erzeugt, der beim Start jedes neuen Szenariumempfangs auf Null zurückgesetzt wird.
  • Ersatz der URI durch die Übertragungsparameter: Im Anfangsblock der XTVML-Objektdatei wird das 'uri'-Attribut entfernt, woraufhin zwei neue Attribute 'tid' und 'tidext' mit den in der vorherigen Phase erhaltenen Werten eingefügt werden. Diese Änderung wird in dem Element vom Typ CDATA- Abschnitt in der empfangenen Datei 'Conductor.xml' gespeichert.
  • Es folgt ein Beispiel einer XTVML-Datei des Bildschirm-Objekts:
    • – vorher:
      Figure 00640001
    • – nachher:
      Figure 00640002
  • Lesen des Inhalts einer XTVML-Objektdatei: Mit dem Inhalt einer XTVML-Datei, die in DOM geladen wird, ermöglicht eine iterative Analyse, dass jede Verwendung einer Datenbezugnahme identifiziert wird. Hierfür wird nach jedem der Elemente gesucht, die ein 'uri'-Attribut besitzen. Daraufhin werden die Werte dieser URIs analysiert, um den Typ des Elementarobjekts zu identifizieren, das die Daten transportiert, woraufhin der zugeordnete Container erzeugt wird. Es werden mehrere Fälle von Bildern unterschieden, die jeweils einem bestimmten Containertyp entsprechen.
  • Für ein Bild:
    Figure 00650001
  • Das 'uri'-Attribut repräsentiert hier die Bezugnahme auf ein Bild.
  • Es ist hier wichtig anzumerken, dass es nicht notwendig ist, einen Container zu erzeugen, falls das Bild durch die Anwendung selbst gemanagt wird. Tatsächlich wird dies in dem Datenleiter vereinbart, woraufhin durch eine URI darauf Bezug genommen wird, deren Stromlokalisierer einen Wert 'appli_id' hat. Somit gibt es keinen Fall einer Erzeugung eines neuen Containers.
  • Hinsichtlich des PageSet wird die URI, die auf den Text Bezug nimmt, auf der Ebene eines in dem <page>-Element enthaltenen <text_line>-Elements vereinbart. Es wird hier angemerkt, dass das Editierhilfsmittel lediglich Informationen hinsichtlich einer einzelnen Seite zu geben braucht, falls das PageSet auf ein Datenelement vom Typ Text Bezug nimmt. Es ist der Datenaustauscher, der dafür verantwortlich ist, dass das Seitenmodell so oft dupliziert wird, wie es angesichts der Länge des Texts nach seiner Formatierung notwendig ist. Tatsächlich ermöglicht das Lesen der Werte der Breite und der Höhe des Textblocks auf der Seite die Berechnung seiner Aufteilung auf mehrere Seiten. Gleichfalls kann spezifiziert werden, dass die erste Seite des PageSet eine Bezugnahme auf ein externes Bild enthalten kann. In diesem Fall wird das Bild mit denselben Größen- und Positionseigenschaften auch auf alle Seiten dupliziert. Die Struktur eines PageSet hat die folgende Struktur:
    Figure 00660001
  • Hinsichtlich des Menüs ist das Prinzip für das Menü, ihm eine eindeutige URI der Typliste, deren Wert die Sammlung von Informationen hinsichtlich der verschiedenen Elemente in dem Menü enthält, und des zum Anzeigen der redaktionellen Daten verwendeten PageSet zuzuordnen. Die URI ist auf der Ebene des <items>-Elements vorhanden. Hier kann berücksichtigt werden, dass das <items>-Element nur ein einzelnes <item>-Element enthält. Ausgehend davon, dass jedes der Elemente in dem Menü auf denselben Typ von PageSet zeigt, reicht es tatsächlich aus, nur die graphischen Eigenschaften für ein einzelnes Element zu definieren. Ein Duplizierungssystem ermöglicht dann, in Übereinstimmung mit den Mengenbeschränkungen des Systems so viele Menüeinträge einzufügen, wie in Bezug auf den Inhalt der URI notwendig sind.
  • Das <menu>-Objekt kann in der folgenden Form dargestellt werden:
    Figure 00670001
    Figure 00680001
  • Hinsichtlich des PageSet erfordert diese Datei keine Einzelbehandlung, da sie gleichzeitig geladen wird, während das zugeordnete Menü gelesen wird. Somit wird die Suche nach <uri>-Elementen für diesen Dateityp nicht durchgeführt.
  • Erzeugung/Änderung eines Containers: Der Container ist tatsächlich eine XTVML-Datei, die durch eine TID/TIDExt identifiziert ist, die die Daten an sich enthalten sollte. Es ist möglich, verschiedene Containerstrukturen zu unterscheiden:
    Hinsichtlich des Bildcontainers wird dieser Container vollständig aus der Vereinbarung einer URI in einem <picture_description>-Element erzeugt. Somit wird z. B. Folgendes erhalten:
    Figure 00690001
  • Das <data>-Element enthält ein einziges <picturefile>-Element, das ein 'value'-Attribut besitzt, dessen Wert auf eine MPEG-Bilddatei Bezug nehmen muss.
  • In Bezug auf den PageSet-Container wird dieser Container tatsächlich vollständig aus einer in dem Datenleiter gesendeten <pageset>-Datei kopiert.
  • Figure 00700001
  • Figure 00710001
  • Das <pageset>-Element enthält mehrere Elemente, die Informationen über die graphische Darstellung (Position, Größe, Farben usw.) geben, und ein <pages>-Element, das selbst ein <page>-Element enthält. Dieses <page>-Element, das das Modell der Seite repräsentiert, besitzt ein <text_lines>-Element und/oder ein <picture_description>-Element, das auf ein externes Textstück bzw. Bild Bezug nimmt. Falls die URI auf ein Textstück Bezug nimmt, wird der Text abgerufen, damit er direkt in die PageSet-Datei eingefügt wird. Andererseits wird im Fall einer Bezugnahme auf ein Bild wie oben beschrieben ein Container vom <picture>-Typ erzeugt.
  • In Bezug auf das Menü wird der dem Menü zugeordnete Container abgesehen davon, dass das 'uri'-Attribut des <menu>-Typs durch das Attributpaar 'tid' und 'tidext' ersetzt ist, wie für das PageSet vollständig aus der XTVML-Menüdatei kopiert.
  • Figure 00720001
  • Figure 00730001
  • Darüber hinaus wird in dieser Phase der Inhalt der PageSet-Datei wiedergewonnen, die mit der in dem <next_object>-XML-Block definierten URI verknüpft ist. Dies ermöglicht, dass ein Container erzeugt wird, der als ein Modell für die Erzeugung jeder der den Menüelementen entsprechenden PageSets dient. Die PageSet-Datei ist abgesehen davon, dass ihre TidExt in Bezug auf das Menüelement, das seine Anzeige veranlasst, veränderlich ist, ähnlich der oben definierten PageSet-Datei. Außerdem wird angemerkt, dass die in dem PageSet auf der Ebene des Bilds und des Textblocks definierten URIs gleich sind und direkt auf den vollständigen Block der Datenliste Bezug nehmen.
  • Figure 00730002
  • Figure 00740001
  • Außerdem wird angemerkt, dass diese zwei Container (Menu und PageSet) im Laufe der Zeit verknüpft bleiben, was die Umgruppierung auf der Ebene des Datenleiters bedeutet. Dieser Punkt wird im Folgenden ausführlicher diskutiert.
  • Bei der Erzeugung wird der Container in den Speicher geladen, wobei darauf geachtet wird, ihm die URI der Daten zuzuordnen, auf die Bezug genommen wird.
  • Zuweisung der Übertragungsparameter: Das Lesen der Datei 'Diffusion.xml' ermöglicht, dass der Wert der dem Containertyp entsprechenden TID wiedergewonnen wird, wobei der Zähler TIDExt den Wert gibt. Dieses Paar wird daraufhin verwendet, um Informationen hinsichtlich der Attribute TID und TIDExt des Containers zu ermitteln. Zum Beispiel wird für einen Bild-Typcontainer Folgendes erhalten:
    Figure 00750001
  • Ersetzen der URI durch die Übertragungsparameter: Diese Operation ist gleich der in dem Absatz hinsichtlich des Inhalts einer XTVML-Objektdatei dargestellten. In dem oben gegebenen Beispiel gibt das Folgende die Beschreibung eines Bilds auf einem Bildschirm:
    Figure 00750002
  • Einfügung des Standardwerts: Der Begriff des Standardwerts ermöglicht, den Container mit einem realen Datenelement zu übertragen, das auf der Ebene des Empfängers/Decodierers angezeigt werden kann, wobei dies nicht das Senden der Daten durch den Inhaltsanbieter berücksichtigt. Diese Tatsache ermöglicht, XTVML-Objekte, die das Szenarium umfassen, ohne das Risiko eines Problems 'defekter Verknüpfungen' zusammen zu übertragen.
  • Wenn die Struktur des Containers erzeugt worden ist, ermöglicht das Lesen des Standardwerts in der Datei 'Reference.xml', dass der Inhalt durch einen konkreten Wert ersetzt wird.
  • In Bezug auf den Bildtyp gibt das Lesen des Inhalts des CDATA-Abschnitt-Typelements den Namen der MPEG-Bilddatei. Diesem Wert geht die Zeichenfolge voran, die den lokalen Index angibt, wo die Bilddatei zur Zeit ihres Empfangs von dem Datenaustauscher gespeichert worden ist, woraufhin sie in das 'value'-Attribut des <picturefile>-Elements eingefügt wird. Schließlich wird Folgendes erhalten:
    Figure 00760001
  • Wie zuvor erläutert wurde, managt der Fall der Bezugnahme in dem PageSet eines dynamischen Bilds in Bezug auf den PageSet-Typ erneut einen autonomen Bild-Typcontainer. Somit wird die Behandlung des Standardwerts im Kontext eines <picture>-Typcontainers bewirkt.
  • Soweit es die Bezugnahme auf einen Ursprungstextblock betrifft, gibt das Lesen des Inhalts eines CDATA-Abschnitt-Typ-Bezugnahmeelements die Sammlung von Text, ohne ihn zusammenzusetzen. Aus Gründen der Leistung in dem Empfänger/Decodierer wird die Zusammenfügung der Textblöcke auf der Datenaustauscherebene ausgeführt. Hierfür besteht die erste Phase im Wiedergewinnen der Parameter der Anzeigegröße, d. h. <width> und <height>, in dem XTVML-Objekt, das den Textblock anzeigt. Daraufhin muss ein Modul zulassen, dass die Sammlung von Text in Abhängigkeit von der Breite und von der Höhe des PageSet-Objekts und in Abhängigkeit von der Zeichensatzgröße (18 oder 21) geschnitten wird. Dieses Modul berücksichtigt ebenfalls die Ausrichtung (rechts, links, Blocksatz). Im Fall von Blocksatz können Zwischenräume zwischen Wörtern hinzugefügt werden. Darüber hinaus werden die Textlinien in den Datenabschnitt eingefügt, was die Verwendung von Zeichen ermöglicht, die in der Schreibweise der Sprache XML normalerweise reserviert sind. Beispielhaft wird z. B. der folgende Dateityp erhalten:
    Figure 00780001
    Figure 00790001
  • In Bezug auf den Menu-Typ ist dem Menü, wie zuvor diskutiert wurde, eine eindeutige URI zugeordnet. Der Wert dieser URI ermöglicht, dass ein XML-Block wiedergewonnen wird, der die Sammlung von Daten enthält.
  • Das Lesen dieses XML-Blocks ermöglicht, dass die Standardwerte des ersten Elements, d. h. der Wert ihrer Legende (<legend>) und ihres Etiketts (<label>), bekannt sind.
  • Das Prinzip des Einfügens der Standardwerte der Legenden und der Etiketten der Menüelemente ist praktisch gleich dem für das PageSet erzeugten. Tatsächlich wird die Zeichenfolge wiedergewonnen, die den Standardwert repräsentiert, und daraufhin ihre Länge in Bezug auf die Breite des <item>-Elements überprüft. Diese Breite wird in dem 'value'-Attribut des <width>-Elements entdeckt, das sich in dem <menu_description>-Element befindet. Falls die Länge der Standardzeichenfolge größer als die Breite der Elemente ist, wird zum Abschneiden der Zeichenfolge übergegangen, wobei darauf geachtet wird, die letzten drei Zeichen durch drei '.'-Zeichen zu ersetzen.
  • Für den Ersatz der in dem <next_object>-Block definierten URI muss sie durch ein 'tid'/'tidext'-Paar ersetzt werden, was die Erzeugung einer Datei vom PageSet-Typ bedeutet, die durch dasselbe Paar identifiziert ist und in dem Modell, das durch den der Datei <menu> zugeordneten <pageset>-Container definiert ist, unterstützt ist. Diese Datei <pageset> ist wie folgt:
    Figure 00800001
    Figure 00810001
  • Soweit es das PageSet-Objekt betrifft, auf das das Element zeigt, werden die Standardwerte, die das Bild und den Textblock betreffen, in der gleichen Weise wie ein oben gesehenes klassisches PageSet behandelt.
  • Einfügen eines Containers in die Daten, Betreiber: Diese Phase besteht im Hinzufügen eines <container>-Elements zu der Datei 'Conductor.xml'. Dieses Element enthält mehrere Attribute, die 'stream_locator' und 'data_locator' sind, die die Werte der URI-Parameter der Daten enthalten, auf die Bezug genommen wird. An diesem Punkt ist es wichtig anzumerken, dass es im Gegensatz zu den <table>-Elementen die Parameter der URI sind, die eingefügt werden, und nicht das 'uri'-Attribut ist. Dies erfolgt mit dem Ziel der Optimierung der Lokalisierung der Container in dem Betreiber in dem Moment, in dem die mit der Bezugnahme verknüpften realen Daten übertragen werden, wobei dieser Verwendungstyp im Folgenden dargestellt wird.
  • Ein weiteres Attribut, das 'datatype'-Attribut, wird ebenfalls eingefügt, um Informationen hinsichtlich des durch den Container übermittelten Datentyps (z. B. Datenliste, Text, Bild) zu geben. Für jede dieser Containertypen unterscheidet sich die XML-Blockstruktur, die angefügt wird, auf folgende Weise:
    In Bezug auf den Bildtyp:
    Figure 00820001
  • Das <container>-Element enthält hier nur ein einzelnes Unterelement des Abschnittdatentyps, das den XML-Block der Bilddatei repräsentiert.
  • In Bezug auf den PageSet-Typ:
    Figure 00820002
  • Das <container>-Element enthält hier immer ein einzelnes Unterelement des Abschnittdatentyps, das den XML-Block der PageSet-Datei repräsentiert. Es besitzt vier weitere ergänzende Attribute, 'width', 'height', 'align' und 'font', die in dieser Reihenfolge für die Breite, für die Höhe, für die Ausrichtung des Textblocks auf der PageSet-Seite und für die Größe des Zeichensatzes repräsentativ sind. Diese Parameter sind wesentlich beim Zusammensetzen des Ursprungstexts und bei dessen Teilen in mehrere Blöcke.
  • In Bezug auf den Menu-Typ:
    Figure 00830001
  • Wie oben erwähnt wurde, müssen das Menü und das PageSet in diesem Fall verknüpft sein, da die URI für die zwei Objekte gemeinsam ist. Außerdem enthält das <container>-Element dieses Mal zwei Unterelemente:
    Das Erste, <menu>, besitzt ein Attribut, das Informationen über die Breite der Menüelemente gibt, die nützlich zum Überprüfen der Länge der Etikettkette sind, und ein Element vom Abschnittsdaten-Typ, das den Menü-XML-Block repräsentiert.
  • Das Zweite, <pageset>, besitzt die vier Attribute, die Informationen über die Breite, über die Höhe und über die Ausrichtung des Textblocks der PageSet-Seiten sowie über die Zeichensatzgröße geben, die für die Zusammensetzung des Ursprungstexts notwendig sind. Außerdem enthält es ein Abschnittsdaten-Typelement, das den PageSet-XML-Block repräsentiert.
  • Dies kann als Leiter Folgendes geben:
    Figure 00840001
  • XTVML-Datei-MPEG-Umsetzung: Nach der Analyse der Sammlung von URIs jeder der XTVML-Dateien in der Datei 'Conductor.xml' kann ein erneutes Lesen jedes <table>- und <container>-Elements Folgendes ermöglichen:
    Zunächst das Laden jeder XTVML-Datei, die in den Unterelementen des CDATA-Abschnitt-Typs enthalten ist, in eine Liste von DOM.
  • Außerdem zweitens die Umsetzung jeder XTVML-Datei in eine MPEG-Tabelle über den XML2MPEG-Umsetzer und das Speichern des Ergebnisses in einer Speicherliste.
  • Sendung an SBI: Sobald alle XTVML-Dateien ins MPEG-Format umgesetzt worden sind, verbleibt es, sie an die PID zu übertragen, der sie zugeordnet sind. Um die richtige PID und den richtigen SBI zu ermitteln, werden die dem Typ des XTVML-Objekts entsprechenden Parameter innerhalb der Datei 'Diffusion.xml' gesucht. Da der Typ des Objekts durch den Namen des Wurzelelements seiner XTVML-Datei bestimmt ist, ist es notwendig, nach dem <object>-Element zu suchen, das den richtigen 'type'-Attributwert besitzt. Es verbleibt dann, den Wert des 'period'-Attributs, um die Zykluszeiten zu erhalten, und daraufhin den des 'pid'-Attributs des Eltern-<pid_data>-Elements zu lesen. Schließlich ermöglicht der Wert des 'sbi_id'-Attributs des <pid_data>-Elements, dass das entsprechende <sbi>-Element ermittelt wird und die physikalischen Parameter gelesen werden.
  • Aus Gründen der Vereinfachung des Managements des Beendens der Übertragung von MPEG-Tabellen ist die Übertragungsbetriebsart der Tabellen die indirekte Betriebsart. Dies bedeutet, dass die Übertragung jeder der Tabellen durch eine 'Data ID' identifiziert wird und dass für die zu sendenden Tabellen für jeden SBI eine 'Conductor ID' spezifiziert wird. Es ist wichtig anzumerken, dass mehrere Sammlungen von MPEG-Tabellen unterschieden werden, die mit mehreren 'Conductor IDs' verknüpft sind. Wie im Folgenden ausführlich erläutert wird, kann die Übertragung von Daten, auf die Bezug genommen wird, tatsächlich unterschieden werden, wobei die Container somit ihre eigene 'Conductor ID' besitzen, um ihre Übertragung auf der SBI-Ebene unabhängig steuern zu können. Zusammengefasst werden eine 'Conductor ID', die die Sammlung von MPEG-Tabellen, die den <table>-Elementen in der Datei 'Conductor.xml' entsprechen, zusammen gruppiert, und für jedes <container>-Element eine 'Conductor ID' vereinbart.
  • Die 'Data IDs' haben den Wert des 'uri'-Attributs der <table>- oder <container>-Elemente. Für die 'Conductor ID' werden zwei Fälle unterschieden:
    In Bezug auf die <table>-Elemente: Alle MPEG-Tabellen, die jedem dieser Elemente entsprechen, werden mit derselben 'ConductorID' verknüpft. Sie hat als ihren Wert das Ergebnis der Verkettung des Werts des 'appli_id'-Attributs und des Werts des 'name'-Attributs des Wurzelelements der Datei 'Conductor.xml'.
  • In Bezug auf die <container>-Elemente: Jede der mit diesem Elementtyp verknüpften MPEG-Tabellen besitzt ihre eigene 'Conductor ID'. Sie nimmt als ihren Wert das Ergebnis der Verkettung des Werts des 'uri'-Attributs des <container>-Elements und des Werts des 'appli_id'-Attributs des Wurzelelements der Datei 'Conductor.xml', was die Konsistenz auf der Datenaustauscherebene sicherstellt.
  • Mit dem Ziel der Vereinfachung der Überwachung der Übertragung der Tabellen wird durch die Folge von Übertragungen eine Datei 'Broadcast.xml' gebildet. Sie besteht aus der Liste der SBIs und für jeden SBI aus der Sammlung der für die Verbindung notwendigen Parameter. Die Zeit des Beginns der Übertragung und optional die Zeit des Endes sind ebenfalls angegeben. Sie besitzt die folgende Form:
    Figure 00870001
  • Anhalten der Übertragung von Objekten des vorherigen Szenariums: Beim Start der Übertragung jeder der MPEG-Tabellen, die die Datei 'Conductor.xml' bilden, wird in der Datei 'Conductor.old.xml' (entsprechend dem Leiter des vorherigen Szenariums) der Wert des 'id'-Attributs des Wurzelelements wiedergewonnen, wobei dieser Wert den Wert des für die Übertragung des vorherigen Szenariums verwendeten 'Conductor ID'-Parameters repräsentiert. Außerdem wird für jeden in der Liste vorkommenden SBI ein Befehl vom 'Reset Broadcast'-Typ gesendet, der diesen Wert enthält. Wenn diese Operation abgeschlossen worden ist, kann die Datei 'Conductor.old.xml' gelöscht werden.
  • Anmerkung: Unabhängig davon, was das Ergebnis der vorherigen Operationen ist, wird der Programmanbieter durch eine Nachricht benachrichtigt, die die Sammlung übertragener Daten beschreibt.
  • Übertragung einer externen Dateneinheit, auf die Bezug genommen wird
  • Es wird nun ausführlicher die Übertragung einer externen Dateneinheit beschrieben, auf die Bezug genommen wird.
  • 16 ist ein allgemeines Diagramm, das die Übertragung einer externen Dateneinheit veranschaulicht, auf die Bezug genommen wird. Es sind ein Datenaustauscher 1702 sowie verwandte Prozesse, die das Empfangen der XML-Datei, die die Dateneinheit enthält, 1710, das Identifizieren des Stromlokalisierers der empfangenen XML-Datei 1712, das Wiedergewinnen der mit dem ermittelten Stromlokalisierer 1714 verknüpften Container, das Lesen des Datenlokalisierers jedes Containers 1716, das Wiedergewinnen der Dateneinheit, die dem Datenlokalisierer des Containers entspricht, 1718, das Einfügen der Dateneinheit in den Container 1720, das Umsetzen des Containers in das MPEG-Format 1722 und das Übertragen des Containers 1724 umfassen, gezeigt.
  • 17 ist ein Folgediagramm, das ebenfalls die Übertragung einer externen Dateneinheit veranschaulicht, auf die Bezug genommen wird. Es ist die Folge von Ereignissen gezeigt, die sich auf einen SBI 1800, auf einen Leiter 1802, auf einen Datenaustauscher 1804 und auf eine Inhaltsanbieter-XML-Datei 1806 beziehen, wobei die Ereignisse insbesondere das Lesen 1810, das Suchen nach der Dateneinheit, die dem Datenlokalisierer zugeordnet ist, 1812, die Analyse des Stromlokalisierers 1814, das Wiedergewinnen der Container, die dem Stromlokalisierer 1816 zugeordnet sind, das Lesen des Datenlokalisierers von einem Container 1818, das Einfügen der Dateneinheit in die Containerdatei 1820, das Speichern der neuen Containerdatei 1822, das Lesen von dem Betreiber [das Aktualisieren der abgeschlossenen Container] 1824, die MPEG-Umsetzung 1826 und das Übertragen des Containers 1828 umfassen.
  • Es werden nun ausführlicher Merkmale beschrieben, die sich auf das Empfangen der XML-Datei, die die Dateneinheit enthält, auf die Bezug genommen wird, auf die Analyse des Stromlokalisierers, auf die Wiedergewinnung der an dem Stromlokalisierer angebrachten Container, auf das Lesen des Datenlokalisieres des Containers, auf das Suchen nach der Dateneinheit in der XML-Datei für den Inhaltsanbieter, die dem Datenlokalisierer entspricht, auf das Einfügen der Daten in den Container, auf das Lesen der Container des Leiters und auf die Umsetzung in MPEG und auf die Übertragung an den SBI beziehen.
  • Empfangen der XML-Datei, die die Daten enthält, auf die Bezug genommen wird: Die Daten, auf die Bezug genommen wird, werden durch den Inhaltsanbieter mit der Häufigkeit seiner Wahl gesendet. Ein Abtastsystem auf der Datenaustauscherebene ermöglicht, dass eine Datei 'Data.xml' wiedergewonnen wird, die Informationen enthält, die die Dateneigenschaften beschreiben. Diese Datei wird durch den Wert des 'stream_locator'-Attributs des Wurzelelements identifiziert und besitzt eine Sammlung von <datum>-Elementen. Diese <datum>-Elemente enthalten den Datenlokalisierer der Bezugnahme, den Datentyp und das <start_date>-Attribut, das das Datum und die Zeit des Starts der Übertragung der Daten repräsentiert. Tatsächlich ermöglicht die indirekte Sendebetriebsart an den SBI die Verschiebung der Übertragung der Daten. Dennoch wird das Ende der Übertragung der Daten von dem Datenaustauscher nicht berücksichtigt und der Verantwortung des Inhaltsanbieters überlassen.
  • Im Fall der Bildtypdaten werden die MPEG-Dateien ebenfalls gesendet.
  • Figure 00900001
  • Analyse des Stromlokalisierers: Diese Operation besteht einfach im Lesen des 'stream_locator'-Attributs der zuvor empfangenen Datei 'Data.xml'.
  • Wiedergewinnen der Container, die dem Stromlokalisierer zugeordnet sind: Diese Phase besteht im Wiedergewinnen der Liste der <container>-Elemente mit einem 'stream_locator'-Attributwert, der gleich dem des 'stream_locator'-Attributs der durch den Inhaltsanbieter gesendeten Datei ist, aus der auf der Datenaustauscherebene gespeicherten Datei 'Conductor.xml'. Beispielhaft können für einen Stromlokalisierer, der gleich "canal+" ist, die folgenden Elemente wiedergewonnen werden:
    Figure 00910001
  • Lesen des Datenlokalisierers eines Containers: Wenn die <container>-Elemente im Speicher isoliert worden sind, wird iterativ der Wert ihrer 'datalocator'-Attribute gelesen, um zu ermöglichen, dass der Datenblock in der Datei 'Data.xml' identifiziert wird.
  • Suchen nach den Daten, die dem Datenlokalisierer entsprechen, in der Inhaltsanbieter-XML-Datei: Der Wert des 'datalocator'-Attributs ermöglicht für jeden Container, dass das aus der Datei 'Data.xml' wiederzugewinnende <datum>-Element ein 'data_locator'-Attribut mit demselben Wert besitzt. In Übereinstimmung mit dem durch den Wert des 'datatype'-Attributs des <datum>-Elements angegebenen Datentyp werden mehrere Fälle unterschieden:
    In Bezug auf den Bildtyp: Es wird der Inhalt des Unterelements vom Typ CDATA-Abschnitt entnommen, der den Namen der MPEG-Bilddatei enthält.
  • In Bezug auf den Texttyp wird der Inhalt des Unterelements vom Typ CDATA-Abschnitt entnommen, der den Ursprungstextblock enthält.
  • In Bezug auf den Datenlistentyp wird der XML-Block wiedergewonnen, der die Sammlung von Daten enthält, die jedem der Menüelemente entsprechen.
  • Einfügen der Daten in den Container: Es werden immer die folgenden verschiedenen Fälle unterschieden:
    In Bezug auf den Bildtyp: Auf die gleiche Weise wie beim Standardwert wird der Name der MPEG-Bilddatei auf den Wert des 'value'-Attributs des <picturefile>-Elements des Containers eingestellt.
  • In Bezug auf den Texttyp: Der Ursprungstextblock wird in Übereinstimmung mit den in den Attributen 'width', 'height' und 'justif' wiedergewonnenen Beschränkungen der Größe und der Ausrichtung formatiert, sodass er in Linien umbrochen wird. Die Höhe 'height' ermöglicht, dass die globale Anzahl der zum Anzeigen des gesamten Texts notwendigen Seiten bestimmt wird. Somit wird das <page>-Element des Containers vom Typ PageSet so oft wie notwendig dupliziert, wobei darin auf der Ebene des <text_lines>-Elements die Linien der Blöcke in der Reihenfolge eingefügt werden, in der sie erscheinen.
  • In Bezug auf den Datenlistentyp: Für jedes der in dem in der vorherigen Phase wiedergewonnenen Datenblock ermittelten Elemente wird ein Element in dem <menu>-Objekt hinzugefügt.
  • In der gleichen Weise wie der Standardwert wird der Name der MPEG-Bilddatei auf den Wert des 'value'-Attributs des <picturefile>-Elements des Containers eingestellt.
  • Lesen der Container des Leiters: Wenn die Übertragung aller mit dem Stream Locator der von dem Inhaltsanbieter empfangenen Datei verbundenen Container endet, wird die Datei 'Conductor.xml' gefiltert, um nur die <container>-Elemente zu behalten. Die XML-Datei, die jedem von diesen entspricht, wird auf iterative Weise in den Speicher geladen und diese werden ins MPEG-Format umgesetzt.
  • MPEG-Umsetzung und Übertragung über den SEI:
    Es erscheint eine Nachricht vom Typ: Fehler! Quelle nicht verfügbar.
  • Anhalten der Übertragung einer externen Dateneinheit, auf die Bezug genommen wird
  • Es wird nun ausführlicher das Anhalten der Übertragung einer externen Dateneinheit beschrieben, auf die Bezug genommen wird.
  • 18 ist ein allgemeines Diagramm, das das Anhalten der Übertragung einer externen Dateneinheit, auf die Bezug genommen wird, veranschaulicht. Insbesondere, und wie im Folgenden beschrieben wird, veranschaulicht sie die Beziehung zwischen einem Inhaltsanbieter 1900, einem TV-Betreiber 1902 und einem Programmanbieter 1904, wobei verschiedene Konzepte oder Prozesse das Wiedergewinnen der Liste von Daten, auf die während der Übertragung Bezug genommen wird, 1910, die Auswahl einer Bezugnahme 1912, das Anfordern des Anhaltens der Übertragung 1914, das Wiedergewinnen der Container, die die Dateneinheit übertragen, 1916, das Aktualisieren der Container durch Einfügung des Standardwerts der zugeordneten Dateneinheit 1918, das Übertragen der neuen Container 1920 und die Benachrichtigung des Programmanbieters durch den TV-Betreiber 1922 umfassen.
  • 19 ist ein Folgediagramm, das ebenfalls das Anhalten der Übertragung einer externen Dateneinheit, auf die Bezug genommen wird, veranschaulicht. Es ist wieder die Folge von Ereignissen gezeigt, die sich auf einen Inhaltsanbieter 2000, auf einen Programmanbieter 2002, auf einen Datenaustauscher 2004 und auf einen SBI 2006 beziehen, wobei die Ereignisse insbesondere das Auswählen eine Dateneinheit, die übertragen wird, 2010, das Anfordern des Anhaltens der Übertragung 2012, das Wiedergewinnen der Container, die mit dieser Dateneinheit verbunden sind, 2014, den Ersatz der Dateneinheit, auf die Bezug genommen wird, durch ihren Standardwert 2016, die MPEG-Umsetzung der Container 2018, das Senden der Dateien zur Übertragung 2020 und das Benachrichtigen über das Anhalten der Übertragung der Dateneinheit 2022 umfassen.
  • Im Folgenden werden ausführlicher Merkmale beziehen, die sich auf die Wiedergewinnung der Liste von Daten, auf die Bezug genommen wird, während der Übertragung 'Section of the datum of which broadcasting is to be stopped', auf die Wiedergewinnung der Container, auf die Einfügung der Standardwerte in den/die zugeordneten Container und auf die Übertragung des/der zugeordneten Container(s) beziehen.
  • Wiedergewinnung der Liste von Daten, auf die während der Übertragung Bezug genommen wird: Jeder Inhaltsanbieter kann in jedem Moment in der Liste von Daten, auf die er Bezug nimmt, nachschlagen, die durch den Betreiber übertragen wird. Hierfür wird eine WEB-Anwendung über ein Intranet verwendet.
  • Auswahl der Daten, deren Übertragung angehalten werden soll: Der Inhaltsanbieter wählt die besagten Daten in der Liste der URIs aus, was die direkte Folge der Vorbereitung einer XML-Datei hat, die mittels des HTTP-Clients sofort an den Datenaustauscher gesendet wird. Diese Datei enthält die URI der anzuhaltenden Daten. Diese Datei hat die folgende Form:
    <data_stop uri = "canal+ :logo1">
  • Wiedergewinnen der Container: Lesen der Datei 'data_stop' gibt die URI der Daten. Die Zerlegung dieser URI in den Stromlokalisierer und in den Datenlokalisierer ermöglicht die Entnahme der derjenigen <container>-Elemente, deren 'stream_locator'- und 'data_locator'-Attributwerte entsprechen, aus der Datei 'Conductor.xml'. Es wird daran erinnert, dass die Struktur dieser Elemente wie folgt ist:
    Figure 00960001
  • Lesen des CDATA-Abschnitts jedes dieser Elemente gibt die Container-XML-Datei.
  • Einfügen des Standardwerts in den/die zugeordneten Container: Siehe den Abschnitt hinsichtlich der Einfügung von Standardwerten.
  • Übertragung zugeordneter Container: Siehe den Abschnitt hinsichtlich der Übertragung an den SEI.
  • Beenden der Übertragung eines Szenariums
  • Es wird nun das Beenden der Übertragung eines Szenariums beschrieben.
  • 20 ist ein allgemeines Diagramm, das das Beenden der Übertragung eines Szenariums veranschaulicht. Insbesondere, und wie im Folgenden beschrieben wird, veranschaulicht es die Beziehung zwischen einem Programmanbieter 2100 und einem Datenaustauscher 2102 sowie verschiedene Konzepte oder Prozesse, die das Anfordern des Anhaltens eines Szenariums 2110, das Lesen von Informationen, die die Übertragung im Gang betreffen, 2112, einen Leiterrücksetzbefehl 2114 und die Benachrichtigung über das Anhalten des Szenariums 2116 umfassen.
  • 21 ist ein Folgediagramm, das ebenfalls das Beenden der Übertragung eines Szenariums veranschaulicht. Es ist die Folge von Ereignissen gezeigt, die sich auf einen Programmanbieter 2200, auf einen Datenaustauscher 2202 und auf einen SBI 2204 beziehen, wobei die Ereignisse insbesondere das Anfordern des Anhaltens der Übertragung eines Szenariums 2210, die Identifizierung der Anforderung 2212, das Lesen von Informationen, die die Übertragung im Gang betreffen, 2214, das Zurücksetzen der Betreiber 2216 und die Benachrichtigung über das Anhalten der Übertragung 2218 umfassen.
  • Ws werden nun ausführlicher Merkmale, die sich auf die Anforderung für die Beendigung eines Szenariums beziehen, die 'Reset Broadcast'-Befehle und die Benachrichtigung über die Beendigung der Übertragung, beschrieben.
  • Anforderung zum Beendigen eines Szenariums: Der Programmanbieter sendet über den HTTP-Client eine Datei 'reset_broadcast.xml', die die Informationen über den anzuhaltenden Leiter enthält. Diese Informationen werden tatsächlich durch die vollständige Adresse des Leiters repräsentiert, d. h.:
    <conductor appli_id="mag+" diff_id="mag+_test" name='test1' start_date = "01/10/2000 20:00">
  • 'Reset Broadcast'-Befehl: Die Datei 'broadcast.xml' enthält die Sammlung von Übertragungsparametern an die SBIs.
  • Figure 00980001
  • Zur Unterstützung der in den Attributen der <sbi>-Elemente gelesenen Parameter kann ein Befehl zum Beenden der Übertragung des entsprechenden SBI gesendet werden, der den Wert des Leiters spezifiziert, der in dem 'id'-Attribut des <conductor>-Elements erhalten wird. Diese Prozedur wird für jeden SBI ausgeführt, der der Übertragung des Szenariums zugeordnet ist.
  • Benachrichtigung über das Ende der Übertragung: Diese Aktion hat das Ziel, den Programmanbieter vor dem realen Ende seines Szenariums zu warnen. Diese kann vereinfacht in Form einer an den Programmanbieter gesendeten Mail-Nachricht übergeben werden.
  • Unterdrückung der Bezugnahme auf ein Datenelement
  • Es wird nun die Unterdrückung der Bezugnahme auf ein Datenelement beschrieben.
  • 22 ist ein allgemeines Diagramm, das die Unterdrückung der Bezugnahme auf ein Datenelement veranschaulicht. Es sind ein Inhaltsanbieter 2300 und ein Datenaustauscher 2302 sowie verwandte Prozesse, die das Senden einer Nachricht, die die Unterdrückung anfordert, 2310, die Analyse der Verwendung der Bezugnahme 2312, die Aktualisierung der Bezugnahmendatei 2314 und die Benachrichtigung 2316 umfassen, gezeigt.
  • 23 ist ein Folgediagramm, das ebenfalls die Unterdrückung der Bezugnahme auf ein Datenelement veranschaulicht. Es ist die Folge von Ereignissen gezeigt, die sich auf einen Inhaltsanbieter 2400, auf einen Datenaustauscher 2402, auf Leiter 2404, auf Bezugnahmen 2406 und auf einen Programmanbieter 2408 beziehen, wobei die Ereignisse insbesondere das Auswählen der zu unterdrückenden Bezugnahme 2410, das Anfordern der Unterdrückung der Bezugnahme 2412, das Prüfen, ob die Bezugnahme gerade durch ein Szenarium verwendet wird, das übertragen wird, 2414, und, falls die Bezugnahme nicht verwendet wird, 2416, das Unterdrücken der Bezugnahme 2418, das Senden der neuen Bezugnahmendatei 2420 und das Benachrichtigen über den Erfolg 2422, oder, falls die Bezugnahme verwendet wird, 2424, das Benachrichtigen über den Misserfolg 2426, umfassen.
  • Es werden nun ausführlicher Merkmale beschrieben, die sich auf das Auswählen der zu unterdrückenden Bezugnahme, auf die Anforderung für die Unterdrückung der Bezugnahme, auf das Suchen der Verwendung der Bezugnahme, auf das Senden der neuen Bezugnahmedateien und auf die Benachrichtigung beziehen.
  • Auswählen einer zu unterdrückenden Bezugnahme: Der Inhaltsanbieter wählt in der URI-Liste die besagten Daten aus, was die direkte Folge der Vorbereitung einer HTTP-Nachricht hat, die die URI zum Anfordern der Unterdrückung enthält. Sie hat die folgende Form:
    'reference_delete = bourse_de_paris : CAC40'
  • Anforderung zum Unterdrücken der Bezugnahme: Diese Operation besteht im Senden einer konfigurierbaren Anforderung vom Typ 'post' an den WEB-Server des Betreibers, wobei diese Anforderung die obige Nachricht enthält.
  • Untersuchung auf die Verwendung der Bezugnahme: Der Empfang der durch den Inhaltsanbieter gesendeten Nachricht veranlasst die Zerlegung der URI in den Stromlokalisierer und in den Datenlokalisierer. Diese zwei Parameter ermöglichen innerhalb der Leiter jeder Anwendung, die übertragen wird, die Suche nach den <container>-Elementen, die diese zwei Attributwerte 'stream_locator' und 'data_locator' besitzen.
  • Figure 01000001
  • Das Vorhandensein dieser Elemente verhindert, dass der Inhaltsanbieter die Bezugnahme effektiv unterdrückt.
  • Im entgegengesetzten Fall wird jedes der <reference>-Elemente in der Datei 'References.xml', dessen Wert des 'uri'-Attributs dem der zu unterdrückenden Bezugnahme entspricht, unterdrückt.
  • Figure 01010001
  • Senden einer neuen Datei von Bezugnahmen: Falls die Bezugnahme in der Datei 'References.xml' unterdrückt werden konnte, werden die Filteroperation sowie das Senden der Bezugnahmen an die betroffenen Programmanbieter ausgeführt. Siehe auch den Abschnitt hinsichtlich der Filterung und des Sendens der XML-Datei an das Editierhilfsmittel des Programmanbieters.
  • Benachrichtigung: Diese Aktion hat das Ziel, den Inhaltsanbieter vor der Unterdrückung – ob wirksam oder nicht – der Bezugnahme zu warnen. Diese kann in Form einer an den Inhaltanbieter gesendeten Mail-Nachricht übergeben werden.

Claims (12)

  1. Verfahren zum Übertragen interaktiver Anwendungen von einem Betreiber zu wenigstens einem Empfänger/Decodierer, wobei das Verfahren die folgenden Schritte umfasst: auf der Ebene des Betreibers: – Empfangen einer interaktiven Anwendung, die wenigstens eine Datenbezugnahme enthält, von einem Programmanbieter (400); – Empfangen wenigstens von Daten, die im Streaming-Betrieb übertragen werden, von einem Inhaltsanbieter (402), wobei die Daten der wenigstens einen Datenbezugnahme entsprechen, wobei die Daten ohne irgendeine Anforderung gesendet werden; – Ersetzen der wenigstens einen Datenbezugnahme in der interaktiven Anwendung durch die wiedergewonnenen entsprechenden Daten von dem wenigstens einen Datenstrom; – Übertragen der resultierenden interaktiven Anwendung an den Empfänger/Decodierer.
  2. Verfahren nach Anspruch 1, das ferner die folgenden Schritte umfasst: – auf der Ebene eines Programmanbieters (400): Bauen wenigstens einer interaktiven Anwendung, die wenigstens eine Datenbezugnahme umfasst; – auf der Ebene eines Inhaltsanbieters (402): Bereitstellen von Inhalt, der Datenstrom ge nannt wird und der wenigstens Daten umfasst, die der wenigstens einen Datenbezugnahme entsprechen.
  3. Verfahren nach Anspruch 2, das ferner auf der Betreiberebene den Schritt des Umsetzens der interaktiven Anwendungen in das MPEG-Format für die Übertragung umfasst.
  4. Verfahren nach einem vorangehenden Anspruch, bei dem der Programmanbieter für das Erzeugen von Bildschirmen verantwortlich ist, die ein Szenarium bilden.
  5. Verfahren nach einem vorangehenden Anspruch, bei dem der Inhaltsanbieter für das Senden einer Sammlung von Daten, auf die Bezug genommen wird, an den Betreiber verantwortlich ist.
  6. Verfahren nach einem vorangehenden Anspruch, bei dem der Betreiber für die Übertragung der Daten verantwortlich ist.
  7. Verfahren nach einem vorangehenden Anspruch, bei dem der Programmanbieter ein Offline-Hilfsmittel (510), das mit einer Ablagevorrichtung (512) verknüpft ist, ein Editier-Hilfsmittel (514), eine Web-Server-Anwendung (516), eine Übertragungskonsole (518), eine Datenablagevorrichtung (520) und eine Extranet-Vorrichtung (522) umfasst.
  8. Verfahren nach einem vorangehenden Anspruch, bei dem der Inhaltsanbieter (502) eine Übertragungskonsole (560) und eine Extranet-Vorrichtung (562) umfasst.
  9. Verfahren nach einem vorangehenden Anspruch, bei dem der Betreiber einen Empfangsdienst (580), einen URI-XTVML-Verarbeitungsdienst (582), einen Übertragungsdienst (584), eine Datenbank für die Speicherung von URIs (586), eine Datenbank für die Speicherung von Containern (588), einen URI-Editor (590) und einen Web-Server (592) umfasst.
  10. Vorrichtung in einem Digitalfernsehsystem zum Bauen einer interaktiven Anwendung, die an mehrere Empfänger/Decodierer übertragen werden soll, wobei die Vorrichtung umfasst: – Mittel zum Empfangen einer interaktiven Anwendung, die wenigstens eine Datenbezugnahme umfasst, von einem Programmanbieter; – Mittel zum Empfangen wenigstens von Daten, die im Streaming-Betrieb übertragen werden, von einem Inhaltsanbieter, wobei die Daten der wenigstens einen Datenbezugnahme entsprechen, wobei die Daten ohne irgendeine Anforderung gesendet werden; – Mittel zum Ersetzen wenigstens einer Datenbezugnahme in der empfangenen interaktiven Anwendung durch die wiedergewonnenen entsprechenden Daten von dem wenigstens einen Datenstrom.
  11. Vorrichtung nach Anspruch 11, die ferner Mittel umfasst, um die interaktive Anwendung nach der Ersetzung für die Übertragung ins MPEG-Format umzusetzen.
  12. Vorrichtung nach Anspruch 12, die ferner Mittel umfasst, um die umgesetzte interaktive Anwendung in einen zu übertragenden Programmstrom einzufügen.
DE60220259T 2001-03-21 2002-03-21 Datenreferenzsystem Expired - Lifetime DE60220259T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP01400737 2001-03-21
EP01400737A EP1244310A1 (de) 2001-03-21 2001-03-21 Datenreferenzierungssystem
PCT/IB2002/002141 WO2002076102A2 (en) 2001-03-21 2002-03-21 Data referencing system

Publications (2)

Publication Number Publication Date
DE60220259D1 DE60220259D1 (de) 2007-07-05
DE60220259T2 true DE60220259T2 (de) 2008-01-17

Family

ID=8182660

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60220259T Expired - Lifetime DE60220259T2 (de) 2001-03-21 2002-03-21 Datenreferenzsystem

Country Status (9)

Country Link
US (2) US7340528B2 (de)
EP (2) EP1244310A1 (de)
CN (1) CN100438626C (de)
AT (1) ATE363182T1 (de)
AU (1) AU2002309119A1 (de)
CA (1) CA2441574C (de)
DE (1) DE60220259T2 (de)
MY (1) MY138407A (de)
WO (1) WO2002076102A2 (de)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080313282A1 (en) 2002-09-10 2008-12-18 Warila Bruce W User interface, operating system and architecture
US7120666B2 (en) * 2002-10-30 2006-10-10 Riverbed Technology, Inc. Transaction accelerator for client-server communication systems
US8176186B2 (en) 2002-10-30 2012-05-08 Riverbed Technology, Inc. Transaction accelerator for client-server communications systems
US7593915B2 (en) * 2003-01-07 2009-09-22 Accenture Global Services Gmbh Customized multi-media services
FR2862172B1 (fr) * 2003-11-10 2006-02-03 Cit Alcatel Procede et systeme de transmission/reception de contenus multimedia via un reseau de radiocummunication
WO2005053192A1 (ja) * 2003-11-26 2005-06-09 Matsushita Electric Industrial Co., Ltd. コンテンツ送信装置
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US9171100B2 (en) 2004-09-22 2015-10-27 Primo M. Pettovello MTree an XPath multi-axis structure threaded index
JP4095617B2 (ja) * 2005-02-28 2008-06-04 キヤノン株式会社 文書処理装置及び文書処理方法及びコンピュータプログラム
JP4463708B2 (ja) * 2005-03-04 2010-05-19 シャープ株式会社 コンテンツ送信装置、コンテンツ受信装置、コンテンツ配信システム、コンテンツ同期処理プログラム、および記録媒体
KR100691323B1 (ko) * 2005-07-11 2007-03-12 삼성전자주식회사 디지털ｔｖ 및 디지털ｔｖ의 소프트웨어 다운로드방법
US7664742B2 (en) * 2005-11-14 2010-02-16 Pettovello Primo M Index data structure for a peer-to-peer network
US20070174309A1 (en) * 2006-01-18 2007-07-26 Pettovello Primo M Mtreeini: intermediate nodes and indexes
US7515710B2 (en) 2006-03-14 2009-04-07 Divx, Inc. Federated digital rights management scheme including trusted systems
US7962638B2 (en) * 2007-03-26 2011-06-14 International Business Machines Corporation Data stream filters and plug-ins for storage managers
US8112388B2 (en) * 2007-08-03 2012-02-07 Sap Ag Dependency processing of computer files
US8104059B2 (en) * 2007-10-08 2012-01-24 At&T Intellectual Property I, Lp System and method for serving advertising data from the internet
WO2009065137A1 (en) 2007-11-16 2009-05-22 Divx, Inc. Hierarchical and reduced index structures for multimedia files
US8826375B2 (en) * 2008-04-14 2014-09-02 Lookwithus.Com Inc. Rich media collaboration system
US20100011391A1 (en) * 2008-07-14 2010-01-14 Carpenter Jason P Decoder-specific content provision system and method
US8566869B2 (en) 2008-09-02 2013-10-22 Microsoft Corporation Pluggable interactive television
CN105072454B (zh) 2009-01-07 2019-04-19 索尼克Ip股份有限公司 针对在线内容的媒体指南的特定化、集中式、自动化创建
EP2234397A1 (de) * 2009-03-24 2010-09-29 Thomson Licensing Verfahren zur Übermittlung und zum Empfangen von Multimediadaten, welche mit einem Audio-/Videoinhalt verknüpft sind
US11277598B2 (en) * 2009-07-14 2022-03-15 Cable Television Laboratories, Inc. Systems and methods for network-based media processing
US8631028B1 (en) 2009-10-29 2014-01-14 Primo M. Pettovello XPath query processing improvements
EP2507995A4 (de) 2009-12-04 2014-07-09 Sonic Ip Inc Systeme und verfahren zum transport eines kryptographischen materials für elementare bitströme
US8589376B2 (en) * 2010-11-23 2013-11-19 Larry Deutsch Method and apparatus to search data and notify and update a user
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US9087140B2 (en) * 2011-05-24 2015-07-21 International Business Machines Corporation Self-parsing XML documents to improve XML processing
US8818171B2 (en) 2011-08-30 2014-08-26 Kourosh Soroushian Systems and methods for encoding alternative streams of video for playback on playback devices having predetermined display aspect ratios and network connection maximum data rates
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
CN108989847B (zh) 2011-08-30 2021-03-09 帝威视有限公司 用于编码和流处理视频的系统和方法
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
CN102724424B (zh) * 2011-11-29 2017-09-12 新奥特（北京）视频技术有限公司 一种利用数据文件进行电视图文包装场景切换的方法
US9143812B2 (en) 2012-06-29 2015-09-22 Sonic Ip, Inc. Adaptive streaming of multimedia
US10452715B2 (en) 2012-06-30 2019-10-22 Divx, Llc Systems and methods for compressing geotagged video
GB2507751A (en) 2012-11-07 2014-05-14 Ibm Storing data files in a file system which provides reference data files
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US9906785B2 (en) 2013-03-15 2018-02-27 Sonic Ip, Inc. Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9967305B2 (en) 2013-06-28 2018-05-08 Divx, Llc Systems, methods, and media for streaming media content
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US20160006793A1 (en) * 2014-07-04 2016-01-07 Boe Technology Group Co., Ltd. Osd subject file obtaining and providing method and device, updating system
US11137255B2 (en) * 2015-08-03 2021-10-05 Tomtom Global Content B.V. Methods and systems for generating and using localization reference data
US10148989B2 (en) 2016-06-15 2018-12-04 Divx, Llc Systems and methods for encoding video content
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
US11301923B2 (en) 2019-08-05 2022-04-12 Yahoo Assets Llc Automatic web browsing in electronic messaging interface method and apparatus
US11669582B2 (en) * 2021-03-24 2023-06-06 Rookie Road, Inc. Systems and methods for automatic resource replacement

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2300991B (en) * 1995-05-15 1997-11-05 Andrew Macgregor Ritchie Serving signals to browsing clients
FI98175C (fi) * 1995-06-12 1997-04-25 Nokia Oy Ab Multimediaobjektien välitys digitaalisessa tiedonsiirtojärjestelmässä
US5929849A (en) * 1996-05-02 1999-07-27 Phoenix Technologies, Ltd. Integration of dynamic universal resource locators with television presentations
EP0810790A3 (de) * 1996-05-31 1999-10-20 Matsushita Electric Industrial Co., Ltd. Datenkommunikationssystem, Vorrichtung zur Übertragung von Daten und Vorrichtung zum Empfang von Daten
US5991799A (en) * 1996-12-20 1999-11-23 Liberate Technologies Information retrieval system using an internet multiplexer to focus user selection
US6006241A (en) * 1997-03-14 1999-12-21 Microsoft Corporation Production of a video stream with synchronized annotations over a computer network
GB2327837B (en) * 1997-07-29 1999-09-15 Microsoft Corp Providing enhanced content with broadcast video
WO2000004676A1 (fr) * 1998-07-14 2000-01-27 Sony Corporation Procede de gestion de la transmission de donnees, procede de transmission de donnees, et emetteur et recepteur de donnees
US6675385B1 (en) * 1998-10-21 2004-01-06 Liberate Technologies HTML electronic program guide for an MPEG digital TV system
US6360275B1 (en) * 1998-10-29 2002-03-19 Shanghai Wonders Information Co., Ltd. System and method for transmitting and receiving data in a network
US6389458B2 (en) * 1998-10-30 2002-05-14 Ideaflood, Inc. Method, apparatus and system for directing access to content on a computer network
US6799328B1 (en) * 1998-11-23 2004-09-28 Opentv, Inc. Dynamic event information table schedule window
US7000245B1 (en) * 1999-10-29 2006-02-14 Opentv, Inc. System and method for recording pushed data
US7134133B1 (en) * 1999-11-08 2006-11-07 Gateway Inc. Method, system, and software for creating and utilizing broadcast electronic program guide templates
US7028327B1 (en) * 2000-02-02 2006-04-11 Wink Communication Using the electronic program guide to synchronize interactivity with broadcast programs
US20010037359A1 (en) * 2000-02-04 2001-11-01 Mockett Gregory P. System and method for a server-side browser including markup language graphical user interface, dynamic markup language rewriter engine and profile engine
US7882497B2 (en) * 2001-05-17 2011-02-01 Attachmate Corporation Symbiotic computer application and system and method for generation and presentation of same
WO2002100106A1 (en) * 2001-05-30 2002-12-12 Opentv, Inc. On-demand interactive magazine
US7917921B2 (en) * 2001-09-19 2011-03-29 Koninklijke Philips Electronics N.V. Control of an interactive application

Also Published As

Publication number Publication date
CN100438626C (zh) 2008-11-26
EP1371228A2 (de) 2003-12-17
DE60220259D1 (de) 2007-07-05
EP1244310A1 (de) 2002-09-25
AU2002309119A1 (en) 2002-10-03
US8347338B2 (en) 2013-01-01
CA2441574A1 (en) 2002-09-26
WO2002076102A2 (en) 2002-09-26
EP1371228B1 (de) 2007-05-23
MY138407A (en) 2009-05-29
US20080104633A1 (en) 2008-05-01
ATE363182T1 (de) 2007-06-15
CA2441574C (en) 2012-05-29
US7340528B2 (en) 2008-03-04
WO2002076102A3 (en) 2003-03-13
US20050015797A1 (en) 2005-01-20
CN1509573A (zh) 2004-06-30

Similar Documents

Publication Publication Date Title
DE60220259T2 (de) Datenreferenzsystem
DE69736489T2 (de) System zur erzeugung von programmführungsinformation für die ausführung von steuer- und kommunikationsfunktionen durch den benutzer
DE69936157T2 (de) Authentifizierung von in einem digitalen Übertragungssystem übertragenen Daten
DE69909758T2 (de) System zur erzeugung, partitionierung und verarbeitung von elekronischen fernsehprogrammzeitschriften
DE69738024T2 (de) Fernsehprogrammierungssystem und betriebsverfahren dazu
DE69837194T2 (de) Methode und system zur netzwerkverwendungserfassung
DE69901305T3 (de) Modulverwalter für interaktives fernsehsystem
DE69909255T2 (de) Multimediaterminal für mehrere benutzer
DE112013003835B4 (de) Verfahren und Vorrichtung zum Verarbeiten eines digitalen Dienstsignals
DE60037318T2 (de) Verfahren und vorrichtung zur auswahl von mehrfach gesendeten ip-daten die innerhalb eines rundfunkstromes übertragen werden
DE60305096T2 (de) Adressierte Rundfunknachrichtenübertragung
DE69634058T2 (de) System zur Datenurheberrechtsverwaltung unter Verwendung von Schlüsselverteilung
DE69833022T2 (de) Fernladen von anwendungen in einen digitalen decoder
DE69932060T2 (de) Simulation einer zweiwegverbindung für ein-direktionalle datenströme für mehrere teilnehmer
DE69736138T2 (de) Datenfernladung
DE60006708T2 (de) System und verfahren zur aufnahme von push daten
DE60216522T2 (de) Entdeckungsdaten für ip multicast
DE69831179T2 (de) Tragbare vorrichtung zur simulation von bidirektionellen verbindungen für ein-direktionelle datenströme
DE602004009511T2 (de) Vorrichtung und Verfahren zur Verteilung von Programmempfehlungen mittels digitaler Set-Top Boxen
DE69918571T2 (de) Verfahren und vorrichtung zur lieferung von in einem transportstrom eingebetteten bytekodes
DE69738463T2 (de) Rundfunkvorrichtung für Programminformationsrundfunksystem und Empfängerendgerät
DE60217091T2 (de) Synchrones aktualisieren dynamischer interaktiver anwendungen
DE69819507T2 (de) Set-top-box gerätetreiber für die ieee1394 norm
DE69736431T2 (de) Verfahren und vorrichtung zur lokalisierung einer sendung in einem elektronischen programmführer
DE10031034B4 (de) Allgemein interaktive Rundsendungen und insbesondere Systeme zur Erzeugung von interaktiven Rundsendungen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition