-
Die
Erfindung betrifft im Allgemeinen Computersysteme und Softwareanwendungen
dafür und insbesondere
das Liefern von Software-Ressourcen.
-
Ein
digitaler Mediaübertragungsdatenstrom enthält eine
Vielzahl von verschiedenen Inhaltstypen. Digitale Satelliten-Radioübertragungen
weisen beispielsweise einen digitalen Audioinhalt für eine Anzahl
von verschiedenen Kanälen
auf, welche mit Dateninhalt durchsetzt sind. Der Dateninhalt weist
Informationen wie beispielsweise Liedtitel, Künstlernamen oder andere Programm-bezogene
Informationen auf. Digitale Kabel- oder Satelliten-Fernsehübertragungen
weisen beispielsweise Audio- und Videoinhalte für eine Vielzahl von Kanälen auf,
welche mit Dateninhalt durchsetzt sind. Der Dateninhalt beinhaltet
Programmabläufe,
Kanalzuweisungsdaten oder andere Typen von Informationen. In beiden
Fällen empfängt und
verarbeitet ein digitaler Empfänger/Decoder
die Datenübertragungen,
um Audio-, Video- oder andere Daten dem Anwender zu präsentieren.
-
Ein
digitaler Empfänger,
welcher zur Verarbeitung von digitalen Übertragungen geeignet ist,
wie beispielsweise eine typische Haushaltsfernseh-Set-Top-Box („STB"), welcher digitale
Fernsehsignale verarbeitet, erlaubt die Möglichkeit einer weiteren Verbesserung
der Erfahrung des Anwenders durch Vorsehen von zusätzlichem
Inhalt. Genau wie geschlossene Kennung oder sekundäre Audioprogramme
mit der analogen Fernsehübertragung übertragen
wurden, um das Fernseherlebnis des Betrachters zu verbessern, so
können
weitreichendere Typen von zusätzlichem
Inhalt an die Set-Top-Box übertragen
werden, um die Erfahrung des Betrachters in einem digitalen Fernsehkontext
auszuweiten. Die STB stellt zumindest ein grundlegendes Computersystem
dar und kann zusätzlichen
Audio- und Videoinhalt aus Dateninhalt erzeugen, welcher innerhalb des
Stromes von Audio- und Videoinhalt durchsetzt ist. Wenn das Programm
beispielsweise ein Nachrichtenprogramm darstellt, dann können neue
Details oder andere Überschriften
an die STB in Form von Datenblöcken übertragen
werden, welche die STB decodieren kann und dem Anwender anzeigen
kann. Wenn das Programm auf ähnliche
Art und Weise ein Sportprogramm darstellt, dann können Ergebnisse, Statistiken
oder Audiokommentare an die STB gesendet werden, um für die Betrachter
decodiert zu werden.
-
Aufgrund
der Computerleistung in der STB kann die STB ein interaktives Fernsehen
zulassen, welches durch den Anwender in Anspruch genommen werden
kann. Betrachter können
beispielsweise in Gameshows mitspielen, sich bei sofortigen Stimmabgaben
beteiligen und Käufe
tätigen.
Die STB kann als ein Endgerät
dienen, um den Anwendern zu erlauben, mit Fernsehsendern zu interagieren
wie Computer den Computeranwendern erlauben, mit dem Internet zu
interagieren. Anwendungen, Steuerknöpfe, Bilder, Text oder andere
Daten können
mittels eines Datenstromes auf den Computer heruntergeladen werden,
um zusätzlichen
Inhalt und eine interaktive Programmierung zu unterstützen und
zu vereinfachen.
-
1 veranschaulicht
wie zusätzlicher
Inhalt und eine interaktive Programmierung an eine herkömmliche
STB übertragen
werden kann, wo es durch den Anwender in Anspruch genommen werden kann.
Bei einem Sender 100 werden Audio- und Videoquellenmaterial 104 zusammen
mit einem Anwendungscode 112, Knöpfen 116, Bildern 120,
Textdaten 124 und anderen (nicht gezeigten) Daten an einen
Datenmultiplexer 108 eingegeben. Der Datenmultiplexer 108 multiplext
die verschiedenen Eingänge
in einen Sendedatenstrom 130, welcher über Satellit und/oder Kabel
an einen Empfänger 140 übertragen
wird. Beim Empfänger 140 wird
der Sendedatenstrom 130 verarbeitet und durch die STB 150 in empfangenes
Audio- und Videomaterial 154, Anwendungscode 162,
Knöpfe 166,
Bilder 170, Textdaten 174 und andere nicht gezeigte
Daten demultiplext. Das gewünschte
empfangene Audio- und Videomaterial 154 kann der Anwender
durch die STB 150 auswählen
und durch einen Fernsehempfänger 180 in Anspruch
nehmen, und der Anwendungscode 162, die Knöpfe 166,
die Bilder 170, Textdaten 174 und andere nicht
gezeigte Daten können
durch den Anwender über
die STB 150 in Anspruch genommen werden.
-
Es
sei darauf hingewiesen, dass die Beschreibung von 1 die
Sende- und Empfangsprozesse vereinfacht darstellt, wodurch einige
der Anliegen oder Bedenken von Programmdesignern, Sendeingenieuren
oder anderen Teilnehmern in diesem Gebiet nicht klar zum Ausdruck
kommen. Eine besondere Angelegen heit stellt die Art und Weise dar,
mit welcher Audio- und Videoquellenmaterial 104, Anwendungscode 112,
Knöpfe 116,
Bilder 120, Textdaten 124 und andere nicht gezeigte
Daten tatsächlich
senderseitig 100 durch den Datenmultiplexer 108 gemultiplext
und durch die STB 150 empfangsseitig 140 demultiplext
und verarbeitet wird. Der Sendedatenstrom 130 besteht aus
einer Vielzahl von diskreten Blöcken
von Informationen, welche schließlich durch die STB 150 verarbeitet
werden, um den Anwendern es zu ermöglichen, die Programme in Anspruch
zu nehmen.
-
2 zeigt
eine Veranschaulichung eines digitalen Fernsehsendestroms 200 gemäß dem Stand der
Technik. Der Sendestrom weist eine Vielzahl von Videoblöcken („V") 210, Audioblöcken („A") 220 und Datenblöcken („D") 230 auf.
Jeder der Blöcke
stellt ein Teil eines Pakets dar und jedes Paket wird gemäß seinem
Typ bezeichnet. Beispielsweise Pakete mit der Paketkennung („PID") 0 weist ein spezielles
Format auf, welches die Position und/oder eine Kennung eines anderen
speziellen Datentypes beschreibt. Andere PID-Werte weisen Datentypen
auf, deren Details in einer Programmkartentabelle beschrieben werden,
welches eine Liste der Dateitypen vorsieht, welche mit jedem PID
assoziiert ist.
-
Verschiedene
Blocktypen werden aus dem Datenstrom wie gezeigt extrahiert und
in kohärente Datenströme verbunden,
welche zur Präsentation des
Anwenders decodiert werden können.
Diese Blöcke
werden typischerweise durch einen nicht gezeigten Demultiplexer
geleitet, welcher die Codes erkennt, welche die Videoblöcke 210,
die Audioblöcke 220 und
die Datenblöcke 230 identifizieren
und leitet jeden an einen geeigneten, nicht gezeigten Puffer weiter.
Beispielsweise werden zugehörige
Videoblöcke 240 von
dem Datenstrom 200 eingesammelt. Diese Videoblöcke werden
an einen nicht gezeigten Puffer weitergeleitet und zur Darstellung
für den
Betrachter decodiert. Auf ähnliche
Art und Weise identifizierte Audioblöcke 250 und identifizierte
Datenblöcke 260 werden
aus dem Datenstrom extrahiert und an geeignete, nicht gezeigte Decodiermittel
zur Präsentation
ihres Inhaltes an den Anwender weitergeleitet. Es sei darauf hingewiesen,
dass die größere Anzahl
von Blöcken
Videoblöcke 210 darstellen,
da Videoblöcke
typischerweise mehr Datenspeicher und Bandbreite benötigen als
andere Datenformen.
-
Zwei
Aspekte der obigen Veranschaulichung des Datenstromes 200 sind
insbesondere von Bedeutung. Zunächst
treten die Datenblöcke 230 dem Sendedatenstrom 200 in
einer „Catch-as-Catch-can" Art und Weise bzw.
soweit möglich
hinsichtlich der verfügbaren
Bandbreite bei. Wie vorstehend beschrieben, verbraucht das Vorsehen
von Video- und Audioinhalt einen Großteil der zur Verfügung stehenden
Bandbreite. Eine Übertragung
von zusätzlichem Inhalt
kann ein Einfügen
einer Vielzahl von zusätzlichen
Datenblöcken 230 in
dem Sendedatenstrom 200 involvieren. Eine typische digitale
Fernsehübertragung
verwendet einen Datenstrom, welcher aus einer großen Anzahl
von kleinen individuellen Blöcken
zusammengesetzt wird. Diese Blöcke,
welche als Transportstrom-Pakete TS bezeichnet werden, stellen Blöcke mit
fester Größe dar,
welche durch niedrige Pegelschichten in dem Übertragungsprotokoll codiert
und decodiert werden. Beispielsweise bei dem Motion Picture Experts
Group-Standard für Hochgeschwindigkeits-digitale Übertragungen (MPEG-2)
weist jedes TS-Paket eine Größe von 188 Bytes
auf, sowohl für
Video-, Audio- oder andere Daten. Selbst mit einem kleinen Baublock,
mit welchem zu arbeiten ist, benötigt
jeder entfernt anspruchsvolle zusätzliche Inhalt viele Datenblöcke, um
ein Verzeichnis von verfügbaren
Dateien und die Dateien an sich zu kommunizieren, um einen zusätzlichen
Inhalt vorzusehen.
-
Zweitens
kann eine relativ große
Speichermenge verbraucht werden, wenn alle eingehenden Blöcke in dem
STB gespeichert werden. Ein Speichern der gesamten Programme wird
unter Verwendung von Bändern,
Festplatten oder CD-ROM durchgeführt,
welche die Kapazität
der Pufferspeicher in einem typischen STB 150 (1) übersteigt.
Somit ist der Pufferspeicher, welcher zur Unterstützung eines kontinuierlichen
Stromes von einem ausgewählten Programm
und jeglichen zugehörigen
zusätzlichen Inhalt
verwendet wird, eine relativ kostbare Ressource. Wie bei jeglichen
wertvollen Ressourcen ist ein sorgsames Management ein wichtiges
Ziel.
-
Eine
weitere Angelegenheit hinsichtlich der Übertragung von zusätzlichem
Inhalt stellt die Tatsache dar, dass es wünschenswert sein kann, dass
zusätzlicher
Inhalt zur späteren
Verwendung empfangen und gespeichert wird. Audio- und Videoblöcke werden
gesammelt, gepuffert und dem Anwender als im wesentlichen Zeitstrom
wiedergegeben. Wenn somit ein Anwender ein sich im Gang befindli ches
Programm in Anspruch nimmt, dann nimmt er oder sie das Programm
von diesem Punkt an in Anspruch und es besteht keine Notwendigkeit,
die Audio- und Videoblöcke einzufangen,
welche übertragen
worden sind, bevor der Anwender das Programm in Anspruch nimmt.
Andererseits können
Daten, welche einen zusätzlichen
Inhalt aufweisen, welcher sich von Overlay-Grafiken bis zu Audiokommentaren
erstrecken kann, über
eine große
Anzahl von durchsetzten Datenblöcken
gestreut sein in die Audio- und Videoblöcke des gesamten Programmes
passen. Viele Datenblöcke,
welche zur Unterstützung
von einem zusätzlichen
Inhalt benötigt
werden, können übertragen
worden sein, bevor der Anwender das Programm in Anspruch nimmt.
Nichts desto trotz können
vorab übertragene
Blöcke
zu einem späteren Zeitpunkt
aufgerufen werden, wenn der zusätzliche Inhalt
initiiert wird. Da derartige Daten in den Audio- und Videoprogrammen
durchsetzt sind, stellt ein Weg zur Sicherstellung der Verfügbarkeit
aller dieser Daten, welche für
eine bestimmte zusätzliche
Inhaltsanwendung sichergestellt sind, eine wiederholte Übertragung
der Daten in einer wiederkehrenden Schleife dar. Auf diese Art und
Weise können,
selbst wenn ein Anwender seine STB-Box aktiviert, nachdem einige
der gewünschten
Datenblöcke
bereits gesendet wurden, die verpassten Datenblöcke aus der nachfolgenden Schleife
beschafft werden.
-
3 zeigt
einen bekannten Schleifendatenaufbau, welcher üblicherweise als ein „Datenkarussell" 300 bezeichnet
wird. Das Datenkarussell 300 wird aus gesammelten isolierten
Datenblöcken 230 (2)
zusammengesetzt und betrifft die in dem vorstehenden Absatz beschriebene
Angelegenheit. Gemäß 3 wird
beispielsweise angenommen, dass ein Strang 310 des Datenkarussells
benötigt
wird, um eine Reihe von On-Screen Knöpfen darzustellen. Eine Darstellung
dieser Knöpfe
wird durch eine Datenstruktur unterstützt, welche aus einem Verzeichnis 320 und
drei Dateien Datei 1 330, Datei 2 340 und Datei
3 350 zusammengesetzt wird, wobei jede mit einem der Reihe
von On-Screen Knöpfen
assoziiert ist. Um somit die gewünschten
Knöpfe
auszubilden, verwendet die STB den gesamten Strang 310.
Es kann beispielsweise angenommen werden, dass ein Anwender die
STB zu einem Zeitpunkt t·360
aktiviert, was einen Zwischenpunkt während einer Übertragung
von Datenblöcken
darstellt, welche Datei 1 330 darstellt. Einige dieser
Datenblöcke,
welche aus der Datei 1 330 gebildet werden, werden vor
t·360
empfangen und somit wird Datei 1 330 nicht komplett in dem Speicher
der STB gespeichert sein. Der Datenstrang 310 ist Teil
einer wiederkehrenden Schleife 300 eines übertragenen
Datenaufbaus. Wenn somit einige der Datenblöcke, welche die Datei 1 330 darstellen,
in einer vorherigen Übertragung
verpasst wurden, können
diese Datenblöcke
während
einer nachfolgenden Wiederholung des Datenkarussells 300 empfangen
werden, welches in einer kontinuierlichen Rotation übertragen
werden, welches den Namen „Datenkarussell" 300 erklärt.
-
Zwei
weitere Angelegenheiten entstehen aus dem Aufbau des Datenkarussells 300 hinsichtlich
einer Übertragung
von Datenblöcken.
Zunächst sei
darauf hingewiesen, dass viele der Daten in dem Datenkarussell 300 wiederholt übertragen
werden. Es besteht keine Notwendigkeit für die STB, diese Daten jedes
Mal, wenn sie übertragen
werden, aufzuzeichnen, und dies würde die Verarbeitungsressourcen
des STB nachteilig beeinflussen.
-
Zweitens
und vielleicht ein größeres Problem stellt
die Bestimmung dar, wie der Pufferplatz in dem STB für die Daten
zugeordnet werden soll, welche einen zusätzlichen Inhalt beinhalten.
Zur Zeit sind zumindest vier Verfahren zur Verteilung des Platzes
für Daten
bekannt. In einem ersten Verfahren wird ein Puffer fester Größe für diese
Daten bereitgestellt und Datenblöcke
werden in den Puffer durch einen vorab beschriebenen Demultiplexer
weitergeleitet. Wenn das Volumen der Datenblöcke zu groß ist, um in den Puffer zu
passen, dann initiiert der Demultiplexer eine Anfrage nach einem
zusätzlichen
Puffer von der Middleware oder einem Betriebssystem, welches die Hardware
steuert. Wenn der zusätzliche
Puffer erteilt wurde, dann kann der Demultiplexer zu einer Steuerung
der Datenblöcke
fortschreiten. Die Anfrage des Multiplexers nach zusätzlichen
Speicherpuffern jedes Mal, wenn der Platz überschritten wird, kann den Demultiplex-Vorgang
für große Blöcke von
Daten verlangsamen.
-
In
einem zweiten Verfahren wird mehr Speicher als erwartet für den Demultiplexer
zum Speichern von Datenblöcken
zugewiesen. Der Demultiplexer kann dann frei den nicht verwendeten
Speicher für
andere Anwendungen in dem STB verwenden. Dieses Verfahren vermeidet
die Verzögerung
des ersten Verfahrens hinsichtlich der unmittelbaren Anfrage nach
mehr Pufferspeicher, wenn ein anfänglicher Datenempfang den zugeordneten
Platz überschreitet.
Andererseits benötigt
das zweite Verfahren einen größer als
erwarteten Speicherplatz, welcher für die Datenblöcke reserviert
wird. Dies kann zu einer Verschwendung von wertvollen Hardwareressourcen
führen.
Eine nachfolgende Freigabe von nicht verwendetem Speicherpufferraum
kann die verschwenderische Anfangszuweisung verbessern. Sobald jedoch
der Pufferplatz den vorab beschriebenen ausgehandelten Prozess erreicht, übernimmt
dieses Verfahren die potentiellen Verzögerungsprobleme, welche mit
dem ersten Verfahren sowohl hinsichtlich der Sicherung als auch
der Freigabe von Speicherressourcen assoziiert sind.
-
In
einem dritten Verfahren können
die Datenübertragungen
auf eine feste Größe oder
zumindest auf eine feste Vergrößerung begrenzt
werden. Dieses Verfahren reduziert damit die Verarbeitungs- und Ladeverzögerungen,
welche daraus resultieren, dass der Multiplexer Speicherpufferplatz
adäquat
sichert und freigibt. Dieses dritte Verfahren begrenzt jedoch die
Flexibilität
des Systems durch eine Begrenzung des Typs und der Quantität des zusätzlichen
Inhalts, für
welchen die Daten verwendet werden. Unter Berücksichtigung der Beschränkungen
der festen Größe können Anwendungen
die zugeordneten Hardwareressourcen konservativ verwenden. Somit
kann Speicher, welcher für
die Datenblöcke
vorgesehen ist, nicht verwendet oder unterverwendet werden und ein
Teil des Speicherplatzes kann verschwendet werden.
-
Das
vierte Verfahren stellt ein Hybridverfahren der vorherigen Verfahren
dar. Sobald das System initiiert worden ist, wird den Puffern eine
Datengröße zugewiesen,
welche durch die Datenspeicheranforderungen der empfangenden anfänglichen
Datensätze
bestimmt wird. Die zugewiesene Datenpuffergröße wird dann begrenzt auf eine
gemäß den anfänglichen
Datensätzen
spezifizierte Menge. Während kleinere
Datensätze
empfangen werden können, werden
größere Datensätze zurückgewiesen.
Dieses Verfahren weist einen Vorteil dahingehend auf, dass es eine
tatsächliche
repräsentative
Verwendung des Pufferspeichers darstellt, um die zugeordnete Speicherpuffergröße zu setzen,
anstatt angenommene Dateigrößen zu verwenden.
Dieses Verfahren weist jedoch ebenfalls Nachteile auf. Wenn beispielsweise die
anfänglich
zugeordnete Puffergröße groß ist, dann
kann nachfolgend ein Teil des Puffers verschwendet werden. Andererseits,
wenn die zugeordnete Puffergröße zu klein
ist, dann kann die Flexibilität
des Systems hinsichtlich der Verwendung von größeren Datensätzen basierend darauf
beschränkt werden,
was die begrenzende anfängliche
Datensatzgröße darstellt.
-
Abgesehen
von diesen Verfahren können Systeme
flexiblere Ansätze
zur Zuordnung von Speicherpufferraum vorsehen. Beispielsweise bei
der Verwendung des DSM-CC Protokolls, welches als Teil des International
Standard ISO-IEC 13818-6
definiert worden ist, enthält
ein Verzeichniseintrag für eine
Datei eine Bestimmung der Dateigröße. Die Bestimmung könnte durch
den Multiplexer verwendet werden, um eine Neuzuordnungsanforderung
vor dem Empfang der Datei zu initiieren. Die Dateigröße gemäß diesem
Standard repräsentiert
die Größe der Datei,
wie sie in dem Sendestrom komprimiert ist. Da die Daten unkomprimiert
verwendet werden und die komprimierten Datengrößen in Abhängigkeit von der Natur der
komprimierten Daten stark variieren, kann die spezifizierte Dateigröße einen
schlechten Indikator selbst hinsichtlich der relativen Größe der unkomprimierten
Datendateien darstellen.
-
ETSI
TS 101812 V1.2.1 sieht eine technische Spezifikation für Digital
Video Broadcasting für eine
Multimedia Home Plattform vor, bei der ein Datenkarussell einen
Karussell ID-Descriptor als ein MPEG-Datei aufweist, welches einen
Block mit fester Größe darstellt
und relativ klein ist.
-
Andere
relevante Veröffentlichungen
sind aus dem Folgenden ersichtlich:
- (1) www.recnet.com/dab;
- (2) http://www.ibiquity.com/technology/documents/SY_TN_5032_000.pdf;
- (3) http://webap.etsi.org/workprogram/Report_Workltem.asp?WKI_ID-19901;
- (4) www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=31537&ICSI=35&ICS2=40&ICS3=;
- (5) www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=25039&ICSI=35&ICS2=40&ICS3=; und
- (6) www.opentv.com.
-
Somit
besteht ein bislang nicht befriedigtes Bedürfnis in dem Stand der Technik,
modifizierte Dateien in einem Datenkarussell effizient zu erkennen und
Speicherpufferplatz für
Datenblöcke,
welche in dem STB Speicher geladen werden, effizient zuzuweisen.
-
Ausführungsbeispiele
der vorliegenden Erfindung sehen eine effiziente Verwendung von
Ressourcen in einer Set-Top-Box (STB) oder in einem anderen Empfänger vor,
welcher zur Verarbeitung eines Sendedatenstromes verwendet wird.
-
Die
Erfindung ist durch die Ansprüche
1 und 9 definiert.
-
Wenn
somit die Indexdatei mit dem Änderungsindikator
detektiert wird, dann sucht der Empfänger des Datenstromes die Datei,
welche geändert wurde,
und ersetzt die zu ersetzende Datei mit der geänderten Datendatei.
-
Gemäß einem
weiteren Aspekt der Erfindung sucht der den Änderungsindikator in der Indexdatei
detektierende Empfänger
die geänderte
Datei aus dem Datenstrom und ersetzt die zu ersetzende Datendatei
mit der geänderten
Datendatei. Zusätzlich
weist die Indexdatei einen Indexdateiversionsindikator auf, welcher
eine Version der Indexdatei anzeigt und somit anzeigt, wenn die
Indexdatei geändert
wurde. Die Indexdatei weist ferner einen Dateiversionsindikator
für Dateien
in einer Reihe von Dateien auf, mit welchen die Indexdatei assoziiert
ist. Die Dateiversionsindikatoren zeigen an, wenn eine Datei seit
Empfang des letzten Indexblockes geändert worden ist. Die Indexdatei
weist ferner einen Dateigrößenindikator
auf, welcher es erlaubt, zu bestimmen, wenn eine Datei oder Dateien
geändert
wurden und/oder die Größe von einem
Puffer oder Puffern zu bestimmen, welche zum Empfang der geänderten Datei
oder Dateien zuzuordnen sind.
-
Die
bevorzugten und alternativen Ausführungsbeispiele der Erfindung
werden nachstehend lediglich beispielhaft unter Bezugnahme auf die nachfolgende
Zeichnung näher
erläutert.
-
1 zeigt
ein Blockdiagramm der Komposition, Übertragung und Verarbeitung
eines Datenstromes, welcher in einer herkömmlichen digitalen Fernsehübertragung
verwendet wird;
-
2 zeigt
ein Blockdiagramm eines Datenstromes von Video-, Audio- oder anderen
Datenblöcken,
welche in einer herkömmlichen
digitalen Medienübertragung
verwendet werden;
-
3 zeigt
ein Blockdiagramm eines Datenkarussells, welches in einer herkömmlichen
digitalen Medienübertragung
verwendet wird;
-
4 zeigt
ein Blockdiagramm eines Datenkarussells mit einer Indexdatei gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung;
-
5A und 5B zeigen
Blockdiagramme einer Indexdatei gemäß einem Ausführungsbeispiel der
vorliegenden Erfindung,
-
6 zeigt
ein Blockdiagramm zur Erzeugung und Aktualisierung einer Indexdatei
an einer Übertragungsseite
gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung,
-
7 zeigt
ein Blockdiagramm zum Empfang und zur Verwendung einer Indexdatei
an einer Empfangsseite gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung;
-
8 zeigt
ein Blockdiagramm eines Datenverarbeitungs-/Mediensteuerübertragungssystems, welches
eine Indexdatei gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung verwendet, und
-
9 zeigt
ein Blockdiagramm eines Datenverarbeitungs-/Mediensteuerempfangssystems, welches
einen Indexdatei gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung verwendet.
-
Die
Ausführungsbeispiele
der vorliegenden Erfindung sehen ein Verfahren, ein computerlesbares
Medium und ein Datensystem zur Anzeige vor, wenn eine ersetzte Datei
in Reihe von Datendateien durch eine geänderte Datendatei ersetzte
worden ist. Unter Verwendung der Ausführungsbeispiele der vorliegenden
Erfindung wird eine Indexdatei erzeugt und in die Reihen der Datendateien
eingesetzt. Die Indexdatei weist einen Änderungsindikator auf, welcher anzeigt,
dass die geänderte
Datendatei die zu ersetzende Datendatei ersetzt hat. Die Indexdatei
wird wiederholt mit den Reihen der Datendateien übertragen.
-
4 zeigt
ein Datenkarussell 400 mit einer Indexdatei 415 gemäß einem
Ausführungsbeispiel der
vorliegenden Erfindung. Zur Vereinfachung des Vergleichs zwischen
dem Datenkarussell 300 gemäß dem Stand der Technik (3)
weist das Datenkarussell 400 einige Elemente des Datenkarussells 300 (3)
einschließlich
eines Verzeichnisses 320 und der Dateien Datei 1 330,
Datei 2 340 und Datei 3 350 auf. Jedes dieser
gemeinsamen Elemente wird identisch wie in 3 nummeriert,
um hervorzuheben, dass diese Elemente nicht gemäß der vorliegenden Erfindung
geändert
worden sind. Es sei darauf hingewiesen, dass eine erkennbare Änderung
zwischen dem Datenkarussell 300 (3) gemäß dem Stand der
Technik und dem Datenkarussell 400 gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung ein Hinzufügen der Indexdatei 415 in
das Datenkarussell 400 darstellt. Die Indexdatei 415 kann
sich über
mehrere Datenblöcke
erstrecken. Es sei darauf hingewiesen, dass dieses Erstrecken dem
bei anderen Elemente wie beispielsweise das Verzeichnis 320 und
die drei Dateien Datei 1 330, Datei 2 340 und Datei
3 350 entspricht. Wie mit anderen Elementen wird die Indexdatei 410 wiederholt übertragen.
-
Einige
der Betriebsprinzipien des Datenkarussells 400 entsprechen
denen des Datenkarussells 300 (3) gemäß dem Stand
der Technik. Beispielsweise werden Datenblöcke 230 (2)
wiederholt in dem Sendedatenstrom 200 übertragen und werden gesammelt
und zur Verwendung gepuffert. Es sei darauf hingewiesen, dass Systeme,
welche das Datenkarussell 400 verwenden, unterschiedlich auf
die wiederkehrende Übertragung
der Elemente des Datenkarussells 400 reagieren. In einem
System, welches das Datenkarussell 400 gemäß einem Ausführungsbeispiel
der Erfindung verwendet, sobald das System aktiviert worden ist
und einen Satz von Dateien 330, 340 und 350 puffert,
welche in dem Verzeichnis 320 gelistet ist, welches für die derzeitige Anwenderauswahl
geeignet ist, wird das System nicht weitere Dateien laden und Puffern,
bis eine Indexdatei 415 empfangen wurde, welche anzeigt, dass
der Inhalt der Indexdatei und somit andere Dateien in dem Datenkarussell 400 geändert wurden. Dies
steht im Gegensatz zu dem Datenkarussell gemäß dem Stand der Technik, in
welchem die Daten mit jeder Iteration kontinuierlich gelesen und
gepuffert werden, wenn keine der Dateien geändert worden sind.
-
Somit
würde das
System, welches ein derzeit bevorzugtes Ausführungsbeispiel der vorliegenden
Erfindung verwendet, die Ressourcen und/oder die Zeit einsparen,
welche zum Lesen und Puffern der Dateien benötigt wird, welche identisch
mit ihren Vorgängern
sind. Stattdessen würde
die vorliegende Erfindung vorteilhafterweise neue Dateien lediglich dann
lesen und Puffern, wenn ein oder mehrere Änderungen in den Dateien durchgeführt worden
sind. In einer derzeit bevorzugten Ausführungsbeispiel werden lediglich
diejenigen Dateien gelesen und gepuffert, welche aktuell geändert worden
sind, was nachstehend beschrieben wird, wodurch weitere Ressourcen
und/oder Zeit eingespart wird. Es ist jedoch innerhalb der breiten
Prinzipien der vorliegenden Erfindung, wenn mehrere Dateien oder
alle Dateien in dem Datenkarussell jedes Mal gelesen und gepuffert
werden, wenn eine Änderung
in der Indexdatei 415 durchgeführt wird, um anzuzeigen, dass zumindest
eine Änderung
in einem oder mehreren der Dateien in dem Datenkarussell 400 durchgeführt worden
sind.
-
5A zeigt
eine detaillierte Ansicht einer beispielhaften Indexdatei 500 gemäß der vorliegenden
Erfindung. In einem derzeit bevorzugten Ausführungsbeispiel weist die Indexdatei 500 vier
Teile auf: ein Indexdatei-Versionsfeld 504, eine Dateiliste 508, eine
Dateiversionsliste 512 und eine Dateigrößenliste 516. Das
Indexdatei-Versionsfeld 504 wird jedes Mal aktualisiert,
wenn die Indexdatei 500 sich gegenüber einer vorherigen Version
geändert
hat. Die Dateiliste 508 listet die anderen Dateien in dem
Datenkarussell auf, welche mit der Indexdatei 500 assoziiert
sind. Die Dateiversionsliste 512 listet einen derzeitigen
Versionsidentifikator für
jedes der in der Dateiliste 508 gelisteten Dateien auf.
Die Dateigrößenliste 516 listet
die derzeitige Größe jeder
in der Dateiliste 508 gelisteten Dateien auf. In einem
derzeit bevorzugten Ausführungsbeispiel
ist eine 1-zu-1 Entsprechung zwischen der Dateiliste 508,
der Dateiversionsliste 512 und der Dateigrößenliste 516 vorhanden.
Somit können
die Listen 508, 512 und 516 logisch als
eine Tabelle mit Werten in jeder Zeile, jeder Reihe zur Assoziierung
der geeigneten Werte mit den entsprechenden Dateien angesehen werden.
-
Das
Indexdatei-Versionsfeld 504 zeigt an, wenn sich die Indexdatei 500 geändert hat,
wodurch angezeigt wird, wenn eine oder mehrere der Dateien in dem
Datenkarussell sich verändert
haben, welche durch die Indexdatei repräsentiert wird. Der Indexdatei-Versionswert 506 in
dem Indexdatei-Versionsfeld 504 kann eine Änderung
in der Indexdatei 500 auf eine Anzahl von Weisen anzeigen.
Ein Indexdatei-Versionswert 506, welcher in der Indexdatei-Version 504 gespeichert
ist, wird erhöht,
zurück
und vor, zwischen einem begrenzten Satz von Werten oder auf eine
andere Art und Weise verändert.
Es sei darauf hingewiesen, dass die Änderung des Indexdatei-Versionswertes 506,
welcher in der Indexdatei-Version 504 gespeichert
ist, von einem vorherigen Versionsidentifikator zu einem nächsten Versionsidentifikator
zu berücksichtigen
ist und signifikant ist und nicht auf welchen Wert der Indexdatei-Versionswert 506 verändert wird.
-
Der
Rest der Elemente der Indexdatei 500 erzeugt logisch eine
Tabelle, welche die augenblicklichen Attribute jedes der Dateien 510 auflistet,
welche in der Dateiliste 508 gelistet sind. Für jede in
der Dateiliste 508 gelistete Datei 510 wird ein
derzeitiger Dateiversionswert 514 in der Dateiversionsliste 512 gelistet.
Wie vorstehend in Verbindung mit dem Indexdatei-Versionswert 506 beschrieben,
welcher in dem Indexdatei-Versionsfeld 504 gespeichert
ist, können
die Dateiversionswerte 514, welche in der Dateiversionsliste 512 verwendet
werden, eine Änderung
auf verschiedene Art und Weise darstellen. Ein Dateiversionswert 514,
welcher in der Dateiversionsliste 512 gespeichert ist,
kann erhöht
werden, vor und zurück
zwischen einem begrenzten Satz von Werten geändert werden oder kann anderweitig
geändert
werden. Es sei darauf hingewiesen, dass die Änderung des Dateiversionswertes 504 in
der Dateiversionsliste 512 von einem vorherigen Versionsidentifikator
zu einem nächsten
Versionsidentifikator signifikant ist und nicht der spezifische
Wert, auf welchem der Dateiversionswert 514 geändert wird.
Für jede
der Dateien 510, welche in der Dateiversionsliste 512 gelistet
ist, wird eine Dateigröße 518 in
der Dateigrößenliste 516 gelistet.
Die Dateigröße 518,
welche in der Dateigrößenliste 516 gelistet
ist, wird auf geeignete Art und Weise dazu verwendet, Pufferplatz für geänderte Daten
wie oben beschrieben zuzuweisen.
-
Wie
vorstehend beschrieben wird die Indexdatei 500 wiederholt
mit anderen Dateien 510 in dem Datenkarussell übertragen,
mit welchem die Indexdatei 500 assoziiert ist. Wenn keine
der Dateien 510 verändert
wird, verbleibt die Indexdatei 500 unverändert und
die Dateien 510 in dem Datenkarussell werden vorteilhafterweise
nicht geladen oder gepuffert. Wenn die Indexdatei 500 geändert wird,
um eine Änderung
in einer der Dateien 510 zu reflektieren, dann reagiert das
System gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung auf den in der Indexdatei 500 enthaltenen
Informationen.
-
Der
Betrieb und der Effekt der Indexdatei 500 kann durch Beschreibung
veranschaulichen, was abläuft,
wenn die Indexdatei mit einer aktualisierten Indexdatei 500 gemäß 5b ersetzt
wird. 5A zeigt die Indexdatei 500 für eine Reihe
von Dateien Datei 1 v.1 530, Datei 2 v.6 534,
Datei 3 v.3 538 und Datei 4 v.17 542. Wie ebenfalls
in 5A gezeigt, weist die Indexdatei 500 derzeitige
Informationen über
jede der Dateien 530, 534, 538 und 542 auf.
Insbesondere listet die Indexdatei die Namen der Dateien in der
Dateiliste 508, die Version jeder der Dateien in der Dateiversionsliste 512 und
die Größe jeder
der Dateien in der Dateigrößenliste 516 auf.
Die Indexdatei listet den augenblicklichen Versionswert 506 als „21" in dem Indexdatei-Versionsfeld 504.
Wenn in diesem Beispiel das Indexdatei-Versionsfeld 504 durch
einen ganzen Wert jedes Mal erhöht
wird, wenn es von einem Wert von 0 geändert wurde, dann wurde die
Indexdatei 500 einundzwanzig Mal geändert, um eine entsprechende
Anzahl von Instanzen zu reflektieren, in welchen die assoziierten
Dateien 530, 534, 538 und 542 geändert wurden.
-
5B zeigt
eine aktualisierte Indexdatei 504 für dieselbe Reihe von Dateien 530, 534, 538 und 542 wie
die Dateien Datei 3 v.3 538 (5A) mit einer
Dateigröße von 10934,
welches durch die Datei 3 v.4 580 mit einer Dateigröße von 11385
ersetzt wurde. Da Datei 3 v.3 538 (5A) durch
eine Datei 3 v.4 580 (5B) ersetzt
wurde, wird eine aktualisierte Indexdatei 550 in das Datenkarussell
mit diesen Dateien eingefügt.
Dies zeigt dem System an, welches ein Ausführungsbeispiel der vorliegenden
Erfindung verwendet, dass eine Datei in dem Karussell geändert worden
ist.
-
Da
die Änderung
zwischen den Karussellen, welche durch die Indexdatei 500 und 550 (5A und 5B)
repräsentiert
sind, eine Versionsänderung
der Datei 3 von 3 v.3 538 mit einer Größe von 10934 (5A)
auf Datei 3 v.4 580 mit einer Größe von 11385 (5B)
involviert, wurden drei Änderungen
zur Aktualisierung der Indexdatei 500 durchgeführt, um
die aktualisierte Indexdatei 550 zu erzeugen. Als erstes
wird der Indexdatei-Versionswert 507 von „21" in den aktualisierten
Indexdatei-Versionswert von „22" 584 geändert. Zweitens
wird in der Datei versionsliste 512 der Dateiversionswert 514 auf „3" für Datei
3 515 in ihren aktualisierten Versionswert 586 von „4" für Datei
3 geändert.
Schließlich
wird der Dateigrößenwert 518 von „10934" 519 für Datei
3 in der Dateigrößenliste 516 auf
den aktualisierten Dateigrößenwert 588 von „11385" für die Datei
3 geändert.
Mit dieser Information in der aktualisierten Indexdatei 550 (5B)
kann das System, welches ein Ausführungsbeispiel der vorliegenden
Erfindung verwendet, vorteilhafterweise hinsichtlich einer Änderung
in einer oder mehreren Dateien in dem Datenkarussell informiert
werden, ohne unveränderte
Datendateien konstant zu laden und zu Puffern, was Zeit und Ressourcen
spart.
-
Mit
dem Beispiel Weiterschreiten kann davon ausgegangen werden, dass
das System bereits einen Satz von Datendateien 530, 534, 538 und 542 empfangen
hat, welches durch die Indexdatei 500 repräsentiert
wird. Das System scannt das Karussell nach einer aktualisierten
Indexdatei 550 durch Scannen nach Paketen, welche eine
Indexdatei PID wie vorstehend beschrieben aufweisen. Nachdem ein Paket
mit einer Indexdatei PID gefunden wurde, überprüft das System das Paket, um
zu bestimmen, ob der Indexdatei-Versionswert 506 verändert wurde, seitdem
die letzte Indexdatei empfangen wurde. Wenn der Indexdateiversionswert 506 der
gleiche wie die zuletzt empfangen Indexdateiversion ist, dann werden
keine weiteren Aktionen von dem System durchgeführt. Andererseits, wenn der
Indexdatei-Versionswert 506 von dem vorherigen Wert geändert wurde,
dann liest das System die aktualisierte Indexdatei 550 als
einen ersten Schritt des Sicherns der aktualisierten Dateien aus
dem Datenkarussell.
-
Nachdem
die aktualisierte Indexdatei in einem derzeit bevorzugten Ausführungsbeispiel
geladen wurde, wird in einem nächsten
Schritt die Dateiversionsliste 512 überprüft, um zu bestimmen, welche
der Dateien aktualisiert wurde, seitdem die vorhergehende Indexdatei
empfangen wurde. Insbesondere die Dateiversionswerte 514 werden überprüft, um zu
sehen, welche verändert
worden sind. Da die Dateiversion von Datei 3 hier auf eine Version „4" 586 geändert worden
ist, während
die anderen Dateiversionswerte die gleichen blieben, wurde die geänderte Version
identifiziert. Nachdem die geänderte
Datei identifiziert worden ist, wird die Dateigrößenliste 506 nach
der Datei 3580 überprüft und die
geänderte
Dateigröße „11385" 588 wird
gelesen. Nachdem die Größe der geänderten
Datei aufgefunden wurde, weist das System einen (nicht gezeigten)
Puffer zu, welcher dazu in der Lage ist, die geänderte Datengröße „11385" 588 aufzunehmen.
Die geänderte
Datei 3580 wird dann in diesem Puffer gelesen. Der Puffer, welcher
die ersetzte vorherige Datei 3538 aufweist, wird dann freigegeben,
so dass der Speicherplatz, welcher durch diesen Puffer in Anspruch
genommen worden ist, kann für
nachfolgend empfangene Dateien oder andere Zwecke verwendet werden.
-
6 und 7 beschreiben
jeweils ein Flussablaufdiagramm zur Erzeugung und zur Verwendung
von Indexdateien. Gemäß 6 beginnt eine
Routine zur Erzeugung von Indexdateien bei einem Block 610.
Bei Block 620 wird eine ursprüngliche Indexdatei durch Einloggen
der Anzahl der Dateien in dem relevanten Karussell, welche während der Übertragung
geändert
werden können,
eine ursprüngliche
Versionsnummer für
jede Datei und eine ursprüngliche
Größe für jede Datei
erzeugt. Die gesammelten Daten werden in einer geeigneten Liste wie
gemäß 5A und 5B beschrieben
worden ist, eingeloggt. Beim Block 630 wird die Indexdatei
in das Datenkarussell eingefügt
und gemeinsam mit den Dateien übertragen,
mit welchen die Indexdatei assoziiert ist.
-
Bei
einem Entscheidungsblock 640 wird bestimmt, ob Änderungen
in den Dateien durchgeführt worden
sind, welche mit der Indexdatei assoziiert sind. Falls dies nicht
der Fall ist, dann durchläuft
die Schleife den Entscheidungsblock 640, bis eine der assoziierten
Dateien geändert
wird. Wenn eine assoziierte Datei geändert wird, wird beim Block 650 die geänderte Datei
in das Karussell eingefügt.
Bei Block 660 wird eine geänderte Dateigröße für die geänderte Datei
in der Indexdatei eingeloggt. Bei Block 670 wird eine Dateiversion
für die
Datei und eine Indexdateiversion für die Indexdatei geändert. Im
Block 680 wird die überarbeitete
Indexdatei in das Datenkarussell an der Stelle der vorherigen Version
der Indexdatei eingefügt
und übertragen.
Der Ablauf fährt
weiter, um in dem Überprüfungsblock 640 zu überprüfen, ob Dateien
in dem Karussell verändert
worden sind.
-
Gemäß 7 beginnt
ein Ablauf 700 zur Verwendung der Indextabelle bei dem
Block 710. Beim Block 720 wird eine Indexdateiversion
der in dem Karussell empfangenen Indexdatei überprüft. Bei einem Entscheidungsblock 730 wird
bestimmt, ob die Indexdateiversion seit der letzten Indexdatei überprüft worden
ist, geändert
wurde. Es sei darauf hingewiesen, dass anstatt einer Überprüfung der Version
der Indexdatei das System individuell die Dateiversionen überprüfen konnte,
welche in der Indexdatei gelistet sind oder die gelisteten Dateigrößen überprüfen kann,
um festzustellen, ob sie verändert worden
sind. Wenn Anzeichen in der Indexdatei zeigen, dass die Indexdatei
nicht verändert
wurde, dann durchläuft
der Ablauf den Entscheidungsblock 730, bis die Indexdateiversion
geändert
wird. Wenn die Indexdateiversion geändert wurde, dann wird die
Datei in Block 740 identifiziert, welche geändert wurde.
In einem derzeit bevorzugten Ausführungsbeispiel wird bestimmt,
ob eine Datei geändert
wurde, indem die Dateiversionsnummer überprüft wird. Alternativ dazu kann überprüft werden,
ob eine Datei geändert
wurde, indem eine Dateigröße verglichen
wird, um festzustellen, ob sie von der vorherigen Indexdatei geändert wurde.
-
Sobald
die geänderte
Datei oder geänderten Dateien
identifiziert worden sind, wird in Block 750 die geänderte Dateigröße aus der
Indextabelle gelesen. In einem Block 760 wird ein Puffer
mit geeigneter Größe zugeordnet,
um die geänderte
Datei aufzunehmen, unabhängig
davon, ob die geänderte
Datei dieselbe Größe, eine
größere Größe oder
eine kleinere Größe aufweist.
Im Block 770 wird die geänderte Datei in den neu zugeordneten
Puffer gelesen. Im Block 780 wird der Puffer, welcher die
zu ersetzende vorherige Version der Datei aufweist, wird freigegeben,
so dass der Speicherplatz, welcher durch den Puffer verwendet wurde,
für andere
Verwendungen benutzt werden kann. Der Ablauf schreitet zur Überprüfung im
Entscheidungsblock 730 weiter, ob die Version einer empfangenden
Indexdatei geändert wurde.
-
8 zeigt
ein Computersystem, welches als ein Datenverarbeitungs-/Mediensteuerübertragungssystem 800 ausgestaltet
ist, welches zur Verwendung der Ausführungsbeispiele der vorliegenden Erfindung
betrieben werden kann. Das Computersystem kann eine Anzeige 802 wie
beispielsweise einen Fernseher und ein Audiosubsystem 804 wie
beispielsweise ein Stereo- oder ein Lautsprechersystem zur Überwachung
einer Übertragung
von Audio-, Video- und Datenübertragungen
steuern. Das System 800 überträgt durch das Sendesystem 806.
Das System 800 ist dazu geeignet, durch eine Anwendereingabe
einer drahtgebundenen oder drahtlosen Anwendertastatur 808 gesteuert
zu werden.
-
Das
System 800 überträgt durch
das Sendesystem 806 an einen Eingangs/Ausgangscontroller 810,
welcher Signale zu und von einem Videocontroller 812, einem
Audiocontroller 814 und einer zentralen Verarbeitungseinheit
(CPU) 816 leitet. Der Eingangs/Ausgangscontroller 810 ist
geeigneter Art und Weise ein Multiplexer zum Routen von Videodatenblöcken, Audiodatenblöcken und
anderen Datenblöcken,
welche durch das System 800 an die CPU 816 zur
Verarbeitung und zum Multiplexen geleitete und/oder durch das System 800 erzeugt
werden. Die CPU 816 kommuniziert durch einen Systemcontroller 818 mit
Eingangs- und Speichervorrichtungen wie beispielsweise Read only
Memory („ROM") 820, Systemspeicher 822,
Systemspeicher 824 und Eingangsvorrichtungscontroller 826.
Das System 800 gemäß 8 kann
somit Datenblöcke
erzeugen und/oder durch das Sendesystem übertragen. Es sei darauf hingewiesen,
dass die CPU 816 und entsprechende Komponenten dazu geeignet
sind, die Indexdateien gemäß der vorliegenden
Erfindung zu formatieren und zu erzeugen.
-
9 zeigt
ein Computersystem, welches als ein Datenverarbeitungs/Mediensteuerempfangssystem 900 ausgestaltet
ist und dazu geeignet ist, die Ausführungsbeispiele der Erfindung
zu verwenden. Das System 900 empfängt anstatt einer Übertragung von
Daten durch ein Sendesystem 806 (8) Daten von
einem Netzwerk 906 wie beispielsweise ein Breitband-Digitalkabelnetzwerk,
ein digitales Satellitennetzwerk oder andere Datennetzwerke. Im
Gegensatz zu einer Erzeugung durch eine Multiplexierung von Daten
empfängt
das System 900 Audio-, Video- und Dateninhalt von dem Netzwerk 906.
Das System 900 ist geeigneterweise als ein STB zur Steuerung
eines Displays 906 wie beispielsweise ein Fernseher und
eines Audiosubsystems wie beispielsweise ein Stereo- oder ein Lautsprechersystem
ausgestaltet. Das System 900 empfängt ebenfalls eine Anwendereingabe
von einer drahtgebundenen oder drahtlosen Anwendertastatur 908,
welches eine STB Fernbedienung darstellen kann.
-
Das
System 900 empfängt
eine Eingabe von einem Netzwerk 906 über einen Eingangs-/Ausgangscontroller 910,
welches Signale von und zu einem Videocontroller 912, einem
Audiocontroller 914 und einer zentralen Verarbeitungseinheit
(CPU) 916 richtet. Im Falle eines STB ist der Eingangs/Ausgangscontroller 910 geeigneterweise
als ein Demultiplexer zum Routen von Videodatenblöcken, welche von
dem Netzwerk 906 empfangen werden, an einen Videocontroller 912 in
Form eines Videodecoders, Audiodatenblöcke an einen Audiocontroller 914 in Form
eines Audiodecoders und zum Routen anderer Datenblöcke an eine
CPU 916 zur Verarbeitung ausgestaltet. Die CPU 916 kommuniziert
wiederum durch den Systemcontroller 918 mit Eingangs- und Speichervorrichtungen
wie beispielsweise ein ROM 920, Systemspeicher 922,
Systemspeicher 924 und Eingangsvorrichtungscontroller 926.
-
Das
System 900 gemäß 9 kann
somit eingehende Datendateien von verschiedenen Arten einschließlich der
Indexdateien gemäß der vorliegenden
Erfindung empfangen. Das System 900 kann auf die Indexdateien
zum Empfangen und Verarbeiten von geänderten Datendateien reagieren,
welche von dem Netzwerk 906 empfangen wurden.
-
Während das
bevorzugte Ausführungsbeispiel
der Erfindung wie vorstehend veranschaulicht und beschrieben wurde,
können
viele Änderungen durchgeführt werden,
ohne dabei den Schutzbereich der Erfindung zu verlassen. Somit ist
der Schutzbereich der Erfindung nicht auf das offenbarte bevorzugte
Ausführungsbeispiel
beschränkt.
Die Erfindung sollte gänzlich
unter Bezugnahme auf die folgenden Ansprüche bestimmt werden.