-
Die
vorliegende Erfindung bezieht sich auf einen Aufzeichnungsträger mit
einem Programmspeichergebiet zur Speicherung von Verwaltungsdaten,
einem Einführungsgebiet,
einem Programmgebiet zur Speicherung von Benutzerdaten und einem
Ausführungsgebiet.
Die vorliegende Erfindung bezieht sich weiterhin auf ein Verfahren
zum Zugreifen auf digitale Rechteverwaltungsdaten, die in dem Programmgebiet
eines derartigen Aufzeichnungsträgers
gespeichert sind, ein Verfahren zum Aufzeichnen digitaler Rechteverwaltungsdaten auf
einem derartigen Aufzeichnungsträger,
ein entsprechendes Laufwerk und eine entsprechende Aufzeichnungsanordnung,
sowie auf ein Computerprogramm zum Implementieren der genannten
Verfahren.
-
Entsprechend
Anpassungsschichtspezifikationen zum Implementieren eines Sicherheitssystems
für Festwert-
und wiederbeschreibbare optische Speicherplatten befinden sich digitale
Rechteverwaltungsdaten in der Einführung des Diskraums. Der Eingabepunkt
für die
digitalen Rechteverwaltungsdaten (DRM) befindet sich in einer DRM
Zeigereingabe, insbesondere in einem Anpassungsschichtparameterraum
(ALP). Darin sind die physikalischen Stellen aller "Keylockerduplikaten" aufgelistet, wobei
der "Keylocker" die Struktur ist,
welche die Rechte und die Schlüssel
zu den geschützten
Daten enthält.
Für die
Festwert- und neubeschreibbaren Disks befindet sich der DRM Zeiger,
insbesondere der ALP, an einer Adresse, die gegenüber dem
Anfang des Programmgebietes mehr oder weniger fest ist. In diesen
Fällen
kann die DRM Zeigereingabe auf einfache Art und Weise gefunden werden.
-
Für eine optische
Disk von dem aufzeichenbaren (einmal beschreibbaren) Typ können DRM
Daten überall
in dem Programmgebiet liegen, und die DRM Zeigereingabe kann überall hinter
den DRM Daten liegen. Das Finden der DRM Zeigereingabe auf einer
aufzeichenbaren Disk ist auf diese Weise nicht geradeaus. Ohne spezielle
Maßnahmen
würde dies
bedeuten: das Abtasten des ganzen aufgezeichneten Programmgebiets
bis die DRM Zeigereingabe gefunden wird, was viel Zeit nehmen kann.
Eine Komplikation ist, dass das Laufwerk für das Schreiben der DRM Daten
und die DRM Zeigereingabe verantwortlich ist. Eine einfache Datei
mit einem Hinweis auf die DRM Zeigereingabe ist folglich keine Lösung für das Problem,
das das Laufwerk keine Kenntnisse von Dateien hat. Es ist möglich, dass
einen Mechanismus vorzusehen, durch den das Laufwerk die DRM Zei gereingabe
schreibt und die Stelle an die Applikation bekannt gibt, die diese
Information danach in eine Datei schreibt. Dies ist nach wie vor
eine nicht optimale Lösung,
da dies ziemlich kompliziert ist, zusätzliche Kommunikation zwischen
Laufwerk und Applikation erfordert und nicht sehr sicher ist. Außerdem das
Anbringen der Dateieingabe, welche die DRM Zeigereingabendatei beschreibt,
kann an sich ein zeitaufwendiger Prozess sein, der verschiedene
Springbewegungen über
das Prozessgebiet erfordert.
-
Eine
andere Komplikation ist, dass es möglich ist, dass eine Disk,
die unter Verwendung des aufzeichenbaren Zugriffstyps geschrieben
worden ist, unter Verwendung eines nicht konformen Laufwerkes finalisiert
wird. Wenn dies stattfindet, gibt es ein Problem, das es für eine offene
Session gibt, auch noch nach der Finalisierung.
-
Ein
dazu gehöriges
Problem ist, wie das Laufwerk rechtzeitig detektieren kann, dass
eine Disk DRM Daten enthält.
Dies ist nützlich,
weil es die Möglichkeit
bietet, den Keylocker präventiv
zu erfassen. Im Falle einer Festwert- oder neubeschreibbaren Disk
würde das
Einlegen der Disk mit der Abtastung der Einführung starten um die Sessionsparameter
zu erfassen, die in dem Q-Subkanal gespeichert sind. Durch die Wahl
der Standardstelle des Gebietes, das die DRM Zeigereingabe enthält, als
Startpunkt, kann ein Laufwerk gleichzeitig detektieren, ob die Disk
DRM Daten enthält.
-
Deswegen
ist es u. a. eine Aufgabe der vorliegenden Erfindung, einen Aufzeichnungsträger zu schaffen,
der die oben genannten Probleme löst und insbesondere, der es
ermöglicht,
dass ein Laufwerk eine Dateiverwaltungssystemstruktur verwendet
ohne gründliche
Kenntnisse des Dateiverwaltungssystems selber. Weiterhin sollen
entsprechende Verfahren zum Zugreifen oder Aufzeichnen digitaler
Rechteverwaltungsdaten auf einem Aufzeichnungsträger und entsprechende Anordnungen
vorgesehen werden.
-
Diese
Aufgabe wird nach der vorliegenden Erfindung gelöst durch einen Aufzeichnungsträger, wobei
- – digitale
Rechteverwaltungsdaten in dem Programmgebiet gespeichert werden,
- – eine
DRM Zeigereingabe mit dem Eingabepunkt für die genannten digitalen Rechteverwaltungsdaten
in dem Programmgebiet hinter den digitalen Rechteverwaltungsdaten
gespeichert wird, und
- – eine
mit einem Laufwerk auslesbare Eingabe mit einer Information, die
es ermöglicht,
dass das Laufwerk die genannte DRM Zeigereingabe findet und auf
die genannten digitalen Rechteverwaltungsdaten zugreift, die in
dem genannten Programmgebiet oder in dem genannten Programmspeichergebiet
gespeichert sind.
-
Der
vorliegenden Erfindung liegt die Erkenntnis zugrunde, eine mit einem
Laufwerk auslesbare Eingabe einzuführen, die auf die DRM Zeigereingabe,
insbesondere die ALP zeigt, die es ermöglicht, dass das Laufwerk die
DRM Zeigereingabe findet und, durch Verwendung dieser Eingabe, die
DRM Daten findet und darauf zugreift. Diese mit einem Laufwerk auslesbare
Eingabe kann entweder in dem Programmgebiet oder in dem Programmspeichergebiet
gespeichert werden, wobei die beiden Implementierungen gewährleisten
sollen, dass die Eingabe mit Hilfe des Laufwerkes ausgelesen werden
kann. Dazu kann das Laufwerk eine Datenverwaltungsstruktur verwendet
ohne wirkliche Kenntnisse des Datenverwaltungssystems. In dem Fall
behalten sogar nicht konforme oder unwissende Implementierungen
die Information bei.
-
Es
sei bemerkt, dass die vorliegende Erfindung sich nicht auf aufzeichenbare
(einmal beschreibbare) CDs (CD-R) beschränkt, sondern auch auf andere
optische Disks, wie CDs mit einem anderen Zugrifftyp, wie aufzeichenbare
DVDs (DVD-R) angewandt werden kann, wobei in diesem Fall das Gebiet
zum Speichern von Verwaltungsdaten als Verwaltungsaufzeichnungsgebiet
(RMA) statt Programmspeichergebiet (PMA) bezeichnet wird. Auf diese
Weise umfasst der Begriff "Programmspeichergebiet". Wie in dieser Beschreibung
verwendet, auch ein derartiges Verwaltungsaufzeichnungsgebiet.
-
Bevorzugte
Ausführungsformen
der vorliegenden Erfindung sind in den Unteransprüchen definiert.
-
Nach
der ersten bevorzugten Ausführungsform
der vorliegenden Erfindung wird eine ALP Zeigereingabe in dem Programmspeichergebiet
gespeichert, das entweder die Adresse der DRM Zeigereingabe oder einen
Hinweis auf eine virtuelle Zuordnungstabelleneingabe (VAT) enthält, die
auf die genannte DRM Zeigereingabe (ALP) zeigt. Insbesondere wird
die wirkliche physikalische Adresse der DRM Zeigereingabe oder die Folgenummer
oder die Bytestelle der virtuellen Zuordnungstabelleneingabe, welche
die ALP Zeigereingabe enthält,
in dem Programmspeichergebiet gespeichert. Diese Lösung ist
sehr robust. Sie wird von jeder Aktivität der Applikation oder des
Dateiverwaltungssystemlaufwerkes abgeschirmt. Wenn aber die Session
einmal finalisiert worden ist, befindet sich das Programmspeichergebiet
nicht länger
in der gemeinsamen Übertragungsstrecke
und der darin gespeicherte Wert wird nur erfasst, wenn das dem Laufwerk
explizit mitgeteilt wird, beispielsweise durch die Applikation,
den Zeiger aus dem Programmspeichergebiet zu erfassen. Deswegen könnten konforme
Laufwerke als Standard das Abtasten des Programmspeichergebietes
praktizieren, aber dies würde
eine unerwünschte
Verzögerung
bei nicht konformen Disks verursachen.
-
Das
Speichern der physikalischen Adresse der DRM Zeigereingabe ist von
dem Dateiverwaltungssystem unabhängig
und wird auch funktionieren, wenn UDF ("uniform disk format"), das zur Zeit als Standarddateiverwaltungssystem
verwendet wird, nicht als das wirkliche Dateiverwaltungssystem verwendet
wird. Zur Zeit aber gibt es keine Alternative für UDF für die beschriebene Programmdomäne, und
die Anzahl PMA Eingaben, die verwendet werden können, ist zur Zeit auf 100
begrenzt. Dies bedeutet, dass nur höchstens 100 verschiedene ALP
Zeigereingaben auf diese Weise gespeichert werden können.
-
Das
Speichern der virtuellen Zuordnungstabelleneingabe, die auf die
DRM Zeigereingabe zeigt, ist mit UDF verbunden. Die Verwendung der
ALP Zeigereingabe, die in dem Programmspeichergebiet gespeichert ist,
um es zu ermöglichen,
dass das Laufwerk eine Dateiverwaltungsstruktur verwendet, insbesondere
die virtuelle Zuordnungstabelle, ohne Kenntnisse des Dateiverwaltungssystems,
ist eine bevorzugte Option.
-
Nach
einer anderen Ausführungsform
der vorliegenden Erfindung wird ein Deskriptor, insbesondere ein
Implementierungsverwendungsvolumendeskriptor (IUVD), der einen Hinweis
auf eine virtuelle Zuordnungstabelleneingabe (VAT) speichert, die
auf die DRM Zeigereingabe zeigt, wird in dem Programmgebiet gespeichert.
Der Deskriptor hält
vorzugsweise die Folgenummer der virtuellen Zuordnungstabelleneingabe,
die verwendet wird, oder die Byteposition der Adresse in dem Sektor,
welche die virtuelle Zuordnungstabelle hält, insbesondere die logische
Adresse der DRM Zeigereingabe, gezählt vom Anfang der Aufteilung
oder der physikalischen Adresse der DRM Zeigereingabe. Durch diese
Lösung
initialisiert eine UDF Dateiverwaltungssystemimplementierung die
Session. Der Vorteil ist, dass der IUVD in der gemeinsamen Strecke
bleibt, sogar nachdem ein nicht konformes Laufwerk die Session finalisiert
hat.
-
Eine
Möglichkeit
um zu erreichen, dass eine Eingabe in der virtuellen Zuordnungstabelle
auf die DRM Zeigereingabe zeigt, ist, dass das Laufwerk eine virtuelle
Zuordnungstabelleneingabe, die auf die DRM Zeigereingabe zeigt,
einfügt
oder erzeugt. Die Gefahr bei dieser Lösung ist, dass, wenn ein UDF
Reparatur-Utility verwendet wird, dieses detektieren wird, dass
die auf diese Weise geschaffene virtuelle Zuordnungstabellen engabe
nicht auf eine aktuelle Datei zeigt und sie entfernen kann. Dies
wird die Disk nicht ungültig
machen, aber es wird das "Mounten" weniger effizient
machen. Weiterhin ist das Auftreten eines derartigen Ereignisses unwahrscheinlich.
-
Das
Ermitteln, welche virtuelle Zuordnungstabelleneingabe auf die DRM
Zeigereingabe zeigt, kann verschiedenartig erreicht werden. Eine
Option, wie in Anspruch 7 definiert, ist, dass zwei Eingaben in
die virtuelle Zuordnungstabelle eingeschlossen werden, wobei eine
identifiziert, dass die nächste
Eingabe die DRM Zeigereingabe ist, beispielsweise weil sie eine
magische Nummer außerhalb
des gültigen
Adressenbereichs des Mediums enthält, auf dem sie aufgezeichnet
ist, und eine andere Eingabe, welche die wirkliche DRM Zeigereingabe
enthält.
-
Nach
noch einer anderen bevorzugten Ausführungsform wird eine Dateieingabe
mit einem Zeiger auf die genannte virtuelle Zuordnungstabelleneingabe,
auf die genannte DRM Zeigereingabe oder auf eine Datei, welche die
Adresse einer derartigen DRM Zeigereingabe speichert, in dem Programmgebiet
gespeichert. Vorzugsweise befindet die Datei sich in einem virtuellen
Raum nur dann, wenn die Dateieingabe den VAT Tabelleneingabenzeiger
als die Adresse der Datei benutzt. Der erste Schritt ist, eine Datei
zu definieren. Entweder wird der ALP selber als Datei bezeichnet,
oder es wird eine Datei geschaffen, welche die Adresse des ALP enthält. Der
zweite Schritt ist, eine Dateieingabe zu schaffen, welche die Datei
in dem Dateiverwaltungssystem beschreibt. Diese Dateieingabe enthält von der
Datei entweder eine virtuelle Adresse oder eine physikalische Adresse.
Innerhalb der Standard UDF Implementierungen für Daten wird meistens eine
physikalische Adresse verwendet. Wenn eine virtuelle Adresse verwendet
wird, befindet sich die Datei in dem virtuellen Raum, der für Daten
nicht gemeinsam ist, sondern an dieser Stelle nützlich. Die virtuelle Adresse
ist ein Zeiger auf eine Eingabe in den VAT. Mit anderen Worten,
die in der Dateieingabe für
diese Datei aufgezeichnete Adresse ist die VAT Eingabe) Folgenummer),
welche die physikalische Adresse der wirklichen Datei (der Daten)
hält.
-
Diese
Lösung
ist robust für
UDF Reparatur-Utilities, wie die virtuelle Zuordnungstabelleneingabe,
die noch immer auf die wirklichen Daten zeigt und eine Dateieingabe,
die es noch immer für
diese Daten gibt, d. h. die Daten befinden sich in einer Datei innerhalb
eines Dateiverwaltungssystems. Die ALP Zeigereingabe kann auf diese
Weise unter Verwendung des Dateiverwaltungssystems gefunden werden,
da die DRM Zeigerein gabe einen bestimmten Dateinamen erhalten hat,
der in das Dateiverwaltungssystem eingeschlossen ist.
-
Ein
Verfahren zum Zugreifen auf die digitalen Rechteverwaltungsdaten
nach der vorliegenden Erfindung umfasst die nachfolgenden Verfahrensschritte:
- – das
Auslesen einer mit einem Laufwerk auslesbaren Eingabe, die in dem
genannten Programmgebiet oder in dem genannten Programmspeichergebiet
gespeichert ist, mit einer Information, die es ermöglicht, dass
das Laufwerk die genannte DRM Zeigereingabe findet und auf die genannten
digitalen Rechteverwaltungsdaten eingreift, und
- – das
Verwenden der genannten Information in der genannten mit einem Laufwerk
auslesbaren Eingabe zum Auslesen der genannten DRM Zeigereingabe,
die in dem Programmgebiet hinter den genannten digitalen Rechteverwaltungsdaten
gespeichert sind, die den Eingabepunkt für die genannten digitalen Rechteverwaltungsdaten
aufweisen, und
- – das
Verwenden des Eingabepunktes in der genannten DRM Zeigereingabe
um auf die genannten digitalen Rechteverwaltungsdaten einzugreifen.
-
Ein
Verfahren zum Aufzeichnen digitaler Rechteverwaltungsdaten nach
der vorliegenden Erfindung weist die nachfolgenden Verfahrensschritte
auf:
- – das
Speichern der genannten digitalen Rechteverwaltungsdaten in dem
Programmgebiet,
- – das
Speichern einer DRM Zeigereingabe in dem Programmgebiet hinter den
genannten digitalen Rechteverwaltungsdaten,
wobei die genannte
DRM Zeigereingabe den Eingabepunkt für die genannten digitalen Rechteverwaltungsdaten
aufweist, und
- – das
Speichern einer mit einem Laufwerk auslesbaren Eingabe in dem genannten
Programmgebiet oder in dem genannten Programmspeichergebiet, wobei
die genannte mit einem Laufwerk auslesbare Eingabe eine Information
enthält,
die es ermöglicht,
dass das Laufwerk die genannte DRM Zeigereingabe findet und auf
die genannten digitalen Rechteverwaltungsdaten eingreift.
-
Ein
Laufwerk nach der vorliegenden Erfindung umfasst:
- – Lesemittel
zum Auslesen einer mit einem Laufwerk auslesbaren Eingabe, die in
dem genannten Programmgebiet oder in dem genannten Programmspeichergebiet
gespeichert ist, mit einer Information, die es ermöglicht,
dass das Laufwerk die genannte DRM Zeigereingabe findet und auf
die genannten digitalen Rechteverwaltungsdaten eingreift, und
- – Bewertungsmittel
zum Bewerten der genannten Information, die sich in der genannten
mit dem Laufwerk auslesbaren Eingabe befindet und zum Übertragen
dieser Eingabe zu den genannten Lesemitteln, wobei die genannten
Lesemittel dazu vorgesehen sind, die genannte DRM Zeigereingabe
auszulesen, die in dem Programmgebiet hinter den genannten digitalen
Rechteverwaltungsdaten gespeichert ist, die den Eingabepunkt für die genannten
digitalen Rechteverwaltungsdaten enthalten, wobei die genannten
Bewertungsmittel dazu vorgesehen sind, den genannten Eingabepunkt
in der genannten DRM Zeigereingabe zu bewerten und diesen zu den
genannten Lesemitteln zu übertragen,
und zwar zum Zugreifen auf die genannten digitalen Rechteverwaltungsdaten.
-
Weiterhin
bezieht sich die vorliegende Erfindung auf eine Aufzeichnungsanordnung
zum Aufzeichnen digitaler Rechteverwaltungsdaten, mit Aufzeichnungsmitteln
für die
genannten digitalen Rechteverwaltungsdaten in dem Programmgebiet,
zum Speichern einer DRM Zeigereingabe in dem Programmgebiet hinter
den genannten digitalen Rechteverwaltungsdaten, wobei die genannte
DRM Zeigereingabe den Eingabepunkt für die genannten digitalen Rechteverwaltungsdaten
und zur Speicherung einer mit einem Laufwerk auslesbaren Eingabe
in dem genannten Programmgebiet oder in dem genannten Programmspeichergebiet
enthält,
wobei die genannte mit einem Laufwerk auslesbare Eingabe eine Information
enthält,
die es ermöglicht,
dass das Laufwerk die genannte DRM Zeigereingabe findet und auf
die genannten digitalen Rechteverwaltungsdaten zugreift.
-
Die
vorliegende Erfindung bezieht sich ebenfalls auf ein Computerprogramm
mit Computerprogrammcodemitteln um dafür zu sorgen, dass ein Computer
die Verfahrensschritte der Verfahren nach der vorliegenden Erfindung
durchführt,
wenn dieses Computerprogramm in einem Computer läuft.
-
Ausführungsbeispiele
der vorliegenden Erfindung sind in der Zeichnung dargestellt und
werden im Folgenden näher
beschrieben. Es zeigen:
-
1 ein
Blockschaltbild einer Datenwiedergabeanordnung,
-
2 Layouts einer leeren und einer initialisierten
Disk,
-
3 eine Darstellung der Verwendung einer
ALP Zeigereingabe,
-
4 eine Darstellung der Hinzufügung von
Daten unter Verwendung einer ALP Zeigereingabe,
-
5 eine Darstellung der Verwendung eines
Implementierungsverwendungsvolumendeskriptors,
-
6 eine
Darstellung des Implementierungsverwendungsvolumendeskriptormechanismus,
-
7 eine Darstellung der Hinzufügung von
Daten, wenn ein Implementierungsverwendungsvolumendeskriptor verwendet
wird,
-
8 eine
Darstellung der Verwendung zweier virtuellen Zuordnungstabelleneingaben,
und
-
9 eine Darstellung der Verwendung einer
Dateieingabe.
-
1 zeigt
ein Blockschaltbild einer Wiedergabeanordnung nach der vorliegenden
Erfindung. Zum Auslesen von Benutzerdaten aus einer Disk 1 ist
eine Leseeinheit 2 vorgesehen. Ein Teil der Benutzerdaten oder
alle Benutzerdaten können
Verwendungsbeschränkungen
unterliegen, wie diese in einem digitalen Rechteverwaltungssystem
(DRM) definiert sind, ausbedungen zwischen Inhaltsprovidern und
Konsumenten. Dies bedeutet, dass Inhalt, der auf der Disk 1 gespeichert
ist, verschlüsselt
sein kann, und der Inhalt muss entschlüsselt werden, bevor er von
dem Benutzer abgespielt werden kann. Deswegen können beispielsweise Verschlüsselungsschlüssel in
einem bestimmten Gebiet auf der Disk gespeichert sein. Weiterhin
können
Verwendungsrechte auf der Disk 1 gespeichert sein, die
beispielsweise angeben, ob es einem Benutzer gestattet ist, Kopien
von dem Inhalt zu machen. Derartige Verwendungsrechte und Schlüssel werden
nachstehend als DRM Daten bezeichnet. Um derartige DRM Daten auszulesen
ist eine betreffende DRM Leseeinheit 3 vorgesehen. Um einen
Zugriff auf diese DRM Daten zu finden müssen ein oder mehrere Zeiger
durch eine Bewertungseinheit 4 gefunden und bewertet werden,
und zwar bevor die DRM Daten wirklich ausgelesen werden können. Die
ausgelesenen DRM Daten werden danach zur Steuerung der Auslieferung
von Benutzerdaten verwendet, d. h. die Steuereinheit 5 wird
die Inhaltsleseeinheit 2 steuern, beispielsweise die Auslieferung
von Daten verbieten, wenn ein Verwendungsrecht die Auslieferung
oder Entschlüsselung
von Benutzerdaten vor der Auslieferung derselben verbietet. Selbstverständlich können andere
Verwendungsrechte in diesem DRM Daten vorhanden sein oder zu einer
anderen Steuerung der Auslieferung von Benutzerdaten führen. Die
Leseeinheiten 2, 3 und die Bewertungseinheit 4 können auch
als ein Laufwerk betrachtet werden.
-
Insbesondere
für einen
beschreibbaren optischen Aufzeichnungsträger können die DRM Daten überall in
dem Programmgebiet vorgesehen sein, und der Anpassungsschichtparameterraum
(ALP), der als DRM Zeigereingabe mit dem Eingabepunkt für diese DRM
Daten verwendet wird, befindet sich irgendwo hinter den DRM Daten.
Es wird immer möglich
sein, den ALP durch Rückwärtsabtastung
zu finden, anfangend bei dem letzten gültigen Block auf der Disk.
Diese Prozedur kann aber sehr zeitaufwendig sein. Nachstehend werden verschiedene
Maßnahmen
erläutert
um es zu ermöglichen,
dass ein Laufwerk auf die DRM Daten zugreift, die in dem Programmgebiet
einer Disk gespeichert sind.
-
2a zeigt
ein Layout einer leeren Disk, wobei das Leistungskalibrierungsgebiet
(PCA) fortgelassen ist. Von links nach rechts reservierte Räume, vorgesehen
für das
Programmspeichergebiet PMA, das Einführungsgebiet, das Programmgebiet
und das Ausführungsgebiet
sind dargestellt.
-
2b zeigt
das Layout einer initialisierten Disk, die in dem betreffenden Beispiel
keinen speziellen Standard bemerkt, beispielsweise einen CD2 Standard
oder den Orange Book Teil II Standard. Eine CD2 laienhafte Initialisierung
einer CD-R für
sequentiellen Zugriff bedeutet, dass es keine CD2 spezifischen Strukturen
auf der Disk gibt und jeder Gastgeber (Laufwerk, Applikation) wird
die Disk als eine Standard-Disk (Nicht-CD2) wieder erkennen. Es
bedeutet auch, dass auf den CD2 Inhalt auf dieser Disk, beispielsweise
durch eine gewisse Form von Superverteilung, nicht zugegriffen werden
kann um zu rendern, bis CD2 bekannte Applikation den Inhalt unter
Verwendung eines CD2 Laufwerkes aktiviert. Wie in 2b dargestellt,
sind in dem PMA die Stelle der ersten (reservierten) Spur und der
zweiten (UDF Daten) Spur in einer Anfangseingabe E1 aufgezeichnet.
Ein durch UDF bezeichneter Teil hält alle Raumstrukturen. Weiterhin
ist hinter dem UDF Teil eine virtuelle Zuordnungstabelle VAT Informationssteuerblock
ICB vorgesehen. Ein VAT ist eine UDF Struktur, die Adressenneuabbildung
schafft. In diesem Fall enthält
der VAT ICB auch die VAT selber.
-
Wenn
vorausgesetzt wird, dass die verwendete UDF Implementierung CD2
nicht kennt, sind in die Initialisierung keine CD2 spezifischen
Strukturen eingeschlossen. Zu dem betreffenden Zeitpunkt kann das
System aus sich selber ermitteln, ob die CD künftig zur Speicherung von CD2
Inhalt verwendet wird und deswegen kann keine CD2 PMA Eingabe präventiv in
die Initialisierungsprozedur eingeschlossen werden. Wenn die verwendete
UDF Implementierung mit CD2 unbekannt ist, dann kann der CD2 Implementierungsverwendungsraumdeskriptor
(IUVD) aufgezeichnet werden, wie in 2c dargestellt.
Nebst der Tatsache, dass er der CD2 Merker im Falle einer sonst
allgemeinen Disk ist, schafft der IUVD die Stelle einer ALP Adresse
in der VAT. Diese Stelle kann fest liegen, beispielsweise als die
erste Eingabe, wenn gewährleistet
wird, dass die VAT deterministisch ist, wenn der ALP hinzugefügt wird,
d. h. wenn es keine vorhergehenden Sessionen gibt. Nach einer ersten
Ausführungsform
der vorliegenden Erfindung soll ein ALP Zeiger, der in der PMA gespeichert
ist, verwendet werden. Wenn CD2 Daten auf einer Nicht CD2 Disk aufgezeichnet
werden sollen, muss das Laufwerk ein CD2 Laufwerk sein. Die UDF
Implementierung kann allgemein sein und die Applikation ist irrelevant.
-
3a zeigt
ein Speicherlayout nachdem eine CD2 unbekannte UDF Implementierung
CD2 Daten hinzugefügt
hat. Unmittelbar vor dem physikalischen Auswurf einer Disk oder
bei Detektion des Schreibens der VAT werden die Keylocker KL und
der ALP geschrieben und die VAT wird wie in 3b dargestellt,
wiedergegeben. Der Keylocker ist ein Behälter für die Verwendungsrechte und
die Anlagenschlüssel,
d. h. die DRM Daten, auf die durch das Laufwerk der Wiedergabeanordnung
zugegriffen werden soll bevor die CD2 Daten wiedergegeben werden
können.
Der ALP ist eine Struktur, die den Eingabepunkt für die genannten
Keylocker KL enthält,
d. h. er ermöglicht
es, die Stelle der DRM Daten KL zu finden. Damit ein Laufwerk den
ALP findet, wird in dem PMA ein ALP Zeiger aufgezeichnet. In diesem
Fall muss das Laufwerk ein CD2 Laufwerk sein. Es sei bemerkt, dass "UDF" Nicht CD2 Daten
angibt und "CD2" CD2 Daten angibt.
-
Jede
beliebige nachfolgende Hinzufügung
von Daten ist unabhängig
von der Historie der Disk. 4a entspricht 3c und
zeigt den Endzustand nach Hinzufügung
der ALP Zeigereingabe E2. Wenn Nicht CD2 Daten hinzugefügt werden,
wie in 4b dargestellt, werden diese
Sondermaßnahmen
getroffen, weil, wenn Nicht CD2 Daten hinzugefügt werden, wie in 4b dargestellt,
wird eine Kopplung zu dem ALP, d. h. zu der ALP Zeigereingabe E2,
beibehalten. Das Hinzufügen
von CD2 Daten, wie in 4c dargestellt, ist nur in einem
CD2 Laufwerk möglich.
In dem Fall werden KL, ALP und VAT ICB neu geschrieben. Weiterhin
soll die ALP Zeigereingabe E2 in die ALP Zeigereingabe E3 erneuert
werden.
-
Es
sei bemerkt, dass die maximale Anzahl Eingaben in dem PMA die Anzahl
Male, dass die ALP Zeigereingabe aktualisiert werden kann (in der
Praxis etwa 100 mal) begrenzt. Das beschriebene Schema ist sehr robust
und erfordert keine Laufwerk- oder Applikationsunterstützung. Die Übersetzung
und die Änderung
des VAT ist aber ein empfindlicher Punkt. Der VAT ICB ist die letzte
Struktur auf der Disk, es ist ein Zeiger auf die VAT. Wenn die Größe der VAT
und des VAT ICB kombiniert, kleiner ist als die logische Blockgröße (2 KB
auf CD) enthält
der VAT ICB die VAT selber. Dieses Letztere ist fast immer der Fall
und im Falle von CD2 ist es erforderlich.
-
Während in
der oben beschriebenen Ausführungsform
die in dem PMA gespeicherte ALP Zeigereingabe einen Hinweis auf
den ALP enthält,
kann insbesondere die Adresse des ALP in einer etwas anderen Ausführungsform
die ALP Zeigereingabe einen Hinweis auf die VAT Eingabe enthalten,
die auf diesen ALP zeigt. Die beiden Ausführungsformen führen zu
den gleichen Ergebnissen, d. h. ermöglichen es, dass ein Laufwerk, das
imstande ist, die ALP Zeigereingabe auszulesen, um letztendlich
die DRM Daten zu finden.
-
Nach
einer anderen Ausführungsform
muss der oben genannte IUVD dazu verwendet werden. Der CD2 spezifische
IUVD ist fakultativ. Die Verwendung des IUVD erfordert, dass die
Initialisierung der UDF Implementierung mit CD2 bekannt ist. Das
Schema, von dem der IUVD ein Teil ist, erfordert auch die Einfügung der
physikalischen Blocknummer (PBN) des ALP in der VAT. Der IUVD gibt
an, welche VAT Eingabe die Stelle des ALP identifiziert. Obschon
allgemeine UDF Implementierungen die Kopplung beibehält, wird
sie nicht aktualisiert. Folglich wird, wenn der ALP unter Verwendung
einer CD2 unbekannten UDF Implementierung neu geschrieben wird,
der Wert der PBN des ALP in der VAT nicht korrigiert, es sei denn,
dass es stattdessen eine spezielle Prozedur gibt, die es ermöglicht,
dass das Laufwerk die physikalische Adresse des ALP in der VAT aktualisiert.
Wenn dies nicht gewährleistet
wird, bedeutet dies, dass der in dem PMA aufgezeichnete Wert immer
Priorität
hat gegenüber
dem Wert, der in der VAT gespeichert ist. Es sei bemerkt, dass dies
nur die Prozedur für
die Ortung des ALP beeinflusst. Auf jeden Fall gibt es nur einen
einzigen gültigen
ALP.
-
5a zeigt
das Layout der Diskstruktur, wobei ein IUVD, eine UDF Dateneingabe
und ein VAT ICB in dem Programmgebiet aufgezeichnet werden. Der
IUVD enthält
die Nummer der Eingabe in der VAT, welche die physikalische Adresse
des ALP Zeigers identifiziert, angegeben durch den Pfeil. Wenn,
wie in 5b dargestellt, eine CD2 unbekannte
UDF Implementierung CD2 Daten hinzufügt, wird der VAT ICB neu geschrieben. Unmittelbar
vor dem physikalischen Auswurf einer Disk oder bei Detektion des
Schreibens der VAT werden KL und ALP geschrieben, wie in 5c dargestellt.
Die VAT wird kopiert und die PBN des ALP wird in die VAT an der
geeigneten Stelle eingefügt.
-
Dies
ist in 6 dargestellt, die oben das Layout der Datenstruktur
der Disk zeigt, wie in 5c angegeben, nachdem eine andere
UDF Dateneingabe durchgeführt worden
ist, was zu einer Verschiebung des VAT ICB führt. Dargestellt ist die IUVD
Struktur mit einer Eingabe "ALP
Zeiger", dessen
Inhalt "n" ist. Diese Eingabe "n" gibt an, dass VAT Eingabe "n" der dargestellten VAT Struktur die
physikalische Adresse des ALP enthält.
-
Jede
beliebige nachfolgende Hinzufügung
von Daten ist unabhängig
von der Historie der Disk. Wenn nicht CD2 Daten hinzugefügt werden,
wird die ALP VAT Eingabe beibehalten. Wenn CD2 Daten hinzugefügt werden,
ist ein CD2 Laufwerk erforderlich. Dies ist in 7 dargestellt. 7 zeigt ein Layout, wie in 5c dargestellt.
Wenn Nicht CD2 Daten hinzugefügt
werden, wie in 7b dargestellt, sind keine Sondermaßnahmen
erforderlich, da die Kopplung mit ALP in dem verschobenen VAT ICB
beibehalten wird. Das Hinzufügen von
CD2 Daten, wie in 7c dargestellt, ist nur in einem
CD2 Laufwerk möglich.
KL, ALP und VAT ICB sollen danach geschrieben werden, wie dargestellt.
-
Nach
wieder einer anderen Ausführungsform,
die anhand der 8 erläutert wird, werden zwei Eingaben
in die VAT vorgesehen. Die erste Eingabe (VAT Eingabe n) identifiziert,
dass die nächste
Eingabe (VAT Eingabe n + 1) der ALP Zeiger ist, beispielsweise weil
dieser eine magische Nummer enthält.
Die nachfolgende Eingabe (VAT Eingabe n + 1) enthält den wirklichen
ALP Zeiger, insbesondere enthält
sie die Adresse des ALP.
-
In
noch einer anderen Ausführungsform
der vorliegenden Erfindung wird eine Eingabe in die VAT, zeigend
auf den ALP, dadurch erreicht, dass eine Dateieingabe in die virtuelle
Aufteilung geschaffen wird. Der erste Schritt ist das Definieren
einer Datei. Entweder der ALP selber wird als Datei bezeichnet,
oder es wird eine Datei geschaffen, welche die Adresse des ALP enthält. Der
zweite Schritt ist das Schaffen einer Dateieingabe FE, welche die
Datei in dem Dateiverwaltungssystem beschreibt. Diese FE enthält von der
Datei entweder eine virtuelle Adresse oder eine physikalische Adresse.
Innerhalb Standard UDF Implementierungen für Daten wird meistens eine
physikalische Adresse verwendet. Wenn eine virtuelle Adresse verwendet
wird, bleibt die Datei in dem virtuellen Raum, der nicht für Daten üblich ist,
was aber in dem vorliegenden Fall nützlich ist. Die virtuelle Adresse
ist ein Zeiger auf eine Eingabe in die VAT. Mit anderen Worten,
die in die FE für
diese Datei aufgezeichnete Adresse ist die VAT Eingabe (Folgenummer),
welche die physikalische Adresse der wirklichen Datei (der Daten)
enthält.
-
Dies
ist in 9 dargestellt. 9a zeigt
das Layout ohne die vorgeschlagene Dateieingabe. Die VAT zeigt auf
den ALP, der auf den KL zeigt. In 9b ist
eine Dateieingabe eingefügt
und in dem Programmgebiet gespeichert worden. Diese Dateieingabe
FE umfasst einen Zeiger auf die VAT. Diese Lösung ist robust für UDF Reparaturmölichkeiten,
da die VAT Eingabe noch immer auf die wirklichen Daten zeigt und
eine Dateieingabe FE für
diese Daten noch immer besteht, d. h. die Daten sind in einer Datei
innerhalb des Dateiverwaltungssystems. Der ALP Zeiger kann auf diese
Art und Weise unter Verwendung eines Dateiverwaltungssystems gefunden
werden, da der ALP einen bestimmten Dateinamen erhalten hat, der
in das Dateiverwaltungssystem eingeschlossen ist.
-
Nach
einer Abwandlung ist es möglich,
dass die Applikation eine Datei mit einer virtuellen Adresse schafft.
Die virtuelle Adresse, wie diese in der VAT gespeichert ist, wird
auf entweder eine Datei mit der physikalischen Adresse des ALP zeigen
oder unmittelbar auf die physikalische Stelle des ALP. Der wirkliche
Finalisierungsprozess für
die Ausführungsformen,
wie diese oben beschrieben worden sind, wird von einer Applikation
aus initialisiert. Diese Applikation kann über CD2 im Bilde sein oder
nicht. Das Laufwerk, das die Finalisierung durchführt, kann
auch entweder CD2 bekannt sein oder nicht.
-
Ein
anderer Punkt ist, wie das Laufwerk ermittelt, wann das Keylockergebiet
(KLA), das die KL und ALP enthält,
beschrieben werden muss. Auf ideale Weise erfolgt dies unmittelbar
vor dem Schreiben der VAT, bevor die Disk ausgeworfen wird.
-
Das
Laufwerk hat aber keine Möglichkeit
zu wissen, wann die VAT geschrieben wird. Es kostet zu viel um jeden
Block zu untersuchen um zu ermitteln, ob er die VAT ist oder nicht.
Das Laufwerk kann sich nicht auf die Applikation verlassen, ihm
mitzuteilen, wann die VAT geschrieben wird, weil die Applikation
selber dies nicht weiß.
Weiterhin wird die VAT nicht nur dann geschrieben, wenn die Disk
ausgeworfen werden soll, das KLA ideal ist.
-
Eine
durchführbare
Lösung
ist den Auswurfbefehl zu detektieren. Jede stabile und zuverlässige UDF Implementierung
wird die VAT schreiben, bevor die Disk zum Auswerfen freigegeben
wird. Folglich wird, wenn das Laufwerk weiß, dass es das KLA auf einer
Dick mit einem sequentiellen Zugriffstyp schreiben muss und der
UDF Driver die Disk zum Auswerfen freigegeben hat, kann das Laufwerk
auf sichere Weise voraussetzen, dass die VAT geschrieben worden
ist und dass es der letzte gültige
Block auf der Disk sein wird. Eine andere Möglichkeit ist, dass die Applikation
einen Befehl an das Laufwerk gibt, mitzuteilen, das KLA zu schreiben.
-
Nach
der vorliegenden Erfindung ist das Laufwerk imstande, auf die digitalen
Rechteverwaltungsdaten zuzugreifen, die in dem Programmgebiet gespeichert
sind, und zwar durch Verwendung einer Dateiverwaltungssystempegelstruktur,
ohne dass das Dateiverwaltungssystem bekannt ist. Der Vorteil ist,
dass sogar nicht konforme oder unbekannte Implementierungen die
Information festhalten. Text
in der Zeichnung
| Fig.
1 | | | |
| Aus | | | |
| Fig.
2a | | | |
| Einführung | Programmgebiet | Ausführung | |
| Fig.
2b | | | |
| Einführung | reservierte
Spur | teilweise
aufgezeichnete Spur | Ausführung |
| Nicht
aufgezeichnet | | | |
| Fig.
2c | | | |
| Einführung | reservierte
Spur | teilweise
aufgezeichnete Spur | Ausführung |
| Nicht
aufgezeichnet | | | |
| Fig.
3a | | | |
| Einführung | Programmgebiet | Ausführung | |
| Nicht
aufgezeichnet | | | |
| Fig.
3b | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
3c | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
4a | | | |
| Einführung | Programmgebiet | Ausführung | |
| Nicht
aufgezeichnet | | | |
| Fig.
4b | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
4c | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
5a | | | |
| Einführung | Programmgebiet | Ausführung | |
| Nicht
aufgezeichnet | | | |
| Fig.
5b | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
5c | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
6 | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| IUVD
Struktur | | | |
| Name | | Inhalt | |
| Deskriptoranhänger | | Anhänger | |
| Volumendeskriptorfolgenummer | | Einheit
32 | |
| Implementierungsidentifizierer
() | | Entität-ID | |
| ALP
Zeiger | | n | |
| Reserviert | | | |
| Virtuelle
Zuordnungstabellenstruktur | | | |
| Name | | Inhalt | |
| Länge des
Headers | | Einheit
16 | |
| Länge der
Implementierungsverwendung | | Einheit
16 | |
| Logischer
Volumenidentifizierer | | | |
| Vorhergehende
VAT ICB Stelle | | Einheit
32 | |
| Anzahl
Dateien | | Einheit
32 | |
| Implementierungsverwendungsbytes | | | |
| VAT
Eingabe 0 | | Einheit
32 | |
| Fig.
7a | | | |
| Einführung | Programmgebiet | Ausführung | |
| Nicht
aufgezeichnet | | | |
| Fig.
7b | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
7c | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Fig.
8 | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |
| Virtuelle
Zuordnungstabellenstruktur | | | |
| Name | | Inhalt | |
| Länge des
Headers | | Einheit
16 | |
| Länge der
Implementierungsverwendung | | Einheit
16 | |
| Logischer
Volumenidentifizierer | | | |
| Vorhergehende
VAT ICB Stelle | | Einheit
32 | |
| Anzahl
Dateien | | Einheit
32 | |
| Implementierungsverwendungsbytes | | | |
| VAT
Eingabe 0 | | Einheit
32 | |
| Fig.
9a | | | |
| Einführung | Programmgebiet | Ausführung | |
| Nicht
aufgezeichnet | | | |
| Fig.
9b | | | |
| Einführung | nicht
aufgezeichnet | Ausführung | |