NO320055B1

NO320055B1 - Prosessering av opphavsrettsbeskyttet informasjon (data)

Info

Publication number: NO320055B1
Application number: NO20012130A
Authority: NO
Inventors: Masayuki Kozuka; Katsumi Tokuda; Yukako Otani; Masaya Yamamoto; Mitsuhiro Inoue; Yukie Shoda; Masataka Minami; Noboru Hirata
Original assignee: Matsushita Electric Ind Co Ltd
Priority date: 1999-09-01
Filing date: 2001-04-30
Publication date: 2005-10-17
Also published as: NO20012130D0; BR0007049A; DE60017515T2; WO2001016672A1; EP1081574B1; CN1249547C; CA2348771A1; CN1321266A; DE60017515T8; NO20012130L; EP1081574A1; DE60017515D1

Description

Teknisk område

Denne oppfinnelse gjelder en fremgangsmåte og et apparat for prosessering av informasjon (data) som er beskyttet, enten opphavsrettslig eller industrirettslig på annen måte. Særlig gjelder oppfinnelsen prosessering av slik informasjon ved overføring via et kommunikasjonsnett.

Den bakenforliggende teknikk

I de senere år har forskjellige typer informasjon mer blitt vidt tilgjengelig, og man har kunnet distribuere store antall digitale produksjonselementer ved hjelp av forskjellige typer media, herunder det som benevnes multimedia, idet slike produksjonselementer omfatter overføring av bilde og lyd, herunder levende bilder (film og videoopptak). Slik informasjon eller slike produksjonselementer på digital form kan komme ut til brukerne ved hjelp av opptaksmedia så som CD-ROM eller kommunikasjonsmedia så som det globale kommunikasjonsnett Internett. Særlig er nedlasting av digital informasjon til egne mindre datamaskiner av typen PC via et kommunikasjonsnett en konvensjonell måte å spre informasjon på, og av denne grunn er dette forventet brukt i stadig større utstrekning. Produksjonselementer av slik type er også lette å kopiere uten at det finner sted noen degradering, og av denne grunn er det et stort behov for å kunne beskytte rettighetene.

Flere konvensjonelle virkemidler har vært i bruk for dette: Et første eksempel er en innholdskontrollmetode som brukes i et musikkdistribusjonssystem og er publisert som: "Internet-based music distribution requires immediate improvements in copyright protection technologies", Nikkei Electronics, utgave 738, 8. mars 1999, pp 87-111. Denne fremgangsmåte går ut på at en datamaskinfil med kryptert musikk på digital form (musikkdata)

(heretter benevnt fil A) og en fil som inneholder kontrollinformasjon, en dekrypterings-nøkkel for dekryptering av den første fil, filen A, og en eller flere andre filer (herunder kalt filen B) distribuert via et kommunikasjonsnett. For å avspille musikken (disse musikkdata) fra fil A må imidlertid først undersøkes, ut fra den kontrollinformasjon som ligger i fil B, om fil A kan avspilles eller kopieres ut fra eventuelle rettighetsbestemmelser.

Den kjente teknikk skal nå gjennomgås nærmere, og det vises da til tegningene, idet fig. 46 og 47 gjelder slik teknikk. Således viser fig. 46 et blokkskjema over et apparat for prosessering av rettsbeskyttet informasjon, i den første utførelse. Dette apparat er koplet til et kommunikasjonsnett (som ikke er vist) når det brukes, og det inneholder et lager 101 for data som skal distribueres, nemlig innholdet i filen A, for distribusjon via et kommunikasjonsnett så som Internett og/eller et kabelfjernsynsnett. I et rettsregister 102 lagres filen B, idet dennes innhold også distribueres via kommunikasjonsnettet og korresponderer med innholdet i filen A. En salgsprosessor 103 står i forbindelse med en beløpsbelastningsserver (ikke vist) for å selge tjenester som har med rettsbeskyttelsen å gjøre og som gjelder avspilling av spillbar informasjon og andre prosesser, idet de solgte rettigheter eller en betalt avgift for å få utnytte disse rettigheter blir lagret i rettsregisteret 102. Når en instruksjon føres inn ved å bruke en inngangsenhet 104 fastslås i en styreenhet 105, ut fra de rettigheter som ligger lagret i registeret 102, om instruksjonen skal utføres eller ikke. En spiller 106 mottar, dersom instruksjonen skal utføres, en dekrypteringsnøkkel som er lagt inn i fil B, fra styreenheten 105, slik at musikken i fil A kan spilles.

Som et andre eksempel er det i det japanske patentskrift nr. 9-320192 (som i 1998-1999 ennå ikke var gjort tilgjengelig) beskrevet en måte å unngå uautorisert kopiering av krypterte digitale data. Fig. 47 viser hvordan et apparat for å hindre uautorisert bruk av distribuert informasjon arter seg, og dette apparat er særlig slik at data som leses ut fra et lagringsmedium så som en plate 111 først blir kryptert før det formidles via en felleslinje 114 (buss). Dette skjer ved at en første formatenhet 112 legger til en krypteringsstartinfor-masjon, en krypteringsnøkkel, informasjon om en krypteringsenhet, overordnet kopierings-informasjon som gjelder om data kan kopieres eller ikke og identifikasjonsinformasjon for en krypteringsalgoritme som skal brukes, til de data som leses ut fra platen 111. En etterfølgende krypteringsenhet 113 sørger deretter for kryptering av de tilførte data ved å bruke den krypteringsnøkkel som gjelder, idet denne nøkkel gis ut fra en nøkkel-utleveringsenhet 110. Først da kan de krypterte data overføres til felleslinjen 114. Ved uttak av disse eller tilsvarende data fra denne linje brukes en dekrypteringsenhet 115 for dekryptering, ved å bruke en tilsvarende dekrypteringsnøkkel som også tas ut fra nøkkelutleveringsenheten 110, og de dekrypterte data blir deretter tilbakeomvandlet i en andre formatenhet 116, til det format de hadde i platen 111, hvoretter de kan avspilles i en spiller 117.

På denne måte kan man i en første utgave hvor det brukes krypteringsteknikk prosessere rettsbeskyttede data når det er betalt for dette, og i samsvar med det andre eksempel på den kjente teknikk kan beskyttede data også beskyttes fra uautorisert kopiering.

I henhold til denne kjente teknikk har man imidlertid ikke nok detaljer om hvordan man skal håndtere mottatte data som er underlagt beskyttelse, og særlig er det ikke angitt hvordan et format skal tilpasses for best mulig håndtering av rettsbeskyttede data i et apparat for prosessering.

I et musikkdistribusjonssystem vil for eksempel et dataprosesseringsapparat for prosessering av musikkdata motta slike data via et kommunikasjonsnett, og kopiering av de mottatte data vil foregå, til et eksternt lagringsmedium. Apparatet kan hente inn musikkdata fra mange tilbydere, og siden hver tilbyder har sitt eget rettighetsforhold vil disse data måtte distribueres innenfor et format som er unikt for hver av dem. Musikkdata kan også kopieres til forskjellige typer eksterne lagringsmedia så som DVD-RAM og lagerkort, og når dette foregår må de aktuelle musikkdata omvandles til et format som er nærmere angitt for hver type medium.

Under forhold hvor mange tilbydere og musikkleverandører er tilgjengelige og hvor man i tillegg har mange typer eksterne lagringsmedia vil de distribuerte og rettsbeskyttede musikkdata ikke effektivt kunne prosesseres i henhold til den allerede kjente teknikk, siden denne teknikk ikke nærmere angir hvilket format disse data skal prosesseres til/i.

Andre eksempler på nærliggende kjent teknikk kan finnes i patentskriftene WO 97/14087 A, WO 97/37316 A og US 5 715 403 A.

Kort gjennomgåelse av oppfinnelsen

På denne bakgrunn er det et mål med den foreliggende oppfinnelse å fremskaffe et apparat som kan behandle rettsbeskyttede data for effektiv omvandling av slike data som er distribuert via et kommunikasjonsnett, til et internt format som er egnet for den etterfølgende aktuelle prosess.

Oppfinnelsen er nærmere angitt i patentkravene, og særlig gjelder den, i et første aspekt et slikt apparat for prosessering av data og innrettet for å utføre slik prosessering av rettsbeskyttede data innenfor en ervervet rettighet, og som er kjennetegnet ved et lager for å oppta data i et egnet distribusjonsformat og som omfatter minst et innhold for beskyttelse og belastningsinformasjon som bestemmer hvordan en betalingsbelastning skal foregå for innholdet, salgselementer for prosessering av betaling basert på belastningsinformasjonen og komme frem til en salgsstatus som trengs for prosesseringen av innholdet, et rettsregister for å lagre denne salgsstatus fremkommet fra salgselementene, dataomvandlere for omvandling av de distribusjonsformaterte data som inneholder innholdet, til internformaterte data uten belastningsinformasjonen når salgsstatus er etablert for innholdet, et internlager for lagring av disse internformaterte data fra omvandlerne, og prosessutførelseselementer for å utføre prosesseringen av de internformaterte data som ligger lagret i internlageret, med den salgsstatus som ligger lagret i rettsregisteret.

Med et slikt dataprosesseringsapparat vil de data som er underlagt rettsbeskyttelse kunne omvandles til et internformat uten at fakturerings- eller belastningsinformasjon er tatt med, for deretter å bli lagret. Av denne grunn kan disse data behandles på forskjellig måte under overordnet styring hvor rettsbeskyttelsen ivaretas, ved hjelp av en uniform prosedyre og uavhengig av hvilken betalingsbelastningsmåte man benytter.

Videre kan apparatet være slik at de data som representerer innholdet foreligger i kryptert form, at belastningsinformasjonen innbefatter en dekrypteringsnøkkel for dekryptering av innholdet, at dataomvandlerne tar ut denne nøkkel fra belastningsinformasjonen, at nøkkelen lagres i rettsregisteret, og at prosessutførelseselementene utfører dekryptering av det krypterte innhold ved hjelp av nøkkelen i rettsregisteret. På denne måte kan dekrypteringsnøkkelen kunne holdes i rettsregisteret slik at dekrypteringen kan utføres med en og samme fremgangsmåte uavhengig av hvordan man velger å distribuere denne dekrypteringsnøkkel.

Apparatet kan videre være slik at de distribusjonsformaterte data inneholder data som representerer innholdet, belastningsinformasjonen, en hodedel og navigasjonsinformasjon for å kontrollere og styre prosessutførelsen for prosesseringen av innholdet. Apparatet for behandling av slike data kan altså ha kommando over utførelsen av denne behandling, slik det er ment å gjøres fra den som har etablert innholdet, idet styre- og kontrollinformasjon for utførelse av behandlingen benyttes.

Apparatet kan videre være slik at de internformaterte data helt tilsvarer de data som er fremkommet ved å skille belastningsinformasjonen fra de distribusjonsformaterte data. På denne måte blir behandlingen i dataomvandlerne enkel, og samtidig kan behandlings-hastigheten i apparatet i de forskjellige utførelser økes.

I et andre aspekt av oppfinnelsen og som er relatert til det første aspekt kan apparatet være slik at prosessutførelseselementene inneholder en overføringsenhet som kan kopiere over de internformaterte data som ligger lagret i internlageret, til et uttakbart eksternt lagringsmedium, idet dataomvandleren omvandler de distribusjonsformaterte data til internformaterte data, basert på en bestemt type av det eksterne lagringsmedium. Særlig foretrekkes at apparatet omfatter en medieindikator for å registrere hvilken type eksternt lagringsmedium det gjelder, ved hjelp av et indikasjonssignal, slik at dataomvandleren kan utføre formateringsomvandlingen ut fra den indikerte type lagringsmedium, indikert av medieindikatoren ved hjelp av indikasjonssignalene.

I et slikt apparat omvandles altså de rettsbeskyttede data til et internformat som er egnet for den aktuelle type lagringsmedium, hvoretter de omvandlede data lagres. På denne måte kan man redusere datamengden i apparatet.

Apparatet kan videre være slik at de distribusjonsformaterte data inneholder et eller flere elementer i form av innholdet, mens de internformaterte data bare inneholder innhold som skal kopieres til lagringsmediet, blant disse elementer i innholdet. Ved bare å velge ut og lagre det ønskede innhold kan datamengden reduseres betydelig.

I et tredje aspekt av oppfinnelsen gjelder denne en fremgangsmåte for prosessering av data og innrettet for å utføre slik prosessering av rettsbeskyttede data innenfor en ervervet rettighet, og som er kjennetegnet ved å oppta data i et egnet distribusjonsformat og som omfatter minst et innhold for beskyttelse og belastningsinformasjon som bestemmer hvordan en betalingsbelastning skal foregå for innholdet, prosessering av betaling basert på belastningsinformasjonen og komme frem til en salgsstatus som trengs for prosesseringen av innholdet, å lagre denne salgsstatus fremkommet fra salgselementene, omvandling av de distribusjonsformaterte data som inneholder innholdet, til internformaterte data uten belastningsinformasjonen når salgsstatus er etablert for innholdet, lagring av disse internformaterte data fra omvandlerne, og utføre prosesseringen av de internformaterte data med den salgsstatus som er gitt ved lagringen ovenfor.

Et fjerde aspekt av oppfinnelsen gjelder et opptaksmedium for opptak av et program for å utføre denne fremgangsmåte i henhold til det tredje aspekt av oppfinnelsen, ved hjelp av en datamaskin. I det tredje eller fjerde aspekt av oppfinnelsen kan altså de rettsbeskyttede data omvandles til internformaterte data uten å ta med informasjon som gjelder betaling for rettighetene, for deretter å bli lagret. Av denne grunn kan disse data behandles på forskjellig måte under håndtering av rettsbeskyttelsen og ved hjelp av en enhetlig prosedyre, uavhengig av hvilken måte betalingen formidles på. Som angitt ovenfor kan oppfinnelsens fremgangsmåte og apparat gi god brukervennlighet, og fremgangsmåten viser seg ganske effektiv i praktisk bruk.

Hensikten med oppfinnelsen og de nærmere detaljer ved denne vil bli forklart nærmere i den beskrivelse som følger, og samtidig vises til tegningene som er satt opp i en oversikt nedenfor:

Kort gjennomgåelse av tegningene

Fig. 1 viser blokkskjematisk hvordan en første utførelse av et apparat ifølge oppfinnelsen er bygget opp, fig. 2 viser skjematisk et musikkdistribusjonssystem som bruker et slikt apparat, fig. 3a-c viser formater for musikkdata som skal håndteres av apparatet ifølge den første utførelse av oppfinnelsen, fig. 4 viser et eksempel på et register for håndtering av salg, i dette apparat, fig. 5 viser et eksempel på et register for håndtering av rettigheter i samme apparat, fig. 6 viser et flytskjema over det som utføres i en styreenhet i dette apparat, fig. 7 viser tilsvarende for en salgsprosessor i samme apparat, fig. 8 viser et skjema over musikkdistribusjonssystemet som bruker dette apparat, fig. 9 viser et blokkskjema over et tilsvarende apparat i en andre utførelse, fig. 10 viser et flytskjema over det som utføres i en dataomvandler i dette apparat i den andre utførelse, fig. 11 viser et tilsvarende flytskjema over nærmere detaljer i det som utføres i denne dataomvandler, fig. 12 viser et eksempel på en tabell eller et register for håndtering av pakkeoverføringer, i dette apparat, fig. 13a-c viser skjemaer over virkningen av dataomvandlingen i dette apparat, fig. 14 viser et diagram over et annet format for musikkdata som håndteres av apparatet i den andre utførelse, fig. 15 viser et flytskjema over oppbyggingen av et apparat i en tredje utførelse, fig. 16 viser en skjerm for å spesifisere et eksternt lagringsmedium for dette apparat, fig. 17 viser et flytskjema over det som utføres i en dataomvandler i apparatet i denne tredje utførelse, fig. 18 viser oppbyggingen av en såkalt SDAF-pakke i en tredje utførelse av oppfinnelsen, fig. 19a-19c viser andre strukturer for slike pakker, fig. 20 viser et skjema over hvordan man kan dele opp en SDAF-tittel i flere SDAF-pakker, fig. 21 viser et skjema over et eksempel på en SDAF-pakke, fig. 22 viser et diagram over strukturen i en hodedel, fig. 23 og 24 viser de kildekoder som beskriver hodedelen, idet det er brukt programmeringsspråket C++, fig. 25a-25c viser skjematisk hvordan en CEL-attributtabell brukes ved hjelp av en merkestruktur, fig. 26 viser et skjema over korrespondansen mellom nøkkelpar og CEL-enheter, fig. 27 viser kildekoder som beskriver nøkkelparstrukturen, også ved bruk av språket C++, fig. 28 viser skjematisk sammenhengen mellom CEL og navigasjonsdata, fig. 29 viser et skjema over oppbyggingen av slike navigasjonsdata, fig. 30 viser samme i et annet eksempel, fig. 31 viser en tabell over spesifikasjonene for MPEG2-AAC for en audio-CEL, fig. 32 viser en tabell over JPEG-spesifikasjonene brukt for en avbildnings-CEL, fig. 33 viser spesifikasjonene for en MPEG-I-ramme brukt for samme, fig. 34 viser en tabell over spesifikasjonene for PNG brukt for samme, fig. 35 viser en tabell over spesifikasjonene for MPEG2 brukt for en video-CEL, fig. 36 viser et skjema over et tidssøkekart, fig. 37, 38a og 38b viser en tabell og skjemaer over hodedelen i dette tidssøkekart, fig. 39 viser en tabell over inngangene i samme, fig. 40 viser en tabell over et eksempel på CEL-omdirigeringer, fig. 41a-41c viser skjemaer over eksempler på hvordan man kan distribuere en SDAF-pakke, fig. 42a-42c viser hvordan en slik pakke kan frembringes fig. 43 viser en bærbar musikkspiller sett utenfra, fig. 44 viser blokkskjematisk hvordan en omvandler for musikk på digitalt format er bygget opp, fig. 45 viser blokkskjematisk et annet eksempel på samme, fig. 46 viser et blokkskjema over oppbyggingen av et konvensjonelt dataprosesseringsapparat, allerede omtalt innledningsvis i beskrivelsen, og fig. 47 viser et tilsvarende blokkskjema over et konvensjonelt apparat for beskyttelse av rettigheter, også omtalt innledningsvis.

Gjennomgåelse av oppfinnelsen, herunder den beste måte å utføre den på

Oppfinnelsen skal også beskrives i nærmere detalj, og det vises til tegningene. Først beskrives tre utførelser av et apparat ifølge oppfinnelsen, for omvandling av data og konvertering av distribuerte data som er rettsbeskyttet, til et forhåndsbestemt internt format. Deretter beskrives, som et fjerde eksempel hvordan de data som håndteres i den første til tredje utførelse av apparatet, arter seg.

Merk at de beskyttede data i henhold til den fjerde utførelse mer er tatt med som et eksempel på det som allerede er beskrevet for den første til den tredje utførelse, og det er innlysende at apparatet ifølge disse første tre utførelser også kan håndtere andre beskyttede datatyper. Videre behøver ikke de aktuelle data som håndteres være i form av musikk på digital form (musikkdata), men beskyttede data av enhver form vil kunne håndteres av apparatene, blant annet bildedata, tekstdata eller kombinasjoner av disse typer og musikkdata.

Fig. 1 viser et blokkskjema over oppbyggingen av det dataprosesseringsapparat som er i samsvar med en første utførelse av oppfinnelsen. Apparatet 1 vist på fig. 1 omfatter en inngangsenhet 10, et lager 11 for distribuerte data, et salgsregister 12 som kan arte seg som en tabell for håndtering av salg av rettigheter, en salgsprosessor 13, en "dataomvandler 14, et internlager 15, et register 16 som her er kalt et rettsregister og kan arte seg som en tabell for håndtering av rettigheter, en styreenhet 17, en spiller 18, en overføringsenhet 19 og en visningsenhet 21. Apparatet 1 utfører spilling, kopiering og andre prosesser på distribuerte og rettsbeskyttede musikkdata og er særlig kjennetegnet ved at disse data omvandles til et internformat for lagring.

Før gjennomgåelsen av apparatet 1 skal kort forklares hvordan forskjellige musikkdistribusjonssystemer som bruker slike apparater arter seg og hvordan formatene for musikkdata som håndteres i apparatene typisk er, og det vises da til fig. 2 og 3.

På fig. 2 vises hvordan apparatet 1 ifølge oppfinnelsen, for prosessering av data, er koplet via et kommunikasjonsnett 4 til en distribusjonsenhet DS som kan kalles en distribu-sjonsserver 5 og en tilsvarende enhet BBS som har med betaling/salg/fakturering å gjøre og derfor her vil bli kalt en betalingsbelastningsserver 6. Kommunikasjonsnettet 4 kan være et globalt nett så som Internett, et mer lokalt nett for kabelfjernsyn, et nett som inneholder satellittsamband eller et telefonnett for blant annet mobiltelefoner. Distribusjonsserveren 5 lagrer typisk store mengder rettsbeskyttede musikkdata. I respons på en forespørsel fra apparatet 1 sender denne server 5 ut disse musikkdata. Betalingsbelastningsserveren 6 utfører en betalingsprosess for disse data. Det eksterne lagringsmedium 7 kan være i flere eksemplarer og er innrettet for å kunne tas ut fra både apparatet 1 og en bærbar spiller 8 for avspilling av musikk. Apparatet 1 identifiserer hvert medium 7 ved å bruke en identifikator som er unik for hvert slikt medium, eller et etikettnavn som er spesifisert for hvert av dem av brukeren.

Håndtering av rettsbeskyttelsen for overført musikk på digital form (musikkdata) skal nå gjennomgås kort. Serveren 5 sender da ut kryptert musikk og dekrypteringsnøkler for dekryptering, til apparatet 1 som videreformidler informasjon om at en bruker eventuelt er villig til å betale for denne musikk, til serveren 6, før eller etter overføringen, slik at det blir solgt en prosessrett som er knyttet til denne overførte musikk. Apparatet 1 kan for eksempel spille tilbake musikken ved å bruke dekrypteringsnøklene, så mange ganger som det er spesifisert ut fra den rettighet det er betalt for.

Apparatet kan videre kopiere musikken og dekrypteringsnøklene til det eksterne medium 7 (idet en slik prosess kan kalles "check-in". Apparatet 1 kan overføre musikken så mange ganger som det er spesifisert ved betalingen av rettighetene. En overføringsrett som tillater en enkelt overføring blir inndekket når de overførte data sendes. Musikken kan imidlertid bare overføres av samme apparat som har sendt ut samme. Dersom det eksterne lagringsmedium som opphavsrettsbeskyttet musikk er overført til blir overskrevet vil apparatet ikke overføre musikken.

Den musikk som håndteres av apparatet 1 innbefatter, i tillegg til audioinnholdet, også innhold så som video, bildedata, tekst og programmer. Fig. 3a-3c viser skjemaer over tre musikkdataformater som håndteres av apparatet 1. Et format som er vist på fig. 3a brukes for å fordele disse musikkdata, et internformat som er vist på fig. 3b brukes for å lagre disse data i apparatet 1, og et kopiformat vist på fig. 3c brukes for å overføre musikkdata til det eksterne lagringsmedium 7.

Musikken fordeles utover til apparatet 1 av en enhet som er kalt pakke. I det distribusjonsformat som er vist på fig. 3a er denne pakke sammensatt av fire datasekvenser: en hodedel 40, navigasjonsinformasjon 41, et eller flere innhold 42 og belastningsinformasjon 43 for hvilken økonomisk belastning som skal knyttes til musikkoverføringen. Hodedelen

40 innbefatter informasjon så som en pakkeidentifikator for å identifisere pakken, og informasjon om posisjon og størrelse av andre datasekvenser. Innholdet 42 er innholdsdata så som audio, video, bilder, tekst eller programmer. Hvert innhold har sin egen identifikator som er unik i pakken og blir kryptert etter behov.

Navigasjonsinformasjonen 41 brukes som avspillingskontrollinformasjon for å kontrollere og styre avspillingen av musikkdata. For referanse til hvert innhold 42 fra navigasjonsinformasjonen 41 brukes innholdsidentifikatoren. Et innhold som hører til i pakken som navigasjonsinformasjonen hører til, refereres til bare med den tilhørende innholdsidentifikator, mens et innhold i en annen pakke refereres til ved hjelp av pakkeidentifikatoren og innholdsidentifikatoren. Belastningsinformasjonen 43 innbefatter en bruks-betingelse, pris og en dekrypteringsnøkkel for hvert innhold 42.

I apparatet 1 håndteres musikkdata med belastningsinformasjonen 43 fraskilt. I det internformat som er vist på fig. 3b er disse musikkdata sammensatt av hodedelen 40, navigasjonsinformasjonen 41 og innholdet eller innholdene 42.

De aktuelle musikkdata omvandles til et format som passer den type eksterne lagringsmedia 7 før overføringen finner sted. Dersom et slikt medium 7 for eksempel er et SD-lagerkort (sikkert digitalt lager) vil de aktuelle musikkdata omvandles til et format slik at audioinnholdet for dette kort innbefattes, men ikke eventuelt videoinnhold. I det kopiformat som er vist på fig. 3 c sammensettes de aktuelle musikkdata av en hodedel 44, innholdet 42 og en dekrypteringsnøkkel 45. Hodedelen samsvarer med typen for det eksterne lagringsmedium 7, mens dekrypteringsnøkkelen 45 trekkes ut fra belastningsinformasjonen 43 i distribusjonsformatet. Innholdet 42 er innholdsdata som er valgt ut ut fra typen eksternt lagringsmedium 7 fra de musikkdata som ligger i internformatet. De musikkdata som er vist på fig. 3 c innbefatter bare et enkelt innhold 42, men kan ha ytterligere inn-holdssekvenser. Når disse musikkdata overføres kan de deles opp i kopiformatet, til flere filer for kopiering.

Fig. 1 viser videre hvordan oppbyggingen av apparatet 1 er. Hvordan apparatet 1 brukes skal også gjennomgås. De distribuerte musikkdata omvandles til et internformat i den viste dataomvandler 14 og lagres deretter i internlageret 15. Informasjon om retten til å prosessere hvert innhold i disse musikkdata ligger lagret i rettsregisteret 16. Styreenheten 17 refererer til dette register for å avgjøre om instruksjoner 30 som tilføres skal utføres eller ikke. Skal de det sørger enheten 17 for instruksjoner om starting av spilling, overføring og andre prosesser.

Brukeren legger inn disse instruksjoner 30 for innholdet, i inngangsenheten 10. Instruksjonene som gjelder for den første utførelse av apparatet er for distribusjon, salg, spilling, overføring den ene og den andre vei. I tillegg innbefatter andre eksempler forflytting, modussetting, kommandoer for dataklassifikasjon, dataredigering, datasøk, import, eksport, tilføyelse av brukerdata, inntak av fjernet innhold og autorisasjonskontroll.

Lageret 11 for distribuerte data lagrer musikk (musikkdata) i et format som gjør innholdet egnet til distribusjon ved hjelp av distribusjonsserveren 5. I salgsregisteret 12 lagres, slik det er vist på fig. 4, en pakkeidentifikator 50, en innholdsidentifikator 51 og en salgsstatus 52, til sammen et sett for hvert innhold i de musikkdata som ligger lagret i lageret 11. Salgsstatus blir spesifisert ved salget av rettighetene for å kunne utnytte innholdet. En slik status innbefatter for eksempel bare spilling, fullt salg og prøvelytting. Er status bare gjeldende spilling kan innholdet spilles et bestemt antall ganger eller bare innenfor en bestemt periode. Gjelder det fullt salg kan innholdet spilles av helt fritt og over-føres ved kopiering, men da bare et bestemt antall ganger. Er situasjonen prøvelytting kan innholdet avspilles et ubegrenset antall ganger innenfor en bestemt tidsperiode.

Når instruksjonene 30 mottas fra inngangsenheten 10 for salg sender salgsprosessoren 13 informasjon om at brukeren har gått med på å betale for de mottatte musikkdata til beløpsbelastningsserveren 6 (BBS) slik at vedkommende får rett til disse distribuerte musikkdata. Deretter registrerer salgsprosessoren 13 rettighetene for den solgte prosess i salgsregisteret 12. Er det spesifiserte innhold ikke lagret i lageret 11 sender salgsprosessoren 13 ut en forespørsel til serveren 5 om å distribuere de musikkdata som inneholder det aktuelle innhold. Etter å ha mottatt disse musikkdata sørger salgsprosessoren 13 for å over-føre informasjon til dataomvandleren 14 sammen med et styresignal 31 for å instruere om dataomvandlingen.

Ved mottakingen av styresignalet 31 omvandler dataomvandleren 14 disse musikkdata til det riktige internformat, idet dataomvandleren 14 da skiller belastningsinformasjonen 43 fra den distribuerte datapakke for å få de aktuelle musikkdata i det interne format. Omvandleren 14 trekker også ut dekrypteringsnøkkelen 54 for hvert innhold, fra denne belastningsinformasjon 43 og registrerer inn nøkkelen 54 i rettsregisteret 16.

Internlageret 15 lagrer musikkdata i det internformat som etableres i omvandleren 14, og denne lagrede musikk i form av musikkdata kan 'da avspilles, kopieres ut og liknende.

I rettsregisteret 16 ligger informasjon som har med rettsbeskyttelsen å gjøre, slik det er vist på fig. 5, for hvert innhold i internlageret 15. Rettsregisteret 16 inneholder som allerede nevnt elementene 50-52, og i tillegg datoen 53 for salget av rettighetene, den allerede dekrypteringsnøkkel 54, en oppgave over antallet tillatte avspillinger, i form av et antall 55, et tilsvarende antall 56 overføringer ("check-outs"), og mottakerinformasjon 57 for bestemmelsesstedet for overføringen. Merk at fig. 5 viser en enkelt tabell som utgjør registeret, idet denne tabell er delt i to deler som er angitt med a og b, og hvor antallet 55 avspillinger følger dekrypteringsnøkkelen 54 i denne tabell eller dette register 16, før oppdelingen.

Elementene 50-52 er de samme som i salgsregisteret 12, mens datoen 53 angir når innholdet ble solgt. Dekrypteringsnøkkelen 54 brukes for å dekryptere det krypterte innhold. Antallet 55 avspillinger angir hvor mange ganger innholdet er avspilt. Antallet 56 over-føringer indikerer hvor mange ganger innholdet er overført. Mottakerinformasjonen 57 angir en lagringsmedieidentifikator og et etikettnavn for det eksterne lagringsmedium som innholdet er overført til. Etikettnavnet er tildelt det eksterne lagringsmedium når musikkdata først overføres dit.

Elementene 50-54 nevnt ovenfor er satt til forhåndsbestemte verdier når nye musikkdata lagres i internlageret 15. Elementene 50-52 settes til verdier som fremskaffes fra salgsprosessoren 13, mens dekrypteringsnøkkelen 54 settes til en verdi som fremkommer fra dataomvandleren 14. Antallene 55 og 56 settes innledningsvis til null mens mottakerinformasjonen 57 for overføringen klareres. Rettsregisteret 16 er kryptert ved hjelp av en metode som er unik for det aktuelle apparat 1, for beskyttelse mot utilsiktet datainngrep.

Styreenheten 17 bruker rettsregisteret 16 som referanse for å finne om instruksjonene 30 skal utføres eller ikke. Finnes at de skal utføres setter styreenheten 17 i gang med å overføre instruksjoner for starting av spilling eller overføring. I flytskjemaet vist på fig. 6 er indikert hvordan styreenheten 17 arbeider. Når instruksjonene 30 for innholdet (trinn S101) mottas leser styreenheten 17 den beskyttede informasjon om innholdet fra rettsregisteret (trinn Sl02). Enheten 17 bruker deretter denne informasjon til å bestemme om instruksjonene 30 skal utføres eller ikke (trinn Sl03). Når man får en instruksjon om avspilling vil styreenheten 17 ha referanse til antallet tillatte spillinger eller den tillatte spilleperiode som ligger i salgsstatus 52. Er ikke antallet spillinger som er gjennomført større enn det tillatte maksimale antall eller hvis den aktuelle dag ligger innenfor den tillatte avspillingsperiode etter datoen 53 for salgstransaksjonen fastslås i styreenheten 17 at avspillingsinstruksjonene kan iverksettes.

Finnes at instruksjonene skal iverksettes oppdaterer styreenheten 17 antallet 55 avspillinger, antallet 56 overføringer eller andre relevante trinn som tilsvarer elementer i rettsregisteret 16 (trinn S104). Enheten 17 sender deretter ut et styresignal 32 for å starte prosessen, idet dette signal går til en relevant prosessor (trinn Sl05). Ved dette tidspunkt sender også enheten 17 ut dekrypteringsnøkkelen 54 som tas ut fra registeret 16, idet denne nøkkel er lagt inn i styresignalet 32. På den annen side er det slik at når det avgjøres om instruksjonene skal iverksettes eller ikke sender enheten 17 ut styresignalet 32 for å gi et varselbilde i visningsenheten 21 (trinn Sl 06).

Når spilleren 18 mottar styresignalet 32 for å starte avspilling leses det spesifiserte innhold i de aktuelle musikkdata og som ligger lagret i internlageret 15, slik at avspillingen kan utføres for innholdet og ved hjelp av nøkkelen 54. Når signalet 32 tas imot for å starte overføring leser overføringsenheten 19 det spesifiserte innhold fra samme musikkdata og omvandler det til det aktuelle kopiformat, hvoretter enheten 19 skriver de omvandlede musikkdata inn i det eksterne lagringsmedium 7. Når overføringsenheten 19 mottar styresignalet 32 for start av overføringen slettes de musikkdata som er kopiert over til mediet 7.

Overføringsenheten 19 leser også ut medieidentifikatoren 33 fra dette medium 7 og viderefører den til styreenheten 17 som registrerer inn identifikatoren i rettsregisteret etter overføringen. Styreenheten 17 fastlegger også, før overføringen, om slik overføring kan utføres eller ikke, i avhengighet av om identifikatoren 33 er registrert inn i registeret 16 eller ikke.

Når styresignalet 32 tas imot for å gi et varslingsbilde på visningsenheten frembringer denne enhet 21 en varsling på foreskrevet måte og viser dette på en skjerm eller i et vindu med flytekrystaller.

Den dataomvandlingsprosess som karakteriserer apparatet 1 beskrives nedenfor. Det vises til et flytskjema på fig. 7, og først skal gangen i salgsprosessoren 13 gjennomgås for klareringen for å legge til rette for dataomvandling.

Salgsprosessoren 13 mottar først instruksjonene 30 fra inngangsenheten 10 for å utføre salgstransaksjonen for innholdet (trinn S201). Disse instruksjoner spesifiserer innholdsidentifikatoren i det innhold som skal selges og salgsstatus. Salgsbetingelsene som gjelder innholdet vil være de samme som de betingelser som blir bestemt av denne salgsstatus 52 som er vist på fig. 4, innbefattet utelukkende avspilling, fullt salg, prøve-lytting og annet. Deretter kommuniserer salgsprosessoren 13 med beløpsbelastnings-serveren 6 for å utføre beløpsoverføring for det spesifiserte innhold, i henhold til de bestemte salgsbetingelser (trinn S202). Prosessoren 13 utfører betalingsoverføringen ved å referere til belastningsinformasjonen 43 for det spesifiserte innhold. Deretter bestemmer salgsprosessoren 13 om salgsoverføringen er utført eller ikke (trinn S203). Hvis for eksempel prosessoren 13 i trinn S202 sender informasjon til serveren 6 om at brukeren har gått med på å betale for det spesifiserte innhold, i henhold til de spesifiserte salgsbetingelser vil, i trinn S203 prosessoren 13 ved mottakingen av informasjonen fra serveren 6 for bekreftelse av betalingen, kunne avgjøre om betalingen er utført eller ikke. Merk at den betalingsmåte som utføres av prosessoren 13 ikke i det hele tatt er begrenset til det som er indikert ovenfor.

Har salgsprosessen blitt avsluttet vellykket kan prosessoren 13 deretter avgjøre om det spesifiserte innhold ligger lagret i lageret 11 eller ikke (trinn S204). Er ikke innholdet lagret forespør prosessoren 13 serveren 5 om å overføre de aktuelle musikkdata som inneholder det forespurte innhold (trinn S205). Etterat dette er lagret i lageret 11 sender prosessoren 13 ut styresignalet 31 for omvandling, til omvandleren 14 (trinn S206). Denne omvandler utfører deretter omvandling av de aktuelle musikkdata i det distribusjonsformat som ligger lagret i lageret 11, til internformatet. De omvandlede data lagres i internlageret 15.

Har imidlertid ikke salgsprosessen gått som forventet i trinn S203 sender prosessoren ut et styresignal (ikke indikert) for å bemerke at dette ikke er i orden, til visningsenheten 21 (trinn S207). Når denne enhet mottar et slikt bemerkningssignal som ikke er annet enn et styresignal, kommer et varselbilde opp for å indikere at salget ikke er i orden. Merk at salget regnes å svikte dersom det spesifiserte innhold ikke kan finnes eller ikke kan selges under de bestemte salgsbetingelser, eventuelt dersom betalingsbeløpet er utilstrekkelig, bare for å ta et eksempel.

Som angitt ovenfor utføres dataomvandlingen i apparatet 1 når salgsprosessen er avsluttet på vellykket måte, det vil si når det spesifiserte innhold er solgt under de spesifiserte salgsbetingelser.

Nå skal virkningen av apparatet 1 i samsvar med oppfinnelsen beskrives, i den forstand at apparatet brukes til overføring av musikkdata. Fig. 8 viser et skjema over dette, idet slike musikkdata her overføres fra flere tilbydere eller leverandører og til det aktuelle apparat 1. Disse musikkdata er anordnet i grupper eller sekvenser og inneholder et eller flere innhold 42 og belastningsinformasjon 43 for belastning av brukerne med bestemte beløp. Formatet er unikt for hver leverandør. I innholdet i den overførte musikk er navigasjonsinformasjonen 41 og innholdet 42 uunnværlig for avspilling og andre prosesser, mens belastningsinformasjonen 43 bare trengs for å dekket inn det aktuelle beløp, men ikke for selve den aktuelle avspilling eller annet.

Av denne grunn omvandles de aktuelle musikkdata med et format som er egnet for distribusjon til et annet format, nemlig det allerede beskrevne internformat, ved at belastningsinformasjonen 43 skilles fra. Deretter kan de etterfølgende prosesser utføres på foreskrevet og uniform måte, uavhengig av hvordan betalingen skal utføres.

Dekrypteringsnøkkelen 54 trekkes også ut fra denne belastningsinformasjon 43 for å kunne dekryptere det krypterte innhold 42, og nøkkelen lagres deretter i rettsregisteret 16. På denne måte kan den totale håndteringen av nøkkelen 54 muliggjøre dekryptering i et ensartet prosedyreforløp og uavhengig av hvordan denne nøkkel blir distribuert til brukerne.

Det er videre slik at internformatet er identisk med det distribusjonsformat som ikke inneholder belastningsinformasjonen 43, og av denne grunn kan dataomvandlingen utføres uten dekryptering av krypterte data og deretter ny kryptering. Dette gjør prosessen i dataomvandleren 14 enkel, og prosesseringshastigheten i apparatet 1 bedres.

Det er verdt å merke seg at belastningsinformasjonen 43 trekkes ut fra disse musikkdata i distribusjonsformatet etter omvandlingen, og av denne grunn kan datamengden i apparatet 1 reduseres for denne informasjon 43. Metoden er ganske effektiv dersom informasjonen 43 er stor i volum for en komplisert betalingsprosedyre.

I oppfinnelsens utførelse av apparatet 1 lagres informasjon om rettighetene det skal betales for, i rettsregisteret 16, men alternativt kan hver rettighet i et slikt register 16 vist på fig. 5 tilføyes hver overført pakke slik at man kan håndtere rettighetene pakkevis. Antallene 55 og 56 samt mottakerinformasjonen 57, alle i registeret 16 kan dessuten håndteres sammen i en separat tabell, og på denne måte kan de elementer som bare settes en gang og de elementene som oppdateres hver gang dataomvandling utføres, skilles fra hverandre slik at de håndteres ved hjelp av forskjellige tabeller, og på denne måte bedres datasikkerheten.

I den foreliggende utførelse lagres musikkdata i de to formattyper på forskjellige lågere, eller alternativt kan musikkdata for begge to typer lagres i en enkelt lagringsenhet.

Fig. 9 viser et blokkskjema over oppbyggingen av et apparat 2 som også er i samsvar med oppfinnelsen, men i en andre utførelse av denne. Apparatet 2 vist på fig. 9 har akkurat samme elementer 10-13, 22, 15-19 og 21 som i den første utførelse av apparatet (apparatet 1), med i tillegg medieindikatoren 23. Apparatet 2 brukes for samme musikkdistribusjonssystem som apparatet 1 i den første utførelse, og apparatet 2 er kjennetegnet ved å kunne omvandle distribuerte musikkdata til et internformat ut fra hvilken type registrert eksternt lagringsmedium man har til rådighet. Komponentene i den andre utførelse av apparatet har altså samme henvisningstall som tidligere, og en nærmere beskrivelse av dem utelates derfor.

Det eksterne lagringsmedium 7 kan anta forskjellig form, for eksempel være av typen DVD-RAM, og et lagerkort kan være koplet til apparatet 2. For overføring, kopiering og liknende kan de musikkdata som trengs for omvandling til et kopiformat som er spesifisert for hver type medium være tilrettelagt for senere omvandling til et bestemt kopiformat, idet apparatet 2 omvandler musikkdata i distribusjonsformatet til internformatet, basert på hvilken type medium 7 som foreligger.

Det eksterne lagringsmedium 7 er koplet til den allerede omtalte medieindikator 23 for å registrere hvilken type medium 7 man har, og ut fra indikatoren 23 går et indikasjonssignal 35 for å angi hvilken medietype det er, til dataomvandleren 22. Basert på dette signal 35 omvandler omvandleren 22 de musikkdata som ligger lagret i lageret 11 til det internformat som er forhåndsbestemt for hver type medium 7.

Fig. 10 viser et flytskjema over hvordan dette foregår i dataomvandleren 22. Når et styresignal som indikerer dataomvandling (trinn S301) mottas utfører omvandleren 22 følgende prosesser S302-S306 for de musikkdata som ligger lagret i lageret 11, basert på overføringen av indikasjonssignalet 35: Når dette signal mottas indikerer dette at en DVD-enhet er tilkoplet (trinn S302), og i så fall omvandler omvandleren de aktuelle musikkdata til det internformat som passer til en DVD-RAM (trinn S303). Når signalet 35 indikerer at man har en lagertilpasningsenhet (trinn S304) omvandler omvandleren 22 disse musikkdata til et internformat som passer til et lagerkort (trinn S305). Når annen signalindikasjon mottas sørger omvandleren 22 for å omvandle musikkdata til et generelt internformat slik det er vist på fig. 3b (trinn S306).

Omvandleren 22 omvandler musikkdata til det internformat som gjelder, basert på typen lagringsmedium 7, ved hjelp av følgende prosedyre: Fig. 11 viser et flytskjema over omvandlingen til internformatet for DVD-RAM-enheter, og den prosess som er vist på fig.

11 tilsvarer prosessen i trinn S303 for flytskjemaet vist på fig. 10.

Omvandleren 22 kopierer først hodedelen 40 og navigasjonsinformasjonen 41 som er lagt inn i distribusjonsformatet (trinn S401) og initialiserer en variabel I til 1 (trinn S402). Deretter utfører omvandleren prosessene fra trinn S403 til S407 for hvert innhold 42 og leser en attributt for det I-te innhold fra hodedelen 40 (trinn S403). Basert på denne leseattributt blir det i omvandleren fastlagt om dette innhold skal kopieres til mediet DVD-RAM eller ikke (trinn S404), og dersom dette er tilfellet blir innholdet kopiert til mediet 7 (trinn S405). Deretter inkrementerer omvandleren 22 denne variable I med 1 (trinn S406). Er den variable I ikke større enn antallet innhold går prosedyren tilbake til trinn S403 (trinn S407).

I flytskjemaene vist på fig. 10 og 11 er omvandlingsprosessen for eksterne lagringsmedia av bestemte typer vist. Er disse media av en annen type og koplet til apparatet 2 vil en tilsvarende prosess tilføyes hvert flytskjema.

Styreenheten 17 håndterer aktuelle internformaterte musikkdata ved hjelp av en pakkehåndteirngstabell som er vist på fig. 12. Denne tabell inneholder en pakkeidentifikator 60, antallet 61 filer, et filnavn 62 og en filtype 63. Hver rekke i tabellen på fig. 12 tilsvarer en enkelt pakke.

Pakkeidentifikatoren 60 brukes for å identifisere hver pakke, men dersom hodedelen endres ved omvandlingen fra distribusjonsformatet til internformatet vil en ny pakkeidentifikator tilordnes. Antallet 61 filer gjelder det antall filer som er inkludert i pakken, mens filnavnet 62 angir navnet på hver fil. Filtypen 63 representerer en attributt for filen som er inkludert i pakken. En filtype "distribuert" indikerer at filen er en distribuert fil, mens en filtype "kreert" angir at filen var laget av brukeren.

Virkemåten for apparatet 2 i den andre utførelse skal nå gjennomgås. Fig. 13 viser diagrammer over musikkdata i de tre formatene distribusjonsformatet, internformatet og kopiformatet. Musikkdata i det første av disse, vist på fig. 13a innbefatter audioinnholdet 42-1 og 42-2 og et bildeinnhold 42-3: Det antas her at bare audioinnholdet 42-2 av disse kan overføres til det eksterne lagringsmedium 7, og i dette tilfelle vil musikkdata i kopiformatet vist på fig. 13c bare inneholde dette innhold 42-2.

Ved forventning om senere omvandling til kopiformatet omvandler apparatet 2 de aktuelle musikkdata fra distribusjonsformatet til internformatet, idet dette er vist på fig. 13b, for lagring. Musikkdata i internformatet innbefatter bare audioinnholdet 42-2 som kan over-føres til mediet 7.

Som indikert ovenfor, ved å omvandle de distribuerte musikkdata til internformatet som er egnet for den bestemte type eksternt lagringsmedium 7 vil datamengden i apparatet 2 kunne reduseres. Innholdet 42 er stort når det gjelder data siden både audio og bilder ligger komprimert. Ved derfor bare å lagre innholdet som kan overføres senere kan datamengden reduseres betydelig.

De distribuerte musikkdata kan videre innbefatte flere sekvenser med innhold og fremkommet ved å bruke forskjellige kompresjonsmetoder overfor et enkelt original-datainnhold. Fig. 14 viser et eksempel på slike musikkdata. Det antas at audioinnholdet 42-1 og 42-2 er oppnådd ved å bruke to kompresjonsmetoder overfor et enkelt originaldatainn-hold, og i dette tilfelle vil de navigasjonsdata som brukes innbefatte et audioinnhold 46 som innebærer seleksjon av innholdet, ved at ett innhold kan velges ut fra flere.

Når slike musikkdata spres utover i distribusjon velger dataomvandleren 22 det innhold som kan overføres til det tilkoplede eksterne lagringsmedium 7, ut fra flere tilsvarende innhold. Musikkdata i internformatet innbefatter bare det valgte innhold, og det er slik at hvis det eksterne lagringsmedium for eksempel er et lagerkort vil musikkdata i internformatet bare innbefatte det innhold som kan overføres til dette kort. Ved å velge og lagre innholdet på den måte som er angitt ovenfor vil mengden data som ligger lagret i internlageret 15 kunne reduseres.

Videre er det slik at de distribuerte musikkdata kan innbefatte flere sekvenser med navigasjonsinformasjon 41, basert på hver type eksternt lagringsmedium 7. Også i dette tilfelle vil navigasjonsinformasjon som er egnet for det oppkoplede slike medium 7 velges ut fra flere navigasjonsinformasjonssekvenser, og bare den bestemte navigasjonsinformasjon 41 som velges vil bli lagt inn i musikken med internformatet. Her kan slik navigasjonsinformasjon innbefatte flere programmer som kan håndtere den type data som prosesseres i apparatet eller en bærbar spiller. Hvis videre musikkdata innbefatter flere inn-holdssekvenser som kan håndtere flere språktyper blir innholdet valgt for det aktuelle språk.

Som indikert ovenfor er det slik at selv om musikkdata innbefatter flere inn-holdssekvenser eller flere elementer med navigasjonsinformasjon vil disse data omvandles til internformatet, basert på den type eksternt lagringsmedium man har, hvorved reduksjon av den lagrede datamengde oppnås.

I den foreliggende utførelse kopieres musikkdata til et lagringsmedium av typen DVD-RAM eller et lagerkort. Dersom de rettsbeskyttede data gjelder spilleprogramvare kan det spesifiseres en bestemt spiller, og data overføres da til et lagerkort for denne spiller, etc.

Fig. 15 viser et blokkskjema over oppbyggingen av et dataprosesseringsapparat 3 i samsvar med en tredje utførelse. Apparatet 3 innbefatter de samme elementer som tidligere, nemlig inngangsenheten 10, lageret 11 for distribuerte data, salgsregisteret 12, salgsprosessoren 13, dataomvandleren 22, internlageret 15, rettsregisteret 16, styreenheten 17, spilleren 18, overføringsenheten 19, visningsenheten 21, og i tillegg en spesifikasjonsenhet 24 for å spesifisere hvilken type eksternt lagringsmedium 7 man skal bruke. Apparatet 3 brukes i samme musikkdistribusjonssystem som apparatene 1 og 2 i de allerede gjennomgåtte utførelser og kjennetegnes særlig ved at de musikkdata som distribueres omvandles til et internformat ut fra den bestemte type spesifiserte eksterne lagringsmedium 7 man har til rådighet. Komponentene i den tredje utførelse er altså identiske med dem i den andre og har derfor samme henvisningstall. Gjennomgåelsen av de enkelte komponenter og deres bruk utelates derfor her.

I apparatet 3 spesifiserer brukeren hvilken type medium 7 som skal brukes, via inngangsenheten 10, og ikke bare typen kan spesifiseres for den enhet som er tilkoplet i øyeblikket, men også typen eksternt lagringsmedium som kan koples opp senere. Når brukeren spesifiserer dette viser visningsenheten 21 et bilde som kan arte seg slik det er vist på fig. 16, ved at for eksempel et lagringsmedium av typen DVD-RAM og et lagerkort blir spesifisert. På skjermen fremgår at lagerkortet også spesifiseres, og ved hjelp av et slikt skjermbilde kan altså brukeren spesifisere hvilken type medium som musikkdata skal over-føres til.

Ser vi igjen på fig. 15 fremgår at når instruksjonene 30 for å spesifisere mediet 7 mottas fra enheten 10 blir den aktuelle medietype lagret, ved kommando fra spesifi-kasjonsenheten 24. Dette skjer ved å overføre et spesifikasjonssignal 36 som angir den aktuelle type medium 7 overfor dataomvandleren 22.

På tilsvarende måte som i den andre utførelse av apparatet arbeider denne omvandler 22 i samsvar med et flytskjema som er illustrert på fig. 17. Ut fra spesifi-kasjonssignalet 36 omvandles således de musikkdata som ligger lagret i lageret 11, til internformatet som er forhåndsbestemt for hver spesifisert type medium 7. Skjemaet på fig. 17 tilsvarer det som er vist på fig. 10 og behøver derfor ikke gjennomgås særskilt her.

Hvordan apparatet 3 virker skal nå gjennomgås. Musikkdata i internformatet i apparatet 3 inneholder bare det innhold som kan overføres til det nærmere spesifiserte eksterne lagringsmedium 7, og tilsvarende som for den andre utførelse kan derfor datamengden reduseres.

I tillegg kan brukeren også spesifisere hvilken typen lagringsmedium som senere skal oppkoples, og av denne grunn er det mulig å omvandle de aktuelle musikkdata til forenlighet med et slikt medium. Når således brukeren spesifiserer en hensiktsmessig mottaker for overføringen, vil den datamengde som skal lagres kunne holdes redusert ytterligere.

Merk at de dataprosesseringsapparater 1, 2, 3 som her er beskrevet som den første, andre henholdsvis tredje utførelse kan fremkomme ved å kombinere en datamaskin og et program som kan kjøres i denne. Oppfinnelsens apparat kan således generelt realiseres ved å registrere dette program i et opptaksmedium som typisk kan være en diskett, og programmet kan deretter brukes i et vilkårlig datamaskinsystem.

Som den fjerde utførelse, i form av et bestemt eksempel på rettsbeskyttet data slik det også er nevnt i den første til tredje utførelsesbeskrivelse, vil innholdet i et distribusjonsformat av typen SDAF videre beskrives nedenfor.

Det vises til fig. 18-39, og detaljer i dette SDAF vil først beskrives, og deretter vises til fig. 40-45 for bruken.

Innholdsdistribusjonsformatet (SDAF) i samsvar med den foreliggende utførelse av oppfinnelsen brukes til å beskrive multimediainnhold som innbefatter audio, bilde, video, tekst og fildata, og dette innhold beskrevet i forbindelse med SDAF vil heretter kalles en SDAF-tittel. Presentasjonsdata som hver omfatter SDAF-tittelen vil her kalles et innholdselement (CEL), og hvert slikt element CEL vil være tilordnet en CEL-identifikator som er unik i SDAF-tittelen (og heretter benevnt CEL ID).

SDAF-tittelen blir distribuert i splittet form, til enheter som her kalles SDAF-pakker, idet hver pakke er tilordnet en pakkeidentifikator som er unik i hele distribu-sjonssystemet. Fig. 18 viser et oversiktsskjema over et eksempel på en slik SDAF-pakke. Det vises hvordan en SDAF-tittel 2000 danner en pakkegruppe med flere SDAF-pakker 2001, hver bestående av en hodedel 2011, navigasjonsdata 2012, flere innholdselementer CEL 2013 og et tilbud 2014.

Hodedelen 2011 inneholder informasjon så som lokalitet, størrelse og attributt for hver datasekvens i pakken, og slik informasjon fastlegger pakkestrukturen. De innlagte navigasjonsdata 2012 er kontrollinformasjon for utlesing eller avspilling ("play back") og spesifiserer hvordan en spiller skal utføre avspilling av SDAF-tittelen. Fra disse navigasjonsdata 2012 gis referanse til et innholdselement CEL som er innbefattet i den pakke som disse navigasjonsdata hører til eller i andre pakker. Innholdselementet 2013 oppnås ved kryptering av hver sekvens presentasjonsdata for etablering av SDAF-tittelen og nærmere bestemt ved å kryptere de forskjellige typer data nevnt ovenfor (audio, bilder, video, tekst eller fildata). Et par dekrypteringsnøkler for dekryptering av innholdselementet 2013 og CEL ID er kalt et nøkkelpar. Tilbudet 2014 innbefatter flere slike nøkkelpar og salgsregler som beskriver salgspris og tilgjengelig periode for hvert nøkkelpar.

Fig. 19a-c viser skjemaer over tre typer SDAF-pakker. En fulle pakke 2001 er vist på fig. 19c og innbefatter, tilsvarende fig. 18, en hodedel 2011, navigasjonsdata 2012, flere innholdselementer CEL 2013 og et tilbud 2014. En tilbudspakke 2002 vist på fig. 19a innbefatter de samme elementer, men unntatt innholdselementer 2013. En inn-holdselementpakke 2003 vist på fig. 19b innbefatter hodedelen 2011 og flere innholdselementer 2013. Siden navigasjonsdata 2012 trengs for avspilling av SDAF-tittelen kan den fulle pakke 2001 og tilbudspakken 2002 avspilles alene, men CEL-pakken 2003 kan ikke det.

CEL-pakken brukes for å dele opp SDAF-tittelen i henhold til distribusjonskanalen, for eksempel når man utfører distribusjonen ved hjelp av en CD-ROM vil SDAF-tittelen registreres som en full pakke i denne plate. På den annen side, når distribusjonen skjer via Internett deles SDAF-tittelen opp i en full pakke og flere CEL-pakker for distribusjon. SDAF-tittelen er for eksempel delt opp til en full pakke som innbefatter en audio-CEL og flere CEL-pakker som innbefatter en video-CEL som refereres til fra den fulle pakke for distribusjon.

Som vist på fig. 20 kan videre SDAF-tittelen deles opp i flere SDAF-pakker ved hjelp av forskjellige spor. I den pakkeoppdeling som er vist på fig. 20 er en SDAF-tittel 2020 med audiodata for fem spor delt opp i tre pakker 2021-2023. Den første til tredje pakke 2021-2023 har her pakkenavnene Single 1, Single2 og album. Den første og den andre pakke 2021 og 2022 innbefatter begge en audio-CEL for ett spor og navigasjonsdata for å styre avspillingen av innholdselementet CEL. Den tredje pakke 2023 innbefatter en audio-CEL for tre spor og navigasjonsdata for å styre avspillingen av samtlige audio-CEL som ligger i den første til tredje pakke 2021-2023. Ved å dele SDAF-tittelen på denne måte i flere SDAF-pakker vil det være mulig å gjøre hver datasekvensstørrelse mindre slik at det blir lettere å håndtere dataprosesseringen.

Hodedelen, tilbudet, de aktuelle navigasjonsdata og innholdselementet, idet disse komponenter bygger opp SDAF-pakken vil nå gjennomgås i nevnte rekkefølge: Først skal hodedelen 2011 beskrives. Her tas en SDAF-pakke som vist på fig. 21 som et eksempel, og en hodedel 2031 hørende til en SDAF-pakke 2030 skal beskrives. I denne SDAF-pakke 2030 antas her at størrelsen av de aktuelle navigasjonsdata 2032 og tilbudet 2034 begge er på 400H i heksadesimal notasjon. Denne pakke innbefatter tre innholdselementer CEL 2033, og disse typer er regnet fra den første: audio, bilder og fildata. Det antas her at disse tre størrelser for innholdselementene regnet fra den første er 400.000H, 18.000H henholdsvis 8000H, alle i heksadesimal notasjon.

Fig. 22 viser et diagram over oppbyggingen av hodedelen 2031.1 denne hodedel vil data som beskrevet nedenfor være lagret i sekvenser, og størrelsen av hodedelen vil være BCH i heksadesimal notasjon. Merk at oppbyggingen av hodedelen 2031 kan beskrives i programmeringsspråket C++ som vist på fig. 23 og 24. Disse illustrasjoner viser en sek-vensiell kildekode oppdelt i to, og før oppdelingen, en kildekode 2062 som er vist på fig. 24 etter en kildekode 2061 som er vist på fig. 23.

Ved starten av hodedelen 2031 ligger et magisk nummer 2041 (4 B) som indikerer at filen er i SDAF-formatet. Verdien av dette magiske nummer 2041 er en tegnstreng "SDAF". Deretter lagres et versjonsnummer 2042 (4 B) for SDAF, og så lagres en pakke i det 2043 (16 B) og en pakkestørrelse 2044 (4B). Deretter lagres informasjon 2045 om stedet for plasseringen navigasjonsdata (SDAF_LOCATION_NAV på fig. 23), informasjon 2046 om tilbudsplasseringen (SDAF_LOCATION_OFFER på fig. 23) og antallet innholdselementer CEL i pakken 2047. Etter dette lagres CEL-informasjon 2048 (SDAF LOCATION CEL på fig. 2'4) for hvert innholdselement CEL, og til sist lagres en CEL-attributtabell 2049 som indikerer en attributt for hvert innholdselement.

Informasjonen 2045 for plasseringen av navigasjonsdata 2032 tilsvarer hvordan informasjonen 2046 for tilbudet indikerer lokalitet og størrelse av denne fil. Disse to informa-sjonsdeler er begge sammensatt av en forskyvningssekvens (4B) fra starten av SDAF-pakken og hver størrelse (4 B) av den.

CEL-informasjonen 2048 er bygget opp av en CEL_ID 2051 (16 B), en CEL-type 2052 (2B), en CEL-krypteringstype 2053 (2B), informasjon 2054 om CEL-dataplasseringen, og informasjon 2055 om plasseringen av en CEL-attributtabell.

En innholdselementidentifikator CEL ID 2052 er unik i SDAF-tittelen, og CEL-typen 2052 kan anta enhver verdi for audio, bilder, video, tekst eller filer. CEL-krypteringstypen 2053 indikerer en algoritme som brukes for en kryptering av CEL. CEL-datalokalitetsinformasjonen 2054 og informasjonen 2055 for attributtabellen er begge satt opp med en forskyvningssekvens (4 B) fra starten av SDAF-pakken og hver størrelse (4 B) av den. Er forskyvningen eller størrelsen lik null betyr dette at det ikke eksisterer noen data.

CEL-attributtabellen 2049 er en liste over attributter som er spesifisert for hver CEL-type. En audio-CEL-attributtabell (SDAF ATTR AUDIO på fig. 24) innbefatter minst en koder/dekoder (CODEC), antallet kvantiseringssifre angitt i bit, samplings-frekvensen og antallet audiokanaler. En tilsvarende bilde-CEL-attributtabell (SDAFAT-TR_GRAPHIC på fig. 24) omfatter minst høyde og bredde av bildet og krypteringstypen. En video-CEL-attributtabell innbefatter minst høyde og bredde av videoinformasjonen på presenterbar form og krypteringstypen. En tekstattributtabell innbefatter minst krypteringstypen for teksten, så som Unicode eller musikkforskyvnings-JIS (den japanske industristandard). En fil-CEL-attributtabell innbefatter minst typen MIME (Multipurpose Internet Message Extension).

CEL-attributtabellen 2049 er ikke definert som en tabell med fast lengde men har en merkestruktur med variabel lengde, slik det er vist på fig. 25a-c. Er en slik merkestruktur brukt lagres merkelengden og en merkeidentifikasjon før de aktuelle nyttedata, slik det er vist på fig. 25a. CEL-attributtabellen er for eksempel sammensatt av et karakteristiske merke 2063 og et krypteringsmerke 2064. Tabellelementene er spesifisert ved å bruke merkestrukturen, slik at et nytt tabellelement kan tilføyes dataformatet eller dataformater kan endres bare ved å endre et merke. CEL-attributtabellen er spesifisert ved å bruke denne merkestruktur med et stort potensial for utvidelse.

Nå skal tilbudet 2014 beskrives. Som angitt ovenfor omfatter tilbudet flere nøkkelpar og salgsregler for hvert av disse. Hvert nøkkelpar består av en dekrypteringsnøkkel for dekryptering av CEL og CEL_ID. Fig. 26 viser et skjema over sammenhengen mellom nøkkelparet og CEL. Som vist på fig. 26 er et nøkkelpar 2072 sammensatt av en dekrypteringsnøkkel 2073 og en CEL_ID 2074, og hvert slikt nøkkelpar er relatert til hver CEL 2071. Tilbudet innbefatter ikke bare nøkkelparet for det innholdselement CEL som er lagt inn i SDAF-pakken, men også samtlige nøkkélpar for de CEL som er innbefattet i SDAF-pakkene med samme SDAF-tittel. Når en SDAF-tittel er delt opp i flere SDAF-pakker vil med andre ord bare en av disse pakker innbefatte et tilbud, og dette tilbud innbefatter samtlige nøkkelpar for innholdselementene, i SDAF-tittelen.

Salgsreglene beskrives ved å bruke et språk for å angi nøkkelparets bruksbetingelser, og dette språk er kalt det riktige overordnede språk (RML). Brukerbetingelsene for nøkkelparet innbefatter datoen for salget, bruksperioden og om en SDAF-tittel eller et bestemt innholdselement CEL er solgt eller ikke. Salgsreglene spesifiseres ved å bruke disse bruksbetingelser, slik at ett og samme CEL kan selges ved forskjellige priser i avhengighet av betingelsene.

Nå skal navigasjonsdata 2012 beskrives. Disse data etableres av en innholdsskaper slik at brukeren kan bruke elementet CEL mest effektivt, ved å fastlegge den logiske struktur i SDAF-tittelen.

I SDAF brukes XML (eXtensible Markup Language), et merkebeskrivelsesspråk i et tekstformat, til å beskrive disse navigasjonsdata. Når datastrukturen er beskrevet i språket XML brukes en merkestruktur i et tekstformat, og derfor vil data som er beskrevet i XML være redundante sammenliknet med binære data. Uansett dette brukes språket XML på grunn av dets gode ekspanderbarhet.

For å referere til elementet CEL fra navigasjonsdata brukes en CEL-lokaliserer. Denne lokaliserer er i form av en kjededannelse mellom pakkeidentifikasjonen og CEL_ID med et spørsmålstegn som en avgrenser. For det CEL som er innbefattet i SDAF-pakken som innbefatter disse navigasjonsdata utelates imidlertid pakkeidentifikasjonen og avgrenseren, slik at CEL_ID blir CEL-Iokalisatoren. Denne CEL-lokalisator kan spesifisere CEL uavhengig av dette elements fysiske adresse. Fig. 28 viser et skjema over hvordan navigasjonsdata kan refereres til et innholdselement CEL ved å bruke denne CEL-lokalisator. På fig. 28 vises navigasjonsdata 2081 og presentasjonsdata 2082 som et eksempel. De siste innbefatter en audio-CEL 2083 som er kodet med MPEG2-AAC, og en bilde-CEL 2084 som er kodet med JPEG. Pakkeidentifikasjonen og CEL_ID tilhørende elementet audio-CEL 2083 er begge lik 1, mens identifikasjonen og CEL_ID for bilde-CEL 2084 er l henholdsvis 2. I dette tilfelle brukes en CEL-lokalisator "1?1" som er lagt inn i navigasjonsdata 2081 og indikerer audio-CEL 2083 med sin pakkeidentifikasjon "1" og CELID "1". En CEL-lokalisator "1?2" indikerer CEL 2084 med pakkeidentifikasjonen "1" og CEL ID "2". Ut fra dette eksempel er det bare en endring i CEL-lokalisatorens pakkeidentifikasjon som etter etableringen av SDAF-tittelen kan bevirke en endring i SDAF-pakkens tittel. Av denne grunn kan man strukturere denne tittel som en enkelt pakke eller dele den inn i flere SDAF-pakker. Fig. 29 og 30 viser skjematisk hvordan oppbyggingen av navigasjonsdata er, basert på følgende representasjonsmåte: Hvert rektangel representerer et element i disse navigasjonsdata, og en pil trukket fra et element A til et element B indikerer at det første av disse innbefatter det andre som et nedstigende element. Hvert merke eller symbol ved starten av pilene angir følgende:<*>angir at elementet innbefatter 0 eller flere nedstigende elementer, + indikerer at elementet innbefatter 1 eller flere nedstigende elementer, og ? indikerer at elementet innbefatter 0 eller 1 nedstigende element. Omfatter elementet A en gjenstand P uten noen pil betyr dette at dette element har gjenstanden P som en attributt. Understrekede gjenstander/bokstavgrupper representerer CEL-lokalisatorer. PCDATA representerer en tegnstreng satt sammen av tegn som er lagt inn i et forhåndsbestemt tegnsett, og denne representasjon spesifiserer en hierarkisk struktur med et tittelelement som rot.

Et slikt tittelelement 2101 beskriver forsendelsesinformasjon for SDAF-tittelen, og dette elementet har tre attributter: UPC, VERSJON og SPRÅK. Den første av disse tre attributter beskriver en UPC (Universal produktkode) som er den internasjonale standard for slike produktkoder. VERSJON-attributten beskriver navigasjonsstrukturens versjon-nummer, mens SPRÅK-attributten beskriver den type språk som brukes i henhold til standarden ISO 639. Standardspråket er "en" for indikasjon av engelsk. Et metadataelement 2102 beskriver informasjon så som arten for et PLAYLIST- eller TRACK-element. Dette METADATA-element har en typeattributt som beskriver hvilken type elementet har.

Et ASSOC-element 2103 beskriver referanseinformasjon for et CEL som er lagt inn i andre SDAF-titler, og dette element har en REF-attributt som beskriver CEL-lokalisatoren.

Et URL-element 2104 beskriver URL (Uniform ressurslokalisator), og dette element har to attributter: ID og TYPE. Attributten ID beskriver identifikasjonsnummeret for dette element, mens TYPE-attributten beskriver typen av URL-elementet. Et PLAYLIST-element 2105 beskriver en såkalt "playlist" som er en basisenhet for SDAF-tittelen og tilsvarer et album i konvensjonelt pakkeformat og er innbefattet i alle SDAF-titler. PLAYLIST-elementet kan innbefatte et MENY-element som gjelder som meny for denne "playlist". PLAYLIST-elementet har fem attributter: NAVN, ARTIST, PRODUCTID, THUMBNAILID og ONSTART. Navneattributten nevnt først beskriver navnet på elementet, PRODUCTID-attributten beskriver informasjon som tilsvarer en katalogkode i en kompaktplate (CD), ARTIST-attributten gjelder artister/utøvere for en innspilling eller annet, attributten TFfUMBNAILID beskriver CEL-lokalisatoren for det bilde-CEL som er typisk i elementet, og ONSTART-attributten beskriver avspillingen. Dersom ONSTART-attributten er MENY vil den som spiller av stanse avspillingen når det vises en "playlist"-meny. Er attributten TRACK vil avspilleren spille av det første sporelement som er innbefattet i elementet PLAYLIST. Samtlige PLAYLIST-elementer har minst ett sporelement 2106 (TRACK).

Dette sporelement beskriver det spor som omfatter et audio-CEL og kan innbefatte en spormeny, et "slideshow", tekst, fildata og annet. TRACK-elementet har syv attributter: ID, NAME, ARTIST, ISRC, AUDIOID, TSMID og THUMBNAILID. ID-attributten beskriver identifikasjonsnummeret som er unikt i SDAF-tittelen, den neste attributt som gjelder navnet beskriver TRACK-elementets navn, ARTIST-åttributten blir som ovenfor, ISRC-attributten beskriver en internasjonal standardisert innspillingskode, AUDIOID-attributten beskriver CEL-lokalisatoren for det audio-CEL som er relatert til TRACK-elementet, TSMID-attributten beskriver CEL-lokalisatoren for et tidssøkekart som tilsvarer audio-CEL, idet dette kart vil bli beskrevet senere og THUMBNAILID-attributten angir CEL-lokalisatoren for det bilde-CEL som er typisk i TRACK-elementet.

Et MARKER-element 2107 beskriver en markør for å finne starten i TRACK-elementet, og dette element har to attributter: tid og navn (TIME og NAME). Den første av disse beskriver lokaliteten for markøren og angis i millisekunder, mens navneattributten angir markørens navn.

Et SYNCSLIDESHOW-element 2108 beskriver et såkalt slideshow for å vise bilder eller menyer ved å følge den visningstidsinformasjon som er spesifisert i et SYNCMAP-element 2109. Elementet 2108 har tre attributter: ID, NAVN og TYPE. Den første attributt angir identifikasjonsnummeret som er unikt i SDAF-tittelen, NAVN-attributten angir navnet på dette "slideshow", mens TYPE-attributten angir informasjonskategorien i sporet så som kreditter, sangtekst, tale, undertekst, biografi, bildesamlinger eller fremming. SYNCMAP-elementet 2109 angir visningstidsinformasjonen for bildet eller menyen som er spesifisert i SYNCSLIDESHOW-elementet og har tre attributter: MENUID, PLAYID og TIME (tid). MENUID-attributten angir identifikasjonsnummeret for bildet eller menyen som skal vises, PLAYID-attributten angir indeksnummeret for å spesifisere en knapp som skal stilles til avspillingstilstand i menyen, og TID-attributten angir visningstidspunktet og -varigheten i millisekunder. Et SLIDESHOW-element 2110 angir dette "slideshow" for å vise bilder eller menyer ved forhåndsbestemte visningsintervaller, og dette element har fire attributter: ID, NAVN, TYPE og INTERVALL. Den første attributt angir identifikasjonsnummeret som er unikt i SDAF-tittelen, navneattributten angir navnet på dette "slideshow", typeattributten angir informasjonskategorien i sporet, så som kreditter, sangtekst, bunntekst, biografi, bildesamlinger eller fremming, og intervallattributten angir visningsintervallet for bildet eller menyen.

Et SYNCTEXT-element 2111 angir tekstinformasjonen som skal vises med forhåndsbestemt tidsangivelse. Tekstinformasjonen beskrives ved å bruke et SYNCTEXTBLOCK-element 2112, eller denne tekstinformasjon kan spesifiseres ved å referere til deler av tekst-CEL. SYNCTEXT-elementet har fire attributter: ID, TEXTID, REFID og TYPE. Som ovenfor gjelder ID-attributten identifikasjonsnummeret, TEXTID-attributten beskriver CEL-lokalisatoren for tekst-CEL, REFID-attributten angir identifikasjonsnummeret for et TEXTREF-element i det tekst-CEL som er spesifisert av TEXTID-attributten, og TEXTREF-elementet skal beskrives nærmere senere. TYPE-attributten blir som ovenfor.

SYNCTEXTBLOCK-elementet 2112 angir den tekstinformasjon som skal vises med en forhåndsbestemt tidsangivelse, og dette element har en tidsattributt som angir visningstidspunkt og -varighet i millisekunder. Tekstelementet 2113 angir tekstinformasjonen, idet denne er beskrevet i et tekstdataformat. Alternativt kan denne informasjon være spesifisert ved å referere til en del av tekst-CEL. Tekstelementet har samme typer attributter som SYNCTEXT-elementet. Et videoelement 2114 angir eventuelle eksisterende video-CEL. Dette element har tre attributter: ID, VIDEOID og TYPE. ID-attributten er som ovenfor, VIDEOID-attributten angir CEL-lokalisatoren for video-CEL, og TYPE-attributten er som ovenfor. Et FIL-element 2115 angir eventuelle eksisterende fil-CEL, og dette element har tre attributter: ID, FILEID og TYPE. Den første og den siste av disse er som ovenfor, mens FILEID-attributten angir CEL-lokalisatoren for fil-CEL.

Et SLIDE-element 2116 angir et bilde, og dette element har tre attributter: ID; NAME (navn) og BACKGROUNDID (bakgrunnsidentifikasjon). Den første attributt er som ovenfor, navneattributten angir bildets navn, og bakgrunnsattributten angir CEL-lokalisatoren for bilde-CEL på en bildeskjerm. Et menyelement (MENU) 2117 angir en meny som har en eller flere skjermknapper. Elementet har fire attributter: ID, NAME, BACKGROUNDID og SELECTID. De første attributter er som ovenfor, attributten for bakgrunnen angir CEL-lokalisatoren for bilde-DEL vist på en menyskjerm, og SELECTID-attributten angir indeksnummeret for å spesifisere en knapp som skal stilles i en valgt stil-ling. Et BUTTON-element 2118 beskriver skjermknappene som er anordnet på meny skjermen og omfatter, som nedadstigende elementer et eller flere par TEXTBUTTON- og COMMAND-elementer eller par med GRAPHICBUTTON- og COMMAND-elementer. BUTTON-elementet har syv attributter: INDEX, TAB, UP, DOWN, RIGHT, LEFT og AUTOACTION. INDEX-attributten beskriver indeksnummeret som er unikt i menyele-mentet, TAB-attributten beskriver det sekvensnummer som sekvensielt og sirkulativt er anordnet for hver av knappene på menyen, de neste tre attributter angir indeksnummeret for den valgte bestemmelsesknapp som blir lokalisert på oversiden, undersiden, til venstre eller til høyre i forhold til den aktuelle knapp, og AUTOACTION-attributten beskriver det flagg som indikerer om tilstanden er automatisk endret fra selektiv til aktiv.

Et TEXTBUTTON-element 2119 angir skjermknappen som er angitt ved teksten, og dette element har elleve attributter: X, Y, WIDTH, HEIGHT, FORNTSIZE,

NORMALCOLOR, SELECTCOLOR, ACTIONCOLOR, PLAYINGCOLOR, TEXTID og

REFID. Attributtene X, Y, WIDTH og HEIGHT gjelder visningsstedet for den aktuelle knapp, ut fra et koordinatsystem som starter i det øvre venstre hjørne i menyen som origo. FONTSIZE-elementet angir skrifttypestørrelsen i punkter. De fire fargeattributter gjelder visningsfargen i RBG-format når knapptilstanden henholdsvis er normal, seleksjon, aktiv og avspilling. TEXTID-attributten angir CEL-lokalisatoren for et eksternt tekst-CEL. REFID-attributten angir identifikasjonsnummeret for TEXTREF-elementet i det tekst-CEL som er spesifisert av TEXTID.

Et GRAPHICBUTTON-element 2120 angir skjermknappen som grafikk, og dette element har åtte attributter: X, Y, WIDTH, HEIGHT, NORMALID, SELECTID, ACTIONID og PLAYINGID. X, Y, bredde og høyde tilsvarer det som er beskrevet i avsnittet ovenfor, NORMALID-, SELECTID-, ACTIONID- og PLAYINGID-attributtene gjelder CEL-lokalisatoren for bilde-CEL vist når knapptilstanden er henholdsvis normal, selektiv, aktiv og for avspilling.

Et COMMAND-element 2121 angir navigasjonsoperasjonen når brukeren trykker inn en av skjermknappene, og dette element har to attributter: TYPE og TARGET. TYPE-attributten angir en av følgende kommandoer: SHOW, FUNCTION, GOTO, NEXT og PREVIOUS, idet SHOW-kommandoen brukes til å vise det element som er spesifisert av TARGET-attributten. FUNCTION-kommandoen (for funksjonen) er for å utføre det element som er spesifisert av TARGET-attributten, og denne kommando brukes når en playlistmeny blir vist. Kommandoen GOTO er for forflytting fra det element som i øyeblikket er vist og til et spesifisert annet element. NEXT-kommandoen er for å forflytte fra det element som er vist i øyeblikket og til det neste element i en rekke. PREVIOUS-elementet er tilsvarende for et tidligere element. TARGET-attributten angir parameteren for den kommando som er spesifisert av TYPE-attributten. Dersom SHOW-kommandoen er spesifisert vil TARGET-attributten beskrive identifikasjonsnummeret for det element som skal vises. Er funksjonskommandoen spesifisert beskriver TARGET-attributten identifikasjonsnummeret for det element som skal utføres. Er GOTO-kommandoen spesifisert beskriver TARGET-attributten det identifikasjonsnummer som gjelder naboelementet til det element som i øyeblikket vises.

TEXTREF-elementet beskriver tekstkategoriinformasjon for bruk ved referanse i forhold til navigasjonsdata som en del av de tekstdata som ligger lagret i tekst-CEL. De tekstdata som hører til elementet blir referert til ved spesifikasjon av identifikasjonsnummeret for dette element ut fra navigasjonsdata. TEXTREF-attributten har en ID-attributt som angir identifikasjonsnummeret som er unikt i SDAF-tittelen.

Nå skal innholdselementet CEL 2013 beskrives, og det har fire typer: audio, bilde, video, tekst og fil. I SDAF spesifiseres dataformatet og parameteren for hver type CEL. De data som er lagt inn i audio-CEL er audiodata og kodet i samsvar med standarden MPEG2-AAC (avansert audiokoding) [lavkompleksprofil]. Merk at denne standard er spesifisert i ISO/IEC 13818-7: 1997(E) informasjonsteknologi - generell koding av informasjon vedrørende bevegelige bilder og tilhørende audio - Part7 avansert audiokoding (AAC). Den sifferstrøm som er kodet i dette standardsystem antas å være i formatet ADTS (audiodatatransportstrøm). Videre er de parametere som er beskrevet i standarden ISO/IEC 13818-7 begrenset som vist på fig.31. Av disse parametre er de som er forskjellig fra SAMPLING_FREQUENCY_INDEX og CHANNEL_CONFIGURATION vist øverst til venstre i skjemaet på fig. 31 begrenset ved valget av LC-profil slik det er spesifisert i denne standard. Videre er den gjennomsnittlige overføringshastighet i sifre per sekund (bitraten) enten 64 eller 128 kb/s. Data i bilde-CEL er bildedata som er kodet i samsvar med standarden JPEG, MPEG-I-rammen eller PNG (portabel nettgrafikk). Fig. 32-34 viser tabeller over spesifikasjonene for disse tre standarder. Spesifikasjonene for krypteringsalgoritmene for bilde-CEL er begrenset som vist der. Data innbefattet i videb-CEL er videodata som er kodet i samsvar med standarden MPEG-2. Fig. 35 viser en oversikt over denne spesifikasjon, idet den for krypteringsalgoritmen for video-CEL er begrenset slik det er vist på tegningen. Data som hører til tekst-CEL er enten PLAIN-tekst eller XML-tekst i SDAF. Krypteringstypen er enten Unicode eller music shift JIS.

Som et eksempel på denne fil-CEL skal nå gjennomgås et tidssøkekart CEL som innbefatter et tidssøkekart som data. Dette kart danner en tabell som er sammensatt med adresser for en audioramme. Fig. 36 viser et diagram over oppbyggingen av kartet, og det fremgår at dette kart 2090 består av en hodedel 2091 og flere innganger 2092. Fig. 37, 38a og 38b viser en tabell og diagrammer over denne hodedel 2091 i detalj, og som vist omfatter den avspillingstid mellom inngangene, angitt i millisekunder, og det totale antall innganger. Fig. 39 viser en tabell over hver inngang i detalj. Som vist på fig. 39 omfatter hver inngang adressen for audiorammen ved inngangspunktet. Den første inngang indikerer startposisjonen for audiorammen i den angitte audio-CEL.

Merk at MPEG2-AAC i den foreliggende oppfinnelse brukes for å komprimere musikkdata som er lagt inn i audio-CEL, men alternativt kan man også bruke andre formater eller standarder så som MP3 (MPEG1 Audio Layer 3), Dolby-AC3 eller DTS (Digital Theater System).

Nå skal det vises til fig. 40-45 og gjennomgås hvordan bruken av SDAF er. Som forklart ovenfor er SDAF et format for å beskrive innholdet i multimedia og brukes hovedsakelig for distribusjon av musikk på digital form. SDAF kan brukes til forskjellige typer innspillingsmedia, typisk masselagre av typen hard disk, optiske plater så som DVD-RAM og halvlederlagertyper som kan være utformet som lagerkretskort.

I tillegg til distribusjon av musikk (musikkdata) kan SDAF brukes i kombinasjon med allerede eksisterende musikkdata, for eksempel vil SDAF kunne brukes i kombinasjon med musikkdata som er i samsvar med standardene for DVD-audio, slik det skal gjennomgås nedenfor. Tilsvarende kan SDAF brukes for andre innspillingsmedia, så som DVD-video, CD, video-CD og foto-CD.

Musikkdata som samsvarer med standardene DVD-audio innbefatter LPCM (lineær pulskodemodulasjon) når det gjelder audioinnholdet og MPEG-I for rammebildeinnholdet. En spiller som arbeider i samsvar med standardene DVD-audio vil vise en menyskjerm for en brukers interaktive betjening. I DVD-audio-standardene vil en slik menyskjerm vises ved overlagring av et maksimalt antall på fire subvideobilder på en bakgrunn som utgjør et bakgrunnsbilde, slik at man kan få flere rektangulære områder på bakgrunnen. Slike områder kalles gjerne knapper, og hver knapp er tildelt en bestemt kommando. Enkelte restriksjoner har man imidlertid overfor antallet visningsfarger og formen av knappene, og derfor vil en innholdsskaper ikke fritt kunne sette opp alle typer menyskj ermer.

Dette problem kan løses ved tidligere innregistrerte data på menyskjermen og beskrevet i SDAF i en konvensjonell DVD-audio-plate, hvor man viser menyskjermen ved hjelp av disse data ved avspillingen. Nærmere bestemt: multimediainnholdet som er beskrevet i SDAF og en CEL-omdirigerer for referanse fra SDAF til det opprinnelige DVD-audio-innhold. Heretter vil en DVD-audio-plate med slike innregistrerte data kalles en utvidet DVD-audio-plate, og en spiller for avspilling av en slik plate vil kalles en spiller som er SDAF-forenlig.

Fig. 40 viser et skjema for et eksempel på disse CEL-omdirigererne som tilsvarer en enkelt DVD-audio-plate. Hver rekke indikerer CEL-omdirigereren for hver innhold innbefattet i den opprinnelige DVD-audio-plate, og de omfatter en CELJGD 2201, et filnavn 2202, en startadresse 2203 og en sluttadresse 2204. Identifikasjonen CEL ID 2201 er en innholdsidentifikator som er unik i platen. Filnavnet 2202 er navnet på den fil som innbefatter hvert innhold. Start- og sluttadressen 2203 og 2204 er forskyvningsverdier som indikerer start- og endeposisjonen, i forhold til hvert innhold i filen. CEL-omdirigereren er registrert inn i en fil som er kalt DVDA.MAP for eksempel i et SDAF-register som er lagt inn i et leselager i den utvidede plate.

Samtlige forskjellige avspillingskontrollfunksjoner så som rekkefølgeregulering, avspilling av "slideshow" og en menyfunksjon som er fastlagt av DVD-audio-standardene, kan her beskrives ved hjelp av disse SDAF-navigasjonsdata, for eksempel kan menyfunksjonen realiseres ved å overlagre JPEG-knappbilder med et vilkårlig antall farger og fasonger til et MPEG-I rammebakgrunnsbilde for visning og med relasjon av hvert knappområde til en kommando.

Når avspillingsstyreinformasjonen som er lagt inn i platen omvandles til SDAF-navigasjonsdata vil den informasjon som indikerer innholdet bli omvandlet til CEL_ID ved å bruke CEL-omdirigereren. Menyskjermen omvandles til JPEG-knappbilder, og de fremkomne bilder blir arrangert på steder slik at de overlagres på bagrunnsbildet. Navigasjonsdata og knappbilder slik det fremkommer som angitt i beskrivelsen ovenfor blir lagret i en enkelt SDAF-pakke og registreres inn i en fil som for eksempel kan kalles SDAF.SDP og ligger i et SDAF-register i leseområdet i lageret i den utvidede plate. Fremgangsmåten for avspilling av en slik utvidet plate skal gjennomgås senere.

Deretter skal en SDAF-spiller for avspilling av multimediainnhold beskrevet i forbindelse med SDAF gjennomgås. SDAF-spilleren spiller av distribuerte musikkdata på følgende måte: Først søker spilleren etter pakkeidentifikasjoner og navigasjonsinformasjon for å oppsamle de enkelte CEL_ID for de CEL som trengs for avspillingen, og spilleren søker videre i en salgsdatabase ved å bruke sett av disse oppsamlede identifikasjoner og CEL_ID for å fastlegge om hvert CEL er solgt eller ikke. Finnes et CEL som ennå ikke er solgt vil spilleren analysere det innkodede tilbud og sørge for at betaling av en forhåndsbestemt pris blir utført via det eksisterende elektroniske distribusjonssystem. Etter salget vil nøkkelparet som ligger lagret i tilbudet lagres i salgsdatabasen. Finnes at SDAF-pakkens som trengs for avspillingen ikke er i spilleren vil denne sende ut pakkeidentifikasjonen til datadistribusjonsapparatet, og dette vil på sin side fordele ut en SDAF-pakke med den mottatte pakkeidentifikasjon, til spilleren. Etter at samtlige CEL som trengs for avspillingen er solgt vil spilleren dekryptere disse CEL ved bruk av det nøkkelpar eller de nøkkelpar som ligger lagret i salgsdatabasen for avspillingen. Ved dette tidspunkt tolker spilleren navigasjonsdata for avspillingskontroll og -styring.

SDAF-tittelen vil distribueres til spilleren som oppdelt en eller flere SDAF-pakker.

Fig. 41a til 41c viser skjemaer på eksempler for hvordan SDAF-pakkene blir distribuert. I en distribusjonsmåte så som den som er vist på fig. 41a vil en pakke 2301 innbefatte bare et audioinnhold, mens en pakke 2302 vil innbefatte bare et innhold for et bilde eller videografikk. Videre er det slik at man fra pakken 2302 far referert audioinnholdet i pakken 2301, og av denne grunn vil den bruker som bare kjøpte pakken 2301 bare kunne spille dette audioinnhold. En bruker som kjøpte pakken 2302 i tillegg til pakken 2301 kan derimot spille av grafikkinnholdet sammen med audioinnholdet. På denne måte kan SDAF-tittelen spesifiseres ved å tilføye et CEL til det eksisterende spor.

I en distribusjonsmåte som vist på fig. 41b omfatter en pakke 2303 flere audioinn-holdsgrupper og grafikkinnholdsgrupper. Således kan en enkelt pakke innbefatte samtlige av de CEL som er lagt inn i en SDAF-tittel. I en distribusjonsmåte som vist på fig. 41c er en enkelt SDAF-tittel delt opp i pakker 2304-2306 for distribusjon. Den mellomste av disse omfatter innholdet for spor nr. 1, mens den siste pakke 2306 innbefatter et innhold for spor nr. 2.1 denne distribusjonsmåte er det mulig å velge den ene eller andre av disse to pakker 2305 og 2306 for distribusjon.

Videre kan det etableres en ny SDAF-pakke som inneholder et innhold som er eid av brukeren, i spilleren. Fig. 42a-42c viser skjemaer på eksempler på hvordan man skal lage slikt SDAF-pakker. En brukerpakke er således en SDAF-pakke som er etablert av brukeren, mens en solgt pakke er en distribuert SDAF-pakke. Innholdet som omsluttes av en tykk strek på tegningen er det innhold som er eid av brukeren. Det antas her at brukeren eier data som kan leses ut fra en CD, dvs. et audioinnhold som er tatt ut fra denne CD, og et grafisk innhold som er etablert av brukeren selv.

Som vist på fig. 42a kan brukeren lage en pakke 2401 som innbefatter det audioinnhold som er eid av vedkommende selv. Slik det er vist på fig. 42b kan videre brukeren etablere en pakke 2402 som inneholder vedkommendes eget audio- og grafikkinnhold. Videre og som vist på fig. 42c kan også brukeren etablere en pakke 2404 som det audioinnhold som er innbefattet i den solgte pakke 2403 er referert til. Hvis pakken 2404 avspilles vil audioinnholdet som er innbefattet i den solte pakken og grafikkinnholdet som eies av brukeren selv avspilles. Av denne grunn vil det bilde som er lagt inn i den solgte pakke kunne endres til det bilde som er etablert av brukeren, eller et nytt bilde som er etablert av brukeren kan tilføyes til den solgte pakke.

Nå skal en SDAF-forenlig DVD-audio-spiller for avspilling av utvidede DVD-audio-plater beskrives. Spilleren styrer avspillingen ved å følge de navigasjonsdata som er beskrevet med SDAF i stedet for den opprinnelige avspillingsstyreinformasjon som er forenlig med standardene for DVD-audio. Spilleren leser disse navigasjonsdata og CEL-lokalisatoren fra platen og arbeider ved å følge de leste navigasjonsdata. Hvis det er referert til det opprinnelige audioinnhold eller bildeinnhold, fra disse navigasjonsdata vil spilleren referere til CEL-lokalisatoren for å oppnå informasjon om det sted hvor innholdet ligger lagret, hvoretter innholdet avspilles. Spilleren leser bakgrunnsbildet fra DVD-audioområdet på platen og knappbildene fra SDAF-data og kombinerer disse for å vise menyskjermen. På denne måte kan DVD-audiospilleren ved hjelp av den utvidede DVD-audioplate utføre konvensjonell avspilling, mens den SDAF-forenlige DVD-audiospiller kan vise menyskjermen ved å bruke disse navigasjonsdata som er beskrevet med SDAF.

I beskrivelsen ovenfor lagres SDAF-pakken og CEL-omdirigereren i platen, men alternativt kan slike data også lastes ned via et kommunikasjonsnett for å komme spilleren i hende. Denne metode kan brukes for både CD- og DVD-media som allerede er solgt til brukeren, og med denne metode kan også CEL som er tilgjengelige via et kommunikasjonsnett refereres til ved å bruke URL.

Nå skal et dataomvandlingsapparat for kopiering av multimediainnhold spesifisert i SDAF beskrives, idet dette apparat kopierer over til et eksternt lagringsmedium for bærbare musikkspillere. Her er spilleren bygget opp ved hjelp av blant annet et halvlederlager som et eksternt lagringsmedium og er kjennetegnet ved liten størrelse, lav vekt og evnen til å kunne lese inn data ved stor hastighet. En slik bærbar spiller innbefatter, slik det er vist på ig. 43, et flytekrystallvindu 2501 som kan vise tekst, et styrepanel 2502 for å styre og regulere audioavspilling og en høyttaler eller en hodetelefon 2503 for audioutgang. Videre kan et lagerkort 2500 for lagring av audiodata være løsbart tilkoplet spilleren. Den kan avspille audioinnhold som er i samsvar med MPEG2-AAC og også vise tekstinformasjon, men dataregistreringsformatet i lagerkortet er ikke SDAF, men et unikt format.

Fig. 44 viser et blokkskjema over hvordan et slikt dataomvandlingsapparat er bygget opp, for omvandling av innhold som ligger innspilt i en utvidet DVD-audioplate, til et gitt format, og innlesing av det omvandlede innhold i et lagerkort for bærbare musikkspillere. På fig. 44 fremgår at man har et audioinnhold i LPCM-format, et bildeinnhold i MPEG-I-format, en avspillingsstyreinformasjon som er beskrevet i SDAF samt ytterligere tekstinformasjon innspilt på en plate 2601. I apparatet vist på fig. 44 leser en dataleser 2602 avspillingsinformasjonen fra platen 2601 og gir samme informasjon videre til en analysator 2603 som sørger for å analysere informasjonen og finne om innholdet som er innspilt på platen 2601 kan avspilles eller trenger omvandling.

Dataleseren 2602 leser sekvensielt fra platen 2601, nemlig det innhold som kan avspilles av den bærbare spiller og overfører et leste innhold til en dataomvandler 2605, og ved dette tidspunkt vil innhold som ikke kan avspilles av spilleren ikke overføres. Omvandleren 2605 omvandler det leste innhold i samsvar med en bestemt type lagerkort 2500, for eksempel vil tekstinformasjon som kan være direkte avspilt av spilleren så som titler ikke omvandles. På den annen side vil audioinnhold i LPCM-format omvandles til MPEG2-AAC-format, slik at spilleren kan avspille innholdet. Omvandlerenheten 2604 for avspilling frembringer avspillingsinformasjon for spilleren basert på den analyserte informasjon, og en datainnleser 2606 leser denne avspillingsinformasjon som er frembrakt av enheten 2604 og det innhold som er omvandlet av enheten 2605, inn i lagerkortet 2500.

Merk at den dataomvandlingsenhet som er vist på fig. 44 kan omvandle et vilkårlig innhold som ikke behøver å være audioinnhold, til et gitt format og lese dette omvandlede innhold inn i lagerkortet 2500, og videre kan dataregistreringsformatet i dette kort være et vilkårlig format som ikke behøver være SDAF. Videre vil omvandleren kunne omfatte en dataomvandler som kan håndtere forskjellige typer lagringsmedia, og derved kan også avspillingsomvandleren og datainnleseren være inkludert, beregnet for hvert eksterne lagringsmedium.

Videre kan det være slik at dersom man ikke har noen navigasjonsdata som er beskrevet med SDAF som innregistrert i platen 2601, slik det er vist på fig. 45, kan man få manglende data via et kommunikasjonsnett. På fig. 45 antas at det registreres inn et identifikasjonsnummer i platen 2601, for eksempel kan dette nummer for en musikk-CD være en katalogkode, en ISRC-kode og annet.

Dataleseren 2602 leser identifikasjonsnurrimeret for platen og tilveiebringer det samme nummer til en kommunikasjonsenhet 2607 som står i forbindelse med en inn-holdsinformasjonsserver 2611 via et kommunikasjonsnett 2610. Enheten 2607 kan komme til serveren 2611 via Internett eller få direktetilgang til den via en telefonkrets. Serveren 2611 lagrer de manglende data i forhold til identifikasjonsnummeret, og i respons på en forespørsel fra et dataomvandlingsapparat vil disse manglende data oversendes til dette apparat. Etter mottakingen av de manglende data utfører apparatet de samme arbeidstrinn som apparatet vist på fig. 44.

Som angitt ovenfor er innholdsdistribusjonsformatet SDAF i samsvar med oppfinnelsen et format for å beskrive multimediainnhold og brukes hovedsakelig for distribusjon av musikk på digital form (musikkdata). Ved å bruke SDAF i kombinasjon med allerede eksisterende slike musikkdata vil man kunne utvide deres funksjon.

Merk at man fra sammenlikningen mellom fig. 3 og 18 finner sammenhengen eller korrelasjonen mellom de musikkdata som er beskrevet i den første til tredje utførelse og det sikrede audioformat SDAF ifølge oppfinnelsen finnes følgende måte: Hodedelen 40 vist på fig. 3 tilsvarer således hodedelen 2011 vist på fig. 18, navigasjonsinformasjonen 41 tilsvarer navigasjonsdata angitt med 2012 på fig. 18, innholdet 42 tilsvarer CEL 2013 på fig. 18, og belastningsinformasjonen 43 på fig. 3 tilsvarer tilbudet 2014 på fig. 18.

Oppfinnelsen er nå beskrevet i nærmere detaljer, men denne beskrivelse er bare illustrativ og ikke begrensende. Det er klart at en rekke andre varianter og modifikasjoner kan tenkes uten at dette fraviker rammen om patentkravene.

Som beskrevet i det foregående omvandler apparatene ifølge oppfinnelsen rettsbeskyttede data til data i et internformat og uten faktureringsinformasjon, for lagring. Av denne grunn kan forskjellige prosesser utføres ved hjelp av en enhetlig prosedyre for de aktuelle data, under håndtering av beskyttelsen slik at denne ivaretas, uavhengig av hvilken måte det faktureres og betales på.

Claims

1. Apparat (1, 2, 3) for prosessering av data og innrettet for å utføre slik prosessering av rettsbeskyttede data innenfor en ervervet rettighet,karakterisert vedat et lager (11) for å oppta data i et egnet distribusjonsformat og som omfatter minst et innhold (42) for beskyttelse og belastningsinformasjon (43) som bestemmer hvordan en betalingsbelastning skal foregå for innholdet (42), salgselementer (12, 13) for prosessering av betaling basert på belastningsinformasjonen (43) og komme frem til en salgsstatus (52) som trengs for prosesseringen av innholdet (42), et rettsregister (16) for å lagre denne salgsstatus (52) fremkommet fra salgselementene (12,13), dataomvandlere (14, 22) for omvandling av de distribusjonsformaterte data som inneholder innholdet (42), til internformaterte data uten belastningsinformasjonen (43) når salgsstatus (52) er etablert for innholdet (42), et internlager (15) for lagring av disse internformaterte data fra omvandlerne (14, 22), og prosessutførelseselementer (17, 18, 19) for å utføre prosesseringen av de internformaterte data som ligger lagret i internlageret (15), med den salgsstatus (52) som ligger lagret i rettsregisteret (16).

2. Apparat ifølge krav 1,karakterisert vedat: de data som representerer innholdet (42) foreligger i kryptert form, at belastningsinformasjonen (43) innbefatter en dekrypteirngsnøkkel (54) for dekryptering av innholdet (42), at dataomvandlerne (14, 22) tar ut denne nøkkel fra belastningsinformasjonen (43), at nøkkelen (54) lagres i rettsregisteret (16), og at prosessutførelseselementene (17, 18, 19) utfører dekryptering av det krypterte innhold (42) ved hjelp av nøkkelen (54) i rettsregisteret (16).

3. Apparat ifølge krav 1,karakterisert vedat: de distribusjonsformaterte data inneholder data som representerer innholdet (42), belastningsinformasjonen (43), en hodedel (40) og navigasjonsinformasjon (41) for å kontrollere og styre prosessutførelsen for prosesseringen av innholdet (42).

4. Apparat ifølge krav 1,karakterisert vedat: de internformaterte data helt tilsvarer de data som er fremkommet ved å skille belastningsinformasjonen (43) fra de distribusjonsformaterte data.

5. Apparat ifølge krav 1,karakterisert vedat: prosessutførelseselementene (17, 18, 19) inneholder en overføringsenhet (19) som kan kopiere over de internformaterte data som ligger lagret i internlageret (15), til et uttakbart eksternt lagringsmedium (7), idet dataomvandleren (22) omvandler de distribusjonsformaterte data til internformaterte data, basert på en bestemt type av det eksterne lagringsmedium (7).

6. Apparat ifølge krav 5,karakterisert vedvidere å omfatte: en medieindikator (23) for å registrere hvilken type eksternt lagringsmedium (7) det gjelder, ved hjelp av et indikasjonssignal (35), slik at dataomvandleren (22) kan utføre formateringsomvandlingen ut fra den indikerte type lagringsmedium, indikert av medieindikatoren (23) ved hjelp av indikasjonssignalene (35).

7. Apparat ifølge krav 5,karakterisert vedvidere å omfatte: en mediespesifikator (24) for å spesifisere hvilken type eksternt lagringsmedium (7) det gjelder, ved hjelp av et spesifikasjonssignal (36), slik at dataomvandleren (22) kan utføre formateringsomvandlingen ut fra den indikerte type lagringsmedium, spesifisert av mediespesifikatoren (24).

8. Apparat ifølge krav 5,karakterisert vedat: de distribusjonsformaterte data inneholder et eller flere elementer i form av innholdet (42), mens de internformaterte data bare inneholder innhold som skal kopieres til lagringsmediet (7), blant disse elementer i innholdet (42).

9. Fremgangsmåte for prosessering av data og innrettet for å utføre prosessering av rettsbeskyttede data innenfor en ervervet rettighet,karakterisert ved: lagring av et egnet distribusjonsformat og som omfatter minst et innhold (42) for beskyttelse og belastningsinformasjon (43) som bestemmer hvordan en betalingsbelastning skal foregå for innholdet (42), prosessering av betaling basert på belastningsinformasjonen (43) og komme frem til en salgsstatus (52) som trengs for prosesseringen av innholdet (42), lagring av denne salgsstatus (52) fremkommet fra salgselementene (12, 13) ved prosesseringen ovenfor, omvandling av de distribusjonsformaterte data som inneholder innholdet (42), til internformaterte data uten belastningsinformasjonen (43) når salgsstatus (52) er etablert for innholdet (42), lagring av disse internformaterte data fra omvandlerne (14, 22) ved omvandlingen ovenfor, og å utføre prosesseringen av de internformaterte data som ligger lagret i internlageret (15), med den salgsstatus (52) som ligger lagret i rettsregisteret (16) ved lagringen ovenfor.

10. Opptaksmedium med et innregistrert program for kjøring på en datamaskin slik at man med denne utfører en fremgangsmåte for prosessering av data og innrettet for å utføre prosessering av rettsbeskyttede data innenfor en ervervet rettighet,karakterisertved: lagring av et egnet distribusjonsformat og som omfatter minst et innhold (42) for beskyttelse og belastningsinformasjon (43) som bestemmer hvordan en betalingsbelastning skal foregå for innholdet (42), prosessering av betaling basert på belastningsinformasjonen (43) og komme frem til en salgsstatus (52) som trengs for prosesseringen av innholdet (42), lagring av denne salgsstatus (52) fremkommet fra salgselementene (12, 13) ved prosesseringen ovenfor, omvandling av de distribusjonsformaterte data som inneholder innholdet (42), til internformaterte data uten belastningsinformasjonen (43) når salgsstatus (52) er etablert for innholdet (42), lagring av disse internformaterte data fra omvandlerne (14, 22) ved omvandlingen ovenfor, og utførelse av ' prosesseringen av de internformaterte data som ligger lagret i internlageret (15), med den salgsstatus (52) som ligger lagret i rettsregisteret (16) ved lagringen ovenfor.