NO330422B1

NO330422B1 - Kryptering for digital rettighetsforvaltning, samt databeskyttelse av innhold pa en anordning uten interaktiv autentisering

Info

Publication number: NO330422B1
Application number: NO20031645A
Authority: NO
Inventors: Marcus Peinado; M Jay Parks; Jonas Fredrik Helin; Clifford P Strom
Original assignee: Microsoft Corp
Priority date: 2002-04-16
Filing date: 2003-04-10
Publication date: 2011-04-11
Also published as: EP1357455A2; EP1357455A3; JP4615832B2; US7395438B2; NO20031645L; US20030195855A1; EP1357455B1; JP2004040772A; NO20031645D0

Description

Denne søknaden er relatert til U.S.-patentsøknaden 09/290,363, innlevert 12. april 1999 med tittelen "ENFORCEMENT ARCHITECTURE AND METHOD FOR DIGITAL RIGHTS MANAGEMENT", og U.S. provisional søknad 60/126,614, innlevert 27. mars 1999 med tittelen "ENFORCEMENT ARCHITECTURE AND METHOD FOR DIGITAL RIGHTS MANAGEMENT", som begge med dette inntas her som referanse i sin helhet.

Foreliggende oppfinnelse angår en arkitektur for å håndheve rettigheter i digitalt innhold. Mer spesifikt angår foreliggende oppfinnelse en slik arkitektur som tillater tilgang til kryptert digitalt innhold bare i overensstemmelse med parametere som spesifiseres av lisensrettigheter som er ervervet av en bruker av det digitale innholdet. Enda mer spesifikt angår foreliggende oppfinnelse en arkitektur for en relativt liten og/eller enkel anordning med begrensede dekrypterings-og kommunikasjonsmuligheter.

Forvaltning og håndheving av digitale rettigheter er sterkt ønskelig i forbindelse med digitalt innhold så som digital lyd, digitale bilder eller video, digital tekst, digitale data, digitale multimedier, etc, der slikt digitalt innhold skal distribueres til brukere. Typiske distribusjonsmåter omfatter konkrete anordninger så som en magnetisk (floppy) disk, et magnetbånd, en optisk (kompakt) disk (CD), etc, samt ikke-konkrete medier så som en elektronisk oppslagstavle, et elektronisk nettverk, Internett, etc. Når det mottas av brukeren, rendrer eller "avspiller" denne brukeren det digitale innholdet ved hjelp av en dertil egnet rendringsanordning så som en media-avspiller på en personlig datamaskin eller liknende.

En innholdseier eller rettighetshaver, så som en forfatter, en forlegger, en kringkaster, etc. (nedenfor betegnet "innholdseier"), ønsker typisk å distribuere slikt digitalt innhold til en bruker eller mottaker mot en lisensavgift eller en annen godtgjørelse. Denne innholdseieren, gitt valget, vil sannsynligvis ønske å begrense hva brukeren skal kunne gjøre med slikt distribuert digitalt innhold. For eksempel kan innholdseieren ønske å hindre brukeren i å kopiere og redistribuere dette innholdet til en andre bruker, i hvert fall på en måte som gjør at innholdseieren ikke mottar en lisensavgift fra denne andre brukeren.

I tillegg kan innholdseieren ønske å gi brukeren fleksibilitet til å kjøpe forskjellige typer brukerlisenser mot forskjellig lisensavgift, samtidig som brukeren holdes til de betingelsene som gjelder for den typen lisens som faktisk er kjøpt. For eksempel kan innholdseieren ønske å tillate distribuert digitalt innhold å bli spilt av kun et begrenset antall ganger, kun for en gitt total tid, bare på en viss type maskin, bare på en viss type mediaspiller, bare av en viss type bruker, etc.

Etter at distribusjonen har funnet sted, har imidlertid en slik innholdseier

veldig liten, om noen, kontroll over det digitale innholdet. Dette er spesielt proble-matisk i lys av det faktum at praktisk talt enhver ny eller nyere personlig datamaskin omfatter den programvaren og maskinvaren som er nødvendig for å lage en eksakt digital kopi av slikt digitalt innhold og for å laste ned en slik eksakt digital kopi til en skrivbar magnetisk eller optisk disk, eller for å sende en slik eksakt digital kopi over et nettverk så som Internett til en hvilken som helst destinasjon.

Selvfølgelig, som del av den legitime transaksjonen der lisensavgiften ble oppnådd, kan innholdseieren kreve at brukeren av det digitale innholdet lover å ikke redistribuere det digitale innholdet. Et slikt løfte er imidlertid lett å gi og lett å bryte. En innholdseier kan forsøke å hindre slik redistribusjon ved hjelp av en hvilken som helst blant flere kjente sikkerhetsanordninger, vanligvis omfattende kryptering og dekryptering. Det er imidlertid sannsynligvis veldig lite som hindrer en mildt stemt bruker i å dekryptere kryptert digitalt innhold, lagre dette digitale innholdet i en ukryptert form og deretter redistribuere det.

US 5,715,403 angår et system for styring av distribusjon og bruk av digitale arbeider som har tilknyttet bruksrettigheter hvor bruksrettighetene er definert av en bruksrettighetsgrammatikk.

Det eksisterer derfor et behov for å tilveiebringe en gjennomtving ningsarki-tektur og -fremgangsmåte som muliggjør kontrollert gjengivelse eller avspilling av vilkårlige former for digitalt innhold, der denne kontrollen er fleksibel og kan defineres av eieren av det digitale innholdet. Det eksisterer også et behov for å tilveiebringe et kontrollert rendringsmiljø på en beregningsanordning så som en personlig datamaskin, der rendringsmiljøet omfatter i hvert fall en andel av en slik gjennomtvingningsarkitektur. Et slikt kontrollert rendringsmiljø gjør det mulig å påse at det digitale innholdet kun vil bli gjengitt som spesifisert av innholdseie ren, selv om det digitale innholdet skal gjengis på en beregningsanordning som ikke er under kontroll av innholdseieren.

Videre eksisterer det et behov for en pålitelig eller klarert komponent som kjører på beregningsanordningen, der den pålitelige komponenten påtvinger rettighetene til innholdseieren på denne beregningsanordningen i forbindelse med digitalt innhold, også mot forsøk fra brukeren av beregningsanordningen på å aksessere det digitale innholdet på måter som ikke tillates av innholdseieren. Kun som ett eksempel hindrer en slik pålitelig programvarekomponent en bruker av beregningsanordningen i å lage en kopi av det digitale innholdet, bortsett fra som ellers tillatt av innholdseieren.

Endelig eksisterer det et behov for en fremgangsmåte og en mekanisme som gjør det mulig å utvide den digitale rettighetsforvaltningsarkitekturen til en relativt liten og/eller enkel anordning. Mer spesifikt eksisterer det et behov for en versjon av en digital rettighetsforvaltningsarkitektur som muliggjør kryptering og databeskyttelse av innhold i den relativt lille anordningen, selv om den anordningen på hvilken innholdet skal gjengis er relativt liten og/eller enkel og ikke innehar relativt komplekse muligheter så som det å utføre asymmetrisk nøkkel dekryptering og kommunisere med en fjern-entitet over en nettverksforbindelse eller liknende. Mer spesifikt eksisterer det et behov for en mekanisme og fremgangsmåte som utvider DRM-arkitekturen til en slik relativt liten og/eller enkel anordning, der anordningen ikke trenger å utføre asymmetrisk nøkkel dekryptering og ikke krever web- eller nettverkstilkopling.

I et første aspekt tilveiebringer oppfinnelsen en fremgangsmåte som utføres i kombinasjon med en vertsdatamaskin og en anordning som har en anordningsnøkkel (DK) med en forvalgt indeksverdi, der anordningen er for å motta et lagringsmedium eller omfatter lagringsmediet, idet lagringsmediet har lagret deri digitalt innhold som er beskyttet i henhold til en hemmelighet og en tabell som inneholder flere elementer, og hvert element omfatter hemmeligheten kryptert med en nøkkel som kan dekrypteres med anordningsnøkkelen (DK) for én av flere mulige anordninger og en indeksverdi, idet fremgangsmåten er for at anordningen skal gjengi innholdet i mediet og omfatter de trinn å: motta en forespørsel om å gjengi innholdet i mediet; oppnå tabellen fra mediet; oppnå anordningsnøkkelen (DK) for anordningen og indeksverdien til denne (DK); indeksere inn i et element i tabellen basert på den oppnådde indeksverdien; velge den krypterte hemmeligheten fra det indekserte elementet; anvende den oppnådde anordningsnøkkelen (DK) på den valgte krypterte hemmeligheten for å eksponere hemmeligheten; og anvende den eksponerte hemmeligheten for å gjengi det motsvarende innholdet.

Foretrukkede utførelsesformer av fremgangsmåten er angitt i de uselvstendige kravene 2-11.

I et andre aspekt tilveiebringer oppfinnelsen en fremgangsmåte som utføres i kombinasjon med en vertsdatamaskin og flere anordninger som hver har en anordningsnøkkel (DK) med en forhåndsvalgt indeksverdi, der hver anordning er for å motta et lagringsmedium eller omfatter lagringsmediet, idet lagringmediet omfatter en identifikator for dette deri og har lagret deri digitalt innhold som er beskyttet med en hemmelighet samt en tabell som inneholder flere elementer, der hvert element omfatter hemmeligheten kryptert med en nøkkel som kan dekrypteres med anordningsnøkkelen (DK) for én blant flere mulige anordninger og en indeksverdi, idet fremgangsmåten er for at vertsdatamaskinen skal forsyne mediet med tabellen, og omfatter de trinn å: oppnå tabellen fra et hurtigbuffer; oppnå identifikatoren for mediet fra dette; legge til den oppnådde identifikatoren for mediet i den oppnådde tabellen; anvende en anordningsnøkkel (DK) og indeksverdien for denne for å finne det motsvarende elementet i den oppnådde tabellen og avdekke hemmeligheten i denne tabellen; binde tabellen til mediet med identifikatoren for mediet og den eksponerte hemmeligheten; og kopiere den tilknyttede tabellen til mediet.

Foretrukkede utførelsesformer av fremgangsmåten er angitt i de uselvstendige kravene 13-21.

I et tredje aspekt tilveiebringer oppfinnelsen en fremgangsmåte som utføres i kombinasjon med en vertsdatamaskin og et lagringsmedium som omfatter en identifikator for dette deri og som har lagret deri en tabell som inneholder flere elementer, der hvert element omfatter en hemmelighet som er kryptert i henhold til en nøkkel som kan dekrypteres av en anordningsnøkkel (DK) for én blant flere mulige anordninger og en indeksverdi, idet minst én av hemmelighetene er en gjeldende hemmelighet for tabellen, idet fremgangsmåten er for å lagre digitalt innhold i mediet i henhold til den gjeldende hemmeligheten for tabellen og omfatter det å: oppnå identifikatoren fra mediet; oppnå den gjeldende hemmeligheten fra tabellen; anvende den oppnådde, gjeldende hemmeligheten og den oppnådde identifikatoren i en forbestemt funksjon for å generere en endelig hemmelighet; beskytte innholdet som skal lagres i mediet i henhold til den endelige hemmeligheten, og med det binde innholdet til mediet ved identifikatoren for dette; og kopiere det beskyttede innholdet til mediet.

Foretrukkede utførelsesformer av fremgangsmåten er angitt i de uselvstendige kravene 23-25.

De ovennevnte behov fylles i hvert fall delvis av en gjennomtvingningsarkitektur og -fremgangsmåte for forvaltning av digitale rettigheter, der arkitekturen og fremgangsmåten gjennomtvinger rettigheter i beskyttet (sikkert) digitalt innhold som er tilgjengelig på et medium så som Internett, en optisk disk, etc. For det formål å gjøre innhold tilgjengelig, omfatter arkitekturen en innholdstjener fra hvilken det digitale innholdet er tilgjengelig over Internett eller tilsvarende i en kryptert form. Innholdstjeneren kan også levere det krypterte digitale innholdet for opptak på en optisk disk eller liknende, idet det krypterte digitale innholdet kan bli distribuert via den optiske disken. Ved innholdstjeneren blir det digitale innholdet kryptert under anvendelse av en krypteringsnøkkel, og fellesnøkkel/pri-vatnøkkel-teknikker blir anvendt for å binde det digitale innholdet med en digital lisens ved brukerens beregningsanordning eller klientmaskin.

Når en bruker forsøker å gjengi det digitale innholdet på en beregningsanordning, kaller rendringsapplikasjonen et digital rettighetsforvaltning(DRM)-system på denne brukerens beregningsanordning. Hvis brukeren fordøker å gjengi det digitale innholdet for første gang, vil DRM-systemet enten rette brukeren til en lisenstjener for å oppnå en lisens til å gjengi dette digitale innholdet på den søkte måten, eller oppnår bak kulissene en slik lisens fra en slik lisenstjener uten at det er nødvendig for brukeren å foreta seg noe. Lisensen omfatter: - en dekrypteringsnøkkel (KD) som dekrypterer det krypterte, digitale innholdet; - en beskrivelse av rettighetene (avspilling, kopiering, etc.) som overdras av lisensen og relaterte forhold (startdato, utløpsdato, antall avspillinger, etc), idet denne beskrivelsen er på en digitalt lesbar form; og

- en digital signatur som sikrer lisensens integritet.

Brukeren må ikke være i stand til å dekryptere og gjengi det krypterte digitale innholdet uten å oppnå en slik lisens fra lisenstjeneren. Den oppnådde lisensen blir lagret i et lisenslager i brukerens beregningsanordning.

Det er viktig at lisenstjeneren bare utsteder en lisens til et DRM-system som er "pålitelig" (dvs. som kan autentisere seg). For å implementere "tillit", er DRM-systemet utstyrt med en "sort boks" som utfører dekrypterings- og krypter-ingsfunksjoner for DRM-systemet. Den sorte boksen omfatter et felles/privat-nøk-kelpar, et versjonsnummer og en unik signatur, som alle er tilveiebragt av en godkjent sertifiserende autoritet. Fellesnøkkelen blir gjort tilgjengelig for lisenstjeneren for det formål å kryptere deler av den utstedte lisensen, og med det binde denne lisensen til denne sorte boksen. Den private nøkkelen er kun tilgjengelig for den sorte boksen, og ikke for brukeren eller andre, for det formål å dekryptere informasjon som er kryptert med den motsvarende fellesnøkkelen. DRM-systemet blir innledningsvis tilveiebragt med en sort boks med et felles/privat-nøkkelpar, og brukeren blir bedt om å laste ned fra en sort boks-tjener en oppdatert, sikker sort boks når brukeren første gang ber om en lisens. Sort boks-tjeneren tilveiebringer den oppdaterte sorte boksen, sammen med et unikt fellles/privat-nøkkelpar. En slik oppdatert sort boks er skrevet i en unik eksekverbar kode som kun vil kjøre på brukerens beregningsanordning og som oppdateres jevnlig.

Når en bruker ber om en lisens, sender klientmaskinen den sorte boksens fellesnøkkel, versjonsnummer og signatur til lisenstjeneren, og denne lisenstjeneren utsteder en lisens kun dersom versjonsnummeret er tilstrekkelig oppdatert og signaturen er gyldig. En lisensforespørsel omfatter også en identifikasjon av det digitale innholdet for hvilket det bes om en lisens, samt en nøkkel-identifikator som identifiserer den dekrypteringsnøkkelen som er assosiert med det etterspurte digitale innholdet. Lisenstjeneren anvender den sorte boksens fellesnøk-kel til å kryptere dekrypteringsnøkkelen, og dekrypteringsnøkkelen til å kryptere lisensbetegnelsene, og laster deretter ned den krypterte dekrypteringsnøkkelen og de krypterte lisensbetingelsene til brukerens beregningsanordning sammen med en lisens-signatur.

Når den nedlastede lisensen er lagret i DRM-systemets lisenslager, kan brukeren rendre det digitale innholdet i henhold til de rettigheter som overdras av lisensen og som er spesifisert i lisensbetingelsene. Når det fremsettes en fore-spørsel om å rendre det digitale innholdet, blir den sorte boksen forårsaket å dekryptere dekrypteringsnøkkelen og lisensbetingelsene, og en lisensevaluator i DRM-systemet evaluerer disse lisensbetingelsene. Den sorte boksen dekrypterer det krypterte digitale innholdet kun dersom lisensevalueringen resulterer i en av-gjørelse om at etterspørreren har tillatelse til å spille av dette innholdet. Det dekrypterte innholdet sendes til rendringsapplikasjonen for gjengivelse.

Hver blant flere anordninger kan ha en anordningsnøkkel (DK) med en forhåndsvalgt indeksverdi. Hver anordning er for å motta et lagringsmedium, eller omfatter lagringsmediet. I lagringsmediet er det lagret digitalt innhold som er beskyttet i henhold til en hemmelighet og en tabell som inneholder flere elementer. Hvert element omfatter hemmeligheten kryptert med en nøkkel som kan dekrypteres med anordningsnøkkelen til én blant flere anordninger og en indeksverdi.

For at anordningen skal gjengi innholdet i mediet, oppnår anordningen tabellen fra mediet, oppnår anordningsnøkkelen (DK) til anordningen og indeksverdien til denne anordningsnøkkelen, indekserer inn i element i tabellen basert på den oppnådde indeksverdien, velger den krypterte hemmeligheten fra det indekserte elementet, anvender den oppnådde anordningsnøkkelen på den valgte krypterte hemmeligheten for å eksponere hemmeligheten og anvender den eksponerte hemmeligheten for å gjengi innholdet.

Lagringsmediet inneholder en identifikator for dette mediet. For at vertsdatamaskinen skal tilveiebringe mediet med tabellen, oppnår vertsdatamaskinen

tabellen fra et hurtigbuffer, oppnår mediets identifikatorentifikator fra dette, legger til den oppnådde identifikatoren for mediet i den oppnådde tabellen, anvender en anordningsnøkkel og indeksverdien til denne for å finne det motsvarende elementet i den oppnådde tabellen og eksponerer hemmeligheten i denne tabellen, binder tabellen til mediet ved hjelp av mediets identifikator og den eksponerte hemmeligheten, og kopierer den bundede tabellen til mediet.

Den tilveiebragte tabellen er en (N)-te tabell. For at vertsdatamaskinen skal tilveiebringe mediet med en (N+1)-te, oppdatert tabell for å erstatte den tilveiebragte (N)-te tabellen i mediet, oppnår vertsdatamaskinen den (N+1)-te tabellen 64 med en (N+1)-te hemmelighet fra hurtigbufferet, oppnår mediets identifikator fra dette, legger til den oppnådde identifikatoren til mediet i den (N+1)-te tabellen, oppnår den (N+1)-te hemmeligheten fra den (N+1)-te tabellen og oppnår den (N)-te hemmeligheten fra den (N)-te tabellen i mediet og, dersom en slik eksisterer, en daisy-kjede av tidligere hemmeligheter i den (N)-te tabellen. Hver tidligere hemmelighet i daisy-kjeden blir kryptert i henhold til en umiddelbart følgende hemmelighet og danner en serie av ledd. Vertsdatamaskinen utvider deretter den oppnådde daisy-kjeden og legger til den (N)-te hemmeligheten i denne kryptert med den (N+1)-te hemmeligheten som et nytt ledd i daisy-kjeden, legger til den utvidede daisy-kjeden i den (N+1)-te tabellen, ordner den (N+1)-te tabellen til å omfatte gamle hemmeligheter for ugyldiggjorte anordningsnøkler, tilordner et versjonsnummer til hvert element, binder den (N+1 )-te tabellen til mediet ved hjelp av mediets identifikator og den oppnådde (N+1 )-te hemmeligheten, og kopierer den ordnede (N+1)-te tabellen til mediet for å erstatte den (N)-te tabellen i dette.

For at vertsdatamaskinen skal lagre digitalt innhold i mediet i henhold til den gjeldende hemmeligheten i tabellen i dette, oppnår vertsdatamaskinen identifikatoren fra mediet, oppnår den gjeldende hemmeligheten fra tabellen, anvender den oppnådde, gjeldende hemmeligheten og den oppnådde identifikatoren i en forbestemt funksjon for å generere en endelig hemmelighet, beskytter innholdet som skal lagres i mediet i henhold til den endelige hemmeligheten og binder med det innholdet i mediet via dettes identifikator, og kopierer det beskyttede innholdet til mediet.

Den foregående oppsummeringen, så vel som den etterfølgende detaljerte beskrivelsen av utførelsesformene av foreliggende oppfinnelse, vil bli bedre forstått når de leses sammen med de vedlagte figurene. For det formål å illustrere oppfinnelsen, er det i figurene vist utførelsesformer som på det nåværende tids punkt er foretrukket. Som en må forstå, er imidlertid ikke oppfinnelsen begrenset til de nøyaktige arrangementene og anordningene som er vist. Figur 1 er et blokkdiagram som viser en gjennomtvingningsarkitektur ifølge én utførelsesform av foreliggende oppfinnelse; Figur 2 er et blokkdiagram av generatorprogrammet i arkitekturen i figur 1, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 3 er et blokkdiagram av en digital innholdspakke som omfatter digitalt innhold for anvendelse i forbindelse med arkitekturen i figur 1, ifølge én utførel-sesform av foreliggende oppfinnelse; Figur 4 er et blokkdiagram av brukerens beregningsanordning i figur 1, ifølge én utførelsesform av foreliggende oppfinnelse; Figurene 5A og 5B er flytdiagrammer som viser de trinn som utføres i forbindelse med DRM-systemet i beregningsanordningen i figur 4 for å gjengi innhold, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 6 er et flytdiagram som viser de trinn som utføres i forbindelse med DRM-systemet i figur 4 for å bestemme hvorvidt det eksisterer gyldige, fullmaktsgivende lisenser, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 7 er et flytdiagram som viser de trinn som utføres i forbindelse med DRM-systemet i figur 4 for å oppnå en lisens, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 8 er et blokkdiagram av en digital lisens for anvendelse i forbindelse med arkitekturen i figur 1, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 9 er et flytdiagram som viser de trinn som utføres i forbindelse med DRM-systemet i figur 4 for å oppnå en ny sort boks, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 10 er et flytdiagram som viser de nøkkeltransaksjonstrinn som utføres i forbindelse med DRM-systemet i figur 4 for å validere en lisens og et stykke digitalt innhold og gjengi innholdet, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 11 er et blokkdiagram som viser lisensevaluatoren i figur 4 sammen med en digital rettighetslisens (DRL) i en lisens og en språkmotor for å interpre-tere DRL-lisensen, ifølge én utførelsesform av foreliggende oppfinnelse; Figur 12 er et blokkdiagram som representerer et generelt datasystem der aspekter ved foreliggende oppfinnelse og/eller deler av disse kan innlemmes; Figur 13 er et blokkdiagram som viser en enkel anordning, en vertsdatamaskin og et lagringsmedium som inneholder en hemmelighet-tabell og kryptert innhold som skrives til av vertsdatamaskinen og leses av anordningen, ifølge én ut-førelsesform av foreliggende oppfinnelse; Figurene 14 og 15 er flytdiagrammer som viser nøkkeltrinn som utføres av anordningen i figur 13 under gjengivelse av innholdet; Figur 16 er et blokkdiagram som viser en (N+1 )-te tabell som blir avledet fra en (N)-te tabell av vertsdatamaskinen i figur 13; Figur 17 er et flytdiagram som viser nøkkeltrinn som utføres av vertsdatamaskinen i figur 13 for å oppnå en ny tabell for mediet; Figurene 18 og 18A er flytdiagrammer som viser nøkkel trinn som utføres av vertsdatamaskinen i figur 13 for å erstatte en tabell i mediet; Figur 19 er et flytdiagram som viser nøkkeltrinn som utføres av vertsdatamaskinen i figur 13 for å skrive innhold til mediet; og Figur 20 er et flytdiagram som viser flere nøkkeltrinn som utføres av anordningen i figur 13 for å gjengi innholdet.

Med henvisning til figurene i detalj, i hvilke like referansenummer er anvendt for å angi like elementer, er det i figur 1 vist en gjennomtvingningsarkitektur 10 ifølge én utførelsesform av foreliggende oppfinnelse. Generelt gjør gjen-nomtvingningsarkitekturen 10 det mulig for en eier av digital innhold 12 å spesifisere lisensregler som må være oppfylt før dette digitale innholdet 12 tillates gjengitt på en brukers beregningsanordning 14. Slike lisensregler er omfattet i en digital lisens 16 som brukeren/brukerens beregningsanordning 14 (i det følgende brukes disse betegnelsene om hverandre dersom ikke omstendighetene krever annerledes) må oppnå fra innholdseieren eller en agent for denne. Det digitale innholdet 12 blir distribuert i en kryptert form, og kan distribueres fritt og i stort omfang. Fortrinnsvis er dekrypteringsnøkkelen (KD) for å dekryptere det digitale innholdet 12 inkludert med lisensen 16.

DATAMILJØ

Figur 12 og den etterfølgende beskrivelsen er ment for å tilveiebringe en kort, generell beskrivelse av et egnet datamiljø i hvilket foreliggende oppfinnelse og/eller deler av denne kan implementeres. Selv om det ikke er nødvendig, blir oppfinnelsen beskrevet i den generelle konteksten datamaskin-eksekverbare instruksjoner, så som programmoduler, som eksekveres av en datamaskin, så som en klient-arbeidsstasjon eller en tjener. Generelt omfatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer og liknende som ut-fører spesifikke oppgaver eller implementerer spesifikke abstrakte datatyper. Videre må det forstås at oppfinnelsen og/eller deler av denne kan tilpasses andre datasystemkonstruksjoner, omfattende håndholdte anordninger, flerprosessor-systemer, mikroprosessor-basert eller programmerbar forbrukerelektronikk, personlige datamaskiner i nettverk, minidatamaskiner, stormaskiner og liknende. Oppfinnelsen kan også tilpasses for distribuerte beregningsmiljøer der oppgaver blir utført av fjern-prosesseringsanordninger som er forbundet via et kommunika-sjonsnettverk. I et distribuert datamiljø kan programmoduler befinne seg i både lokale og fjernlokaliserte minnelagringsanordninger.

Som vist i figur 12, omfatter et eksempel på et generelt datasystem en kon-vensjonell personlig datamaskin 120 eller liknende som omfatter en prosesser-ingsenhet 121, et systemminne 122 og en systembuss 123 som forbinder forskjellige systemkomponenter omfattende systemminnet med prosesseringsenhe-ten 121. Systembussen 123 kan være en hvilken som helst blant flere mulige typer buss-strukturer, omfattende en minnebuss eller minnekontrolller, en peri-ferienhet-buss og en lokal buss, som anvender en hvilken som helst blant flere mulige bussarkitekturer. Systemminnet omfatter et leseminne (ROM) 124 og et direktetilgangsminne (RAM) 125. Et BIOS (basic input/output system) 126, som inneholder grunnleggende rutiner som overfører informasjon mellom elementer i den personlige datamaskinen 120, for eksempel under oppstart, er lagret i ROM 124.

Den personlige datamaskinen 120 kan videre omfatte en harddiskstasjon 127 for å lese fra og skrive til en harddisk (ikke vist), en magnetdiskstasjon 128 for å lese fra eller skrive til en flyttbar magnetisk disk 129 og en optisk disk-sta sjon 130 for å lese fra eller skrive til en flyttbar optisk disk 131, så som et CD-ROM eller et annet optisk medium. Harddiskstasjonen 127, magnetdiskstasjonen 128 og optisk disk-stasjonen 130 er forbundet med systembussen 123 henholdsvis via et harddiskstasjon-grensesnitt 132, et magnetdiskstasjon-grensesnitt 133 og et optisk stasjon-grensesnitt 134. Stasjonene og deres assosierte datamaskinlesbare medier tilveiebringer ikke-volatil lagring av datamaskinlesbare instruksjoner, datastrukturer, programmoduler og andre data for den personlige datamaskinen 20.

Selv om det eksempelvise miljøet som er beskrevet her anvender en harddisk, en flyttbar magnetdisk 129 og en flyttbar optisk disk 131, er det underfor-stått at andre typer datamaskinlesbare medier som kan lagre data som kan aksesseres av en datamaskin også kan anvendes i det eksemplifiserte operasjons-miljøet. Slike andre typer medier omfatter en magnetkasett, et flash-minnekort, en digital video disk, en Bernoulli patron, et direktetilgangsminne (RAM), et leseminne (ROM) og liknende.

Flere programmoduler kan være lagret i harddisken, magnetdisken 129, den optiske disken 131, ROM 124 eller RAM 125, omfattende et operativsystem 135, ett eller flere applikasjonsprogrammer 136, andre programmoduler 137 og programdata 138. En bruker kan sende inn kommandoer og informasjon til den personlige datamaskinen 120 via inndataanordninger så som et tastatur 140 og en pekeranordning 142. Andre inndataanordninger (ikke vist) kan omfatte en mikrofon, en styrespak, en spillkonsoll, en parabolantenne, en skanner eller liknende. Disse og andre inndataanordninger blir ofte forbundet med prosesser-ingsenheten 121 via et serieport-grensesnitt 146 som er koplet til systembussen, men kan være forbundet via andre grensesnitt, så som en parallellport, en spillut-gang eller en USB (universal serial bus)-port. En monitor 147 eller en annen type skjermanordning er også forbundet med systembussen 123 via et grensesnitt, så som et skjermkort 148.1 tillegg til monitoren 147, omfatter en personlig datamaskin typisk andre perifere utdataanordninger (ikke vist) så som høyttalere og skrivere. Det eksemplifiserte systemet i figur 12 omfatter også en vertsadapter 155, en SCSI (Small Computer System lnterface)-buss 156 og en ekstern lag-ringsanordning 162 forbundet med SCSI-bussen 156.

Den personlige datamaskinen 120 kan operere i et nettverksmiljø som anvender logiske forbindelser til én eller flere fjern-datamaskiner, så som en fjern-datamaskin 149. Fjern-datamaskinen 149 kan være en annen personlig datamaskin, en tjener, en ruter, en nettverks-PC, en peer-anordning eller en annen vanlig nettverksnode, og omfatter typisk mange av eller alle elementene beskrevet ovenfor i forbindelse med den personlige datamaskinen 120, selv om kun en minnelagringsanordning 150 er illustrert i figur 12. De logiske forbindelsene vist i figur 12 omfatter et lokalt nettverk (LAN) 151 og et fjernaksessnett (WAN) 152. Slike nettverksmiljøer er vanlige i kontorer, bedriftsomspennende datanettverk, intranett og Internett.

Når den anvendes i et LAN-nettverksmiljø, er den personlige datamaskinen 120 forbundet til LAN 151 via et nettverksgrensesnitt eller nettverkskort 153. Når den anvendes i et WAN-nettverksmiljø, omfatter den personlige datamaskinen 120 typisk et modem 154 eller andre anordninger for å etablere kommunikasjon over fjernaksessnettet 152, så som Internett. Modemet 154, som kan være internt eller eksternt, er forbundet med systembussen 123 via serieport-grensesnittet 146.1 et nettverksmiljø kan programmoduler som er vist i forbindelse med den personlige datamaskinen 120 eller deler av disse være lagret i den fjernlokaliserte minnelagringsanordningen. Det vil forstås at de viste nettverksforbindels-ene kun er eksempler, og at det kan anvendes andre anordninger for å etablere en kommunikasjonslink mellom datamaskinene.

ARKITEKTUR

Igjen med henvisning til figur 1, i én utførelsesform av foreliggende oppfinnelse, omfatter arkitekturen 10 et generatorprogram 18, en innholdsnøkkel-database 20, en innholdstjener 22, en lisenstjener 24 og en sort boks-tjener 26, så vel som ovennevnte brukers beregningsanordning 14.

ARKITEKTUR - generatorprogram 18

Generatorprogrammet 18 anvendes av en innholdseier for å pakke inn et digitalt innhold 12 i en form som er egnet for anvendelse i forbindelse med arkitekturen 10 ifølge foreliggende oppfinnelse. Spesielt tilveiebringer innholdseieren generatorprogrammet 18 med det digitale innholdet 12, instruksjoner og/eller regler som skal ledsage det digitale innholdet 12 og instruksjoner og/eller regler for hvorledes det digitale innholdet 12 skal pakkes. Generatorprogrammet 18 produserer da en digital innholdspakke 12p som omfatter det digitale innholdet 12 kryptert med en krypterings / dekrypteringsnøkkel, samt de instruksjonene og/eller reglene som følger det digitale innholdet 12.

I én utførelsesform av foreliggende oppfinnelse blir generatorprogrammet 18 instruert til å serieprodusere flere forskjellige pakker 12p med digitalt innhold 12, hver med samme digitale innhold 12 kryptert med en forskjellig krypterings / dekrypteringsnøkkel. Som en må forstå kan det å ha flere forskjellige pakker 12p med samme digitale innhold 12 være nyttig for å spore distribusjonen av slike pakker 12p / innhold 12 (i det følgende bare betegnet "digitalt innhold 12" dersom ikke omstendighetene krever noe annet). En slik distribusjonssporing er vanligvis ikke nødvendig, men kan anvendes av en etterforskende autoritet i tilfeller der det digitale innholdet 12 har blitt solgt eller kringkastet på ulovlig vis.

I én utførelsesform av foreliggende oppfinnelse er den krypterings / dekryp-teringsnøkkelen som krypterer det digitale innholdet 12 en symmetrisk nøkkel, i den betydning at krypteringsnøkkelen også er dekrypteringsnøkkelen (KD). Som vil bli beskrevet mer detaljert nedenfor, blir en slik dekrypteringsnøkkel (KD) levert til en brukers beregningsanordning 14 i en skjult form som del av en lisens 16 for dette digitale innholdet 12. Fortrinnsvis vil hvert stykke digitalt innhold 12 bli tilveiebragt med en innholdsidentifikator (eller hver pakke 12p tilveiebragt med en pakkeidentifikator), hver dekrypteringsnøkkel (KD) ha en nøkkelidentifikator, og generatorprogrammet 18 forårsake at dekrypteringsnøkkelen (KD), nøkkelidenti-fikatoren og innholdsidentifikatoren (eller pakkeidentifikatoren) for hvert stykke digitalt innhold 12 (eller hver pakke 12p) blir lagret i innholdsnøkkel-databasen 20.

I tillegg kan lisensdata vedrørende typen lisenser 16 som skal utstedes for det digitale innholdet 12 og kravene og betingelsene for hver type lisens 16 være lagret i innholdsnøkkel-databasen 20 eller i en annen database (ikke vist). Fortrinnsvis kan lisensdataene modifiseres av innholdseieren ved et senere tidspunkt, som omstendigheter og markedsforhold kan nødvendiggjøre.

Under bruk blir generatorprogrammet 18 matet med informasjon omfattende, blant annet: - det digitale innholdet 12 som skal pakkes; - typen av og parametere for vannmerking og/eller fingeravtrykk som skal anvendes, hvis noen; - typen av og parametere for datakomprimering som skal anvendes, hvis noen; - typen av og parametere for kryptering som skal anvendes; - typen av og parametere for serialisering som skal anvendes, hvis noen; og - de instruksjoner og/eller regler som skal følge det digitale innholdet 12.

Som kjent er et vannmerke et skjult, datamaskinlesbart signal som blir lagt til det digitale innholdet 12 som en identifikator. Et fingeravtrykk er et vannmerke som er forskjellig for hver instans. Som en må forstå er en instans en unik versjon av det digitale innholdet 12. Det kan lages flere kopier av en hvilken som helst instans, og enhver kopi er av en spesifikk instans. Når en spesifikk instans av digitalt innhold 12 har blitt solgt eller kringkastet på ulovlig vis, vil en etterforskende autoritet muligens kunne identifisere mistenkte på grunnlag av vann-merket/fingeravtrykket som er lagt til i det digitale innholdet 12.

Datakomprimering kan bli utført i henhold til en hvilken som helst egnet komprimeringsalgoritme innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan .mp3 eller .wav komprimeringsalgoritmen anvendes. Det digitale innholdet 12 kan naturligvis allerede være i en komprimert tilstand, i hvilket tilfelle ingen ytterligere komprimering er nødvendig.

Instruksjonene og/eller reglene som skal følge det digitale innholdet 12 kan omfatte praktisk talt hvilke som helst ønskede instruksjoner, regler eller annen informasjon uten å fjerne seg fra idéen bak og rammen til foreliggende oppfinnelse. Som vil bli beskrevet nedenfor, blir ledsagende instruksjoner / regler / informasjon primært anvendt av brukeren og brukerens beregningsanordning 14 for å oppnå en lisens 16 for å gjengi det digitale innholdet 12. Følgelig kan ledsagende instruksjoner / regler / informasjon omfatte et formattert lisensakkvireringsskript eller liknende, som vil bli beskrevet mer detaljert nedenfor. I tillegg, eller alternativt, kan ledsagende instruksjoner / regler / informasjon omfatte "for-håndsvisningsinformasjon" som er designet for å tilveiebringe en bruker med en forhåndsvisning av det digitale innholdet 12.

Med den inngitte informasjonen genererer da generatorprogrammet 18 én eller flere pakker 12p som svarer til det digitale innholdet 12. Hver pakke 12p kan deretter lagres hos innholdstjeneren 22 for distribusjon rundt i verden.

I én utførelsesform av foreliggende oppfinnelse, og nå med henvisning til figur 2, er generatorprogrammet 18 et dynamisk generatorprogram 18 som mottar innparametere som kan spesifiseres og opereres på. Følgelig kan et slikt generatorprogram 18 raskt generere flere variasjoner av pakken 12p for flere en-heter av digitalt innhold 12. Fortrinnsvis er innparametrene innlemmet i form av en datakatalog 28, som vist, idet datakatalogen 28 omfatter slike parametere som: - navnet på innfilen 29a som inneholder det digitale innholdet 12;

- typen av innkoding som skal utføres

- krypterings / dekrypteringsnøkkelen (KD) som skal anvendes,

- ledsagende instruksjoner / regler / informasjon ("topptekst-informasjon") som skal pakkes med det digitale innholdet 12 i pakken 12p.

- typen multipleksing som skal utføres; og

- navnet på utfilen 29b til hvilken pakken 12p som er basert på det digitale innholdet 12 skal skrives.

Som en må forstå, kan en slik datakatalog 28 enkelt og raskt modifiseres av en operatør av generatorprogrammet 18 (menneske eller maskin), og typen edi-tering som utføres av generatorprogrammet 18 kan derfor likeledes enkelt og raskt modifiseres på en dynamisk måte. I én utførelsesform av foreliggende oppfinnelse omfatter generatorprogrammet 18 et operatør-grensesnitt (ikke vist) som kan vises på en dataskjerm for en operatørperson. Følgelig kan en slik operatør modifisere datakatalogen 28 ved hjelp av grensesnittet, og kan videre bli rettledet og/eller restriktert under modifikasjon av datakatalogen 28 ved hjelp av grensesnittet.

I generatorprogrammet 18, og som kan sees i figur 2, mottar et kildefilter 18a navnet på innfilen 29a som omfatter det digitale innholdet 12 fra datakatalo gen 28, og henter dette digitale innholdet 12 fra denne innfilen og plasserer det

digitale innholdet 12 i et minne 29c så som et RAM eller liknende. Et innkodings-filter 18b utfører da koding av det digitale innholdet 12 i minnet 29c for å konvert-ere filen fra innformatet til utformatet i henhold til typen innkoding som er spesifisert i datakatalogen 28 (dvs., .wav til .asp, .mp3 til .asp, etc), og plasserer det innkodede digitale innholdet 12 i minnet 29c. Som vist blir det digitale innholdet 12 som skal pakkes (f.eks. musikk) mottatt i et komprimert format, så som formatet .wav eller .mp3, og blir konvertert til et format så som formatet .asp (aktiv-streaming-protokoll). Selvfølgelig kan andre inn- og utformater anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse.

Deretter krypterer et krypteringsfilter 18c det innkodede, digitale innholdet 12 i minnet 29c med den krypterings / dekrypteringsnøkkelen (KD) som er spesifisert i datakatalogen 28, og plasserer det krypterte digitale innholdet 12 i minnet 29c. Et topptekst-filter 18d legger deretter til den topptekstinformasjonen som er spesifisert i datakatalogen 28 i det krypterte digitale innholdet 12 i minnet 29c.

Som en må forstå, avhengig av situasjonen, kan pakken 12p omfatte flere streamer av midlertidig oppstilt digitalt innhold 12 (én stream er vist i figur 2), idet disse flere streamene blir multiplekset. Følgelig utfører et multiplekserfilter 18e multipleksing av topptekstinformasjonen og kryptert digitalt innhold 12 i minnet

29c i henhold til den typen multipleksing som er spesifisert i datakatalogen 28, og plasserer resultatet i minnet 29c. Et filskriverfilter 18f henter da resultatet fra minnet 29c og skriver dette resultatet til den utfilen 29b som er spesifisert i datakatalogen 28 som pakken 12p.

Det skal bemerkes at, i visse tilfeller, typen innkoding som skal utføres normalt ikke vil endre seg. Siden typen multipleksing typisk er basert på typen innkoding, er det likeledes slik at typen multipleksing normalt heller ikke vil endre seg. Dersom det faktisk er slik, trenger ikke datakatalogen 28 omfatte parametere vedrørende typen innkoding og/eller typen multipleksing. Istedet er det kun nødvendig at typen innkoding blir "hardkodet" i innkodingsfilteret og/eller at typen multipleksing blir "hardkodet" i multiplekserfilteret. Selvfølgelig, etter hva som kreves av omstendighetene, trenger ikke generatorprogrammet 18 omfatte alle de ovennevnte filtrene, eller det kan omfatte andre filtre, og ethvert inkludert filter kan være hardkodet eller kan utføre sin funksjon i henhold til parametere spesifisert i datakatalogen 28, alt innenfor idéen bak og rammen til foreliggende oppfinnelse.

Fortrinnsvis implementeres generatorprogrammet 18 på en egnet datamaskin, prosessor eller annen beregningsmaskin ved hjelp av passende programvare. Strukturen til og operasjonen av en slik maskin og slik programvare vil være åpenbar basert på beskrivelsen her, og krever derfor ingen ytterligere detaljert diskusjon i den foreliggende beskrivelsen.

ARKITEKTUR - innholdstjener 22

Igjen med henvisning til figur 1, i én utførelsesform av foreliggende oppfinnelse, vil innholdstjeneren 22 distribuere eller på annen måte gjøre tilgjengelig for avhenting pakkene 12p som er generert av generatorprogrammet 18. Slike pakker 12p kan distribueres på forespørsel fra innholdstjeneren 22 via en hvilken som helst egnet distribusjonskanal innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan en slik distribusjonskanal være Internett eller et annet nettverk, en elektronisk oppslagstavle, elektronisk post eller liknende. I tillegg kan innholdstjeneren 22 anvendes for å kopiere pakkene 12p til magnetiske eller optiske disker eller andre lagringsanordninger, og disse lagringsanordning-ene kan deretter bli distribuert.

Det vil bli forstått at innholdstjeneren 22 distribuerer pakker 12p uten hensyn til klarerings- eller sikkerhetsproblematikk. Som beskrevet nedenfor blir denne problematikken håndtert i forbindelse med lisenstjeneren 24 og relasjonen mellom denne lisenstjeneren 24 og brukerens beregningsanordning 14.1 én ut-førelsesform av foreliggende oppfinnelse frigir og distribuerer innholdstjeneren 22 fritt pakker 12p som omfatter digitalt innhold 12 til hvem som helst som ber om disse. Innholdstjeneren 22 kan imidlertid også frigi og distribuere slike pakker 12p i et begrenset omfang innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan innholdstjeneren 22 først kreve betaling av en forbestemt distribusjonsavgift før distribusjon, eller den kan kreve at en som skal distribueres pakken identifiserer seg, eller den kan foreta en avgjørelse av hvorvidt distribusjonen skal tillates basert på en identifikasjon av etterspørreren.

I tillegg kan innholdstjeneren 22 anvendes for å utøve lagerstyring ved å instruere generatorprogrammet 18 om å generere et antall forskjellige pakker 12p på forhånd for å imøtekomme en forventet etterspørsel. For eksempel kan tjeneren generere 100 pakker 12p basert på samme digitale innhold 12 og dele ut hver pakke 12p 10 ganger. Når en beholdning av pakker 12p er redusert til 20, for eksempel, kan innholdstjeneren 22 da instruere generatorprogrammet 18 om å generere, for eksempel, 80 nye pakker 12p.

Fortrinnsvis har innholdstjeneren 22 i arkitekturen 10 et unikt felles/privat-nøkkelpar (PU-CS, PR-CS) som blir anvendt som del av prosessen med å evaluere en lisens 16 og oppnå en dekrypteringsnøkkel (KD) for å dekryptere tilhør-ende digitalt innhold 12, hvilket vil bli forklart mer i detalj nedenfor. Som kjent er et felles/privat-nøkkelpar en asymmetrisk nøkkel, i den betydning at det som er kryptert med én av nøklene i nøkkelparet bare kan dekrypteres med den andre av nøklene i nøkkelparet. I et krypteringssystem med et felles/privat-nøkkelpar kan fellesnøkkelen gjøres kjent for alle, men den private nøkkelen må alltid holdes hemmelig av innehaveren av denne private nøkkelen. Følgelig, dersom innholdstjeneren 22 krypterer data med sin private nøkkel (PR-CS), kan den sende de krypterte dataene ut i verden med sin fellesnøkkel (PU-CS) for dekrypterings-formål. Tilsvarende, dersom en ekstern anordning ønsker å sende data til innholdstjeneren 22 på en slik måte at bare denne innholdstjeneren 22 skal kunne dekryptere disse dataene, må denne eksterne anordningen først oppnå felles-nøkkelen til innholdstjeneren 22 (PU-CS), og må deretter kryptere dataene med denne fellesnøkkelen. Følgelig kan innholdstjeneren 22 (og bare innholdstjeneren 22) deretter anvende sin private nøkkel (PR-CS) for å dekryptere disse krypterte dataene.

Som med generatorprogrammet 18, blir innholdstjeneren 22 implementert i en egnet datamaskin, prosessor eller annen beregningsmaskin ved hjelp av passende programvare. Strukturen til og operasjonen av en slik maskin og slik programvare skulle være åpenbar basert på beskrivelsen her, og krever derfor ingen detaljert diskusjon i den foreliggende beskrivelsen. Videre kan, i én utførelses-form av foreliggende oppfinnelse, generatorprogrammet 18 og innholdstjeneren 22 befinne seg i samme datamaskin, prosessor eller annen beregningsmaskin, hver i et separat arbeidsrom. En må videre forstå at innholdstjeneren 22 i visse tilfeller kan omfatte generatorprogrammet 18 og/eller utføre funksjonene til generatorprogrammet 18, som beskrevet ovenfor.

Struktur av digital innholdspakke 12p

Nå med henvisning til figur 3, i én utførelsesform av foreliggende oppfinnelse, omfatter pakken 12p med digitalt innhold som den distribueres av innholdstjeneren 22: - det digitale innholdet 12 kryptert med krypterings / dekrypteringsnøkkelen (KD), som beskrevet ovenfor (dvs. (KD(CONTENT))); - innholdsidentifikatoren (eller pakkeidentifikatoren) for dette digitale innholdet 12 (eller pakken 12p); - nøkkelidentifikatoren til dekrypteringsnøkkelen (KD);

- lisensakkvireringsinformasjon, fortrinnsvis i ukryptertform; og

- nøkkelen KD som krypterer innholdstjeneren 22 sin fellesnøkkel (PU-CS), signert med innholdstjeneren 22 sin private nøkkel (PR-CS) (dvs. (KD (PU-CS) S

(PR-CS))).

Med hensyn til (KD (PU-CS) S (PR-CS)), må en forstå at et slikt element skal anvendes i forbindelse med validering av det digitale innholdet 12 og/eller pakken 12p, som vil bli forklart nedenfor. I motsetning til et sertifikat med en digital signatur (se nedenfor), er ikke nøkkelen (PU-CS) nødvendig for å oppnå (KD (PU-CS)). Istedet oppnås nøkkelen (PU-CS) ganske enkelt ved å anvende de-krypteringsnøkkelen (KD). Når den er oppnådd på denne måten, kan nøkkelen (PU-CS) anvendes for å sjekke gyldigheten til signaturen (S (PR-CS)).

Det må også forstås at for at en slik pakke 12p skal kunne genereres av generatorprogrammet 18, dette generatorprogrammet 18 allerede må besitte lis-ensakkvireringsinformasjonen og (KD (PU-CS) S (PR-CS)), trolig som topptekst-informasjon tilveiebragt i datakatalogen 28. Videre må generatorprogrammet 18 og innholdstjeneren 22 trolig vekselvirke for å generere

(KD (PU-CS) S (PR-CS)). Denne vekselvirkningen kan for eksempel omfatte de trinn der:

- innholdstjeneren 22 sender (PU-CS) til generatorprogrammet 18; - generatorprogrammet 18 krypterer (PU-CS) med (KD) for å generere (KD (PU-CS)); - generatorprogrammet 18 sender (KD (PU-CS)) til innholdstjeneren 22; - innholdstjeneren 22 signerer (KD (PU-CS)) med (PR-CS) for å generere (KD (PU-CS) S (PR-CS)); og - innholdstjeneren 22 sender (KD (PU-CS) S (PR-CS)) til generatorprogrammet 18.

ARKITEKTUR - lisenstjener 24

Igjen med henvisning til figur 1, i én utførelsesform av foreliggende oppfinnelse, utfører lisenstjeneren 24 de funksjoner å motta en forespørsel om en lisens 16 fra en brukers beregningsanordning 14 i forbindelse med digitalt innhold 12, bestemme hvorvidt brukerens beregningsanordning 14 kan gis en utstedt lisens 16, forhandle en slik lisens 16, generere lisensen 16 og sende lisensen 16 til brukerens beregningsanordning 14. Fortrinnsvis omfatteren slik oversendt lisens 16 dekrypteringsnøkkelen (KD) for å dekryptere det digitale innholdet 12. Lisenstjeneren 24 og disse funksjonene vil bli forklart mer i detalj nedenfor. Fortrinnsvis, og i likhet med innholdstjeneren 22, har lisenstjeneren 24

i arkitekturen 10 et unikt felles/privat-nøkkelpar (PU-LS, PR-LS) som blir anvendt som del av prosessen med å evaluere en lisens 16 og oppnå en dekrypterings-nøkkel (KD) for å dekryptere motsvarende digitalt innhold 12, som vil bli forklart mer i detalj nedenfor.

I likhet med generatorprogrammet 18 og innholdstjeneren 22, blir lisenstjeneren 24 implementert i en egnet datamaskin, prosessor eller annen beregningsmaskin ved hjelp av passende programvare. Strukturen til og operasjonen av en slik maskin og slik programvare skulle være åpenbar basert på beskrivelsen her, og krever derfor ingen detaljert diskusjon i foreliggende beskrivelse. Videre kan, i én utførelsesform av foreliggende oppfinnelse, generatorprogrammet 18 og/eller innholdstjeneren 22 befinne seg i én og samme datamaskin, prosessor eller annen beregningsmaskin sammen med lisenstjeneren 24, hver i et separat arbeidsrom.

I én utførelsesform av foreliggende oppfinnelse, før utstedelse av en lisens 16, inngår lisenstjeneren 24 og innholdstjeneren 22 en agenturavtale eller liknende der lisenstjeneren 24 samtykker i å være den lisensgivende myndighet for i hvert fall en del av det digitale innholdet 12 som blir distribuert av innholdstjeneren 22. Som en må forstå kan én innholdstjener 22 inngå en agenturavtale eller liknende med flere lisenstjenere 24, og/eller én lisenstjener 24 kan inngå en agenturavtale eller liknende med flere innholdstjenere 22, alt innenfor idéen bak og rammen til foreliggende oppfinnelse.

Fortrinnsvis kan lisenstjeneren 24 vise for alle at den faktisk har myndighet til å utstede en lisens 16 for digitalt innhold 12 som er distribuert av innholdstjeneren 22. For å gjøre dette, er det foretrukket at lisenstjeneren 24 sender til innholdstjeneren 22 lisenstjeneren 24 sin fellesnøkkel (PU-LS), og at innholdstjeneren 22 deretter sender til lisenstjeneren 24 et digitalt sertifikat som inneholder PU-LS som innholdet signert av innholdstjeneren 22 sin private nøkkel

(CERT (PU-LS) S (PR-CS)). Som en må forstå kan innholdet (PU-LS) i et slikt sertifikat bare aksesseres med innholdstjeneren 22 sin fellesnøkkel (PU-CS). Som en også må forstå er en digital signatur av underliggende data generelt en kryptert utgave av disse dataene, og vil ikke overensstemme med disse dataene når den blir dekryptert dersom dataene har blitt forfalsket eller på annen måte modifisert.

Som en lisensgivende myndighet i forbindelse med digitalt innhold 12, og som del av lisensieringsfunksjonen, må lisenstjeneren 24 ha tilgang til dekrypter-ingsnøkkelen (KD) for dette digitale innholdet 12. Følgelig er det foretrukket at lisenstjener 24 har tilgang til den innholdsnøkkel-databasen 20 som omfatter de-krypteringsnøkkelen (KD), nøkkelidentifikatoren og innholdsidentifikatoren (eller pakkeidentifikatoren) for det digitale innholdet 12 (eller pakken 12p).

ARKITEKTUR - sort boks-tjener 26

Fortsatt med henvisning til figur 1, i én utførelsesform av foreliggende oppfinnelse, utfører sort boks-tjeneren 26 de funksjoner å installere og/eller oppgradere en ny sort boks 30 i en brukers beregningsanordning 14. Som vil bli forklart mer i detalj nedenfor, utfører den sorte boksen 30 krypterings- og dekrypterings funksjoner for brukerens beregningsanordning 14. Som også vil bli forklart mer i detalj nedenfor, er den sorte boksen 30 ment å være sikker og beskyttet mot angrep. Slik sikkerhet og beskyttelse tilveiebringes, i hvert fall delvis, ved å oppgradere den sorte boksen 30 til en ny versjon ved behov ved hjelp av sort boks-tjeneren 26, som vil bli forklart mer i detalj nedenfor.

Som med generatorprogrammet 18, innholdstjeneren 22 og lisenstjeneren 24, blir sort boks-tjeneren 26 implementert i en egnet datamaskin, prosessor eller annen beregningsmaskin ved hjelp av passende programvare. Strukturen til og operasjonen av en slik maskin og slik programvare skulle være åpenbar basert på beskrivelsen her, og krever derfor ingen detaljert diskusjon i foreliggende beskrivelse. Videre kan, i én utførelsesform av foreliggende oppfinnelse, lisenstjeneren 24, generatorprogrammet 18 og/eller innholdstjeneren 22 befinne seg i én og samme datamaskin, prosessor eller annen beregningsmaskin sammen med sort boks-tjeneren 26, hver i et separat arbeidsrom. Merk at det likevel som en sikkerhetsforanstaltning kan være lurt å ha sort boks-tjeneren 26 på en separat maskin.

ARKITEKTUR - brukers beregningsanordning 14

Nå med henvisning til figur 4 er, i én utførelsesform av foreliggende oppfinnelse, brukerens beregningsanordning 14 en personlig datamaskin eller liknende som inneholder elementer omfattende et tastatur, en mus, en skjermenhet, en prosessor, et RAM, et ROM, en harddiskstasjon, en diskettstasjon, en CD-spiller og/eller liknende. Brukerens beregningsanordning 14 kan imidlertid også være en dedikert fremvisningsanordning så som et fjernsyn eller en monitor, en dedikert lydavspillingsanordning så som et stereoanlegg eller en annen musikkavspil-ler, en dedikert skriver, eller liknende, blant annet, alt innenfor idéen bak og rammen til foreliggende oppfinnelse.

Eieren av digitalt innhold 12 må stole på at brukerens beregningsanordning 14 vil rette seg etter de regler som er spesifisert av denne innholdseieren, dvs. at det digitale innholdet 12 ikke vil bli gjengitt dersom ikke brukeren oppnår en lisens 16 som tillater gjengivelse på den søkte måten. Brukerens beregningsanordning 14 må derfor fortrinnsvis tilveiebringe en pålitelig komponent eller meka nisme 32 som kan forsikre innholdseieren om at denne beregningsanordningen 14 ikke vil gjengi det digitale innholdet 12 på annen måte enn i henhold til lisensreglene som er inneholdt i den lisensen 16 som er assosiert med det digitale innholdet 12 og oppnådd av brukeren.

Her er den pålitelige mekanismen 32 et digital rettighetsforvaltnings (DRM)-system 32 som aktiveres når en bruker ber om at et stykke digitalt innhold 12 blir rendret, som bestemmer hvorvidt brukeren har en lisens 16 for å rendre det digitale innholdet 12 på den ønskede måten, som utfører det å oppnå en slik lisens 16 om nødvendig, som avgjør hvorvidt brukeren har rettighet til å spille det digitale innholdet 12 i henhold til lisensen 16, og som dekrypterer det digitale innholdet 12 for rendringsformål dersom brukeren faktisk har rettighet til dette i henhold til lisensen 16. Innholdet i og funksjonen til DRM-systemet 32 i brukerens beregningsanordning 14 og i forbindelse med arkitekturen 10 er beskrevet nedenfor.

DRM-system 32

DRM-systemet 32 utfører fire hovedfunksjoner med arkitekturen 10 som er beskrevet her: (1) akkvisisjon av innhold, (2) lisensakkvisisjon, (3) rendring av innhold og (4) installering/oppdatering av den sorte boksen 30. Fortrinnsvis kan hvilke som helst av funksjonene utføres på et hvilket som helst tidspunkt, selv om en innser at noen av funksjonene krever at det digitale innholdet 12 er akkvi-rert på forhånd.

DRM-system 32 - akkvirering av innhold

Akkvirering av digitalt innhold 12 av en bruker og/eller brukerens beregningsanordning 14 er typisk en forholdsvis enkel operasjon, og omfatter generelt det å plassere en fil som inneholder kryptert digitalt innhold 12 i brukerens beregningsanordning 14. Selvfølgelig, for å fungere med arkitekturen 10 og DRM-systemet 32 beskrevet her, er det nødvendig at det krypterte digitale innholdet 12 er på en form som er egnet for arkitekturen 10 og DRM-systemet 32, så som den digitale pakken 12p som vil bli beskrevet nedenfor.

Som en må forstå kan det digitale innholdet 12 oppnås på en hvilken som helst måte fra en innholdstjener 22, enten direkte eller indirekte, innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan slikt digitalt innhold 12 være lastet ned fra et nettverk så som Internett, være lokalisert på en oppnådd optisk eller magnetisk disk eller liknende, være mottatt som del av en e-postmelding eller liknende eller lastet ned fra en elektronisk oppslagstavle eller liknende.

Slikt digitalt innhold 12, når det er oppnådd, blir fortrinnsvis lagret på en slik måte at det oppnådde digitale innholdet 12 kan aksesseres av en rendringsapplikasjon 34 (som vil bli beskrevet nedenfor) som kjører på beregningsanordningen 14, og av DRM-systemet 32. For eksempel kan det digitale innholdet 12 plasseres som en fil på en harddisk (ikke vist) i brukerens beregningsanordning 14 eller på en nettverkstjener (ikke vist) som kan aksesseres av beregningsanordningen 14.1 tilfellet der det digitale innholdet 12 blir oppnådd på en optisk eller magnetisk disk eller liknende, kan det være tilstrekkelig at denne disken er til stede i en tilhørende stasjon (ikke vist) som er forbundet med brukerens beregningsanordning 14.

I foreliggende oppfinnelse ser en ikke for seg at det skal være nødvendig med spesialverktøy for å akkvirere digital innhold 12, enten fra innholdstjeneren 22 som en direkte distribusjonskilde eller en mellomstasjon som en indirekte distribusjonskilde. Det vil si at det er foretrukket at det digitale innholdet 12 er like enkelt å oppnå som en hvilken som helst annen datafil. DRM-systemet 32 og/eller rendringsapplikasjonen 34 kan imidlertid omfatte et grensesnitt (ikke vist) som er konstruert for å hjelpe brukeren med å oppnå det digitale innholdet 12. For eksempel kan grensesnittet omfatte en nettleser som er spesialkonstruert for å søke etter digitalt innhold 12, linker til forhåndsdefinerte web-områder på Internett som er kjente som kilder for digitalt innhold 12, og liknende.

DRM-system 32 - rendring av innhold, del 1

Nå med henvisning til figur 5A, i én utførelsesform av foreliggende oppfinnelse, antatt at det krypterte digitale innholdet 12 er distribuert til og mottatt av en bruker og plassert av brukeren i beregningsanordningen 14 i form av en lagret fil, vil brukeren forsøke å gjengi det digitale innholdet 12 ved å eksekvere en varia-sjon av en rendringskommando (trinn 501). For eksempel kan denne rendrings- kommandoen være i form av en forespørsel om å "avspille" eller "åpne" det digitale innholdet 12.1 enkelte datamiljøer, så som for eksempel operativsystemet

"MICROSOFT WINDOWS", distribuert av MICROSOFT Corporation i Redmond, Washington, kan denne avspillings- eller åpne-kommandoen være så enkel som å "klikke" på et ikon som representerer det digitale innholdet 12. Selvfølgelig kan det anvendes andre utførelsesformer av en slik rendringskommando innenfor idéen bak og rammen til foreliggende oppfinnelse. Generelt kan en slik rendringskommando betraktes å bli eksekvert hver gang en bruker instruerer at en fil som omfatter digitalt innhold 12 åpnes, kjøres, eksekveres og/eller liknende.

Viktig, og i tillegg, kan en slik rendringskommando være i form av en fore-spørsel om å kopiere det digitale innholdet 12 til en annen form, så som til utskrevet form, en visuell form, en hørbar form, etc. Som en må forstå kan samme digitale innhold 12 bli gjengitt på én form, så som på en dataskjerm, og deretter på en annen form, så som et utskrevet dokument. I foreliggende oppfinnelse blir hver type gjengivelse kun utført dersom brukeren har rettighet til å gjøre dette, som vil bli forklart nedenfor.

I én utførelsesform av foreliggende oppfinnelse er det digitale innholdet 12 i form av en digital fil som har et filnavn som ender med en filendelse, og beregningsanordningen 14 kan basert på denne f Hendelsen velge å starte en spesiell type rendringsapplikasjon 34. For eksempel, dersom filendelsen angir at det digitale innholdet 12 er en tekstfil, er rendringsapplikasjonen 34 en form for tekstbe-handler så som "MICROSOFT WORD", distribuert av MICROSOFT Corporation i Redmond, Washington. Tilsvarende, dersom filendelsen angir at det digitale innholdet 12 er en lyd-, video- og/eller multimediafil, er rendringsapplikasjonen 34 en form for multimediaspiller, så som "MICROSOFT MEDIA PLAYER", også distribuert av MICROSOFT Corporation i Redmond, Washington.

Selvfølgelig kan det anvendes andre metoder for å velge en rendringsapplikasjon innenfor idéen bak og rammen til foreliggende oppfinnelse. Kun som et eksempel kan det digitale innholdet 12 inneholde metadata i en ukryptert form (dvs. ovennevnte topptekstinformasjon), idet metadataene omfatter informasjon om typen rendringsapplikasjon 34 som er nødvendig for å gjengi dette digitale innholdet 12.

En slik rendringsapplikasjon 34 undersøker fortrinnsvis det digitale innholdet 12 assosiert med filnavnet og bestemmer hvorvidt det digitale innholdet 12 er kryptert i en rettighetsbeskyttet form (trinnene 503, 505). Dersom det ikke er beskyttet, kan det digitale innholdet 12 gjengis uten ytterligere omveier (trinn 507). Dersom det er beskyttet, bestemmer rendringsapplikasjonen 34 fra det krypterte digitale innholdet 12 at DRM-systemet 32 er nødvendig for å spille av dette digitale innholdet 12. Følgelig instruerer rendringsapplikasjonen 34 brukerens beregningsanordning 14 om å kjøre DRM-systemet 32 deri (trinn 509). Rendringsapplikasjonen 34 kaller da dette DRM-systemet 32 for å dekryptere det digitale innholdet 12 (trinn 511). Som vil bli beskrevet mer detaljert nedenfor, vil DRM-systemet 32 dekryptere det digitale innholdet 12 bare dersom brukeren har en gyldig lisens

16 for dette digitale innholdet 12 og rettighet til å spille det digitale innholdet 12 i

henhold til lisensreglene i den gyldige lisensen 16. Fortrinnsvis, når DRM-systemet 32 har blitt kalt av rendringsapplikasjonen 34, overtar dette DRM-systemet 32 kontrollen fra rendringsapplikasjonen 34, i hvert fall for det formål å bestemme hvorvidt brukeren har rettighet til å spille det digitale innholdet 12 (trinn 513).

Komponenter i DRM-system 32

I én utførelsesform av foreliggende oppfinnelse, og igjen med henvisning til figur 4, omfatter DRM-systemet 32 en lisensevaluator 36, den sorte boksen 30, et lisenslager 38 og et tilstandslager 40.

Komponenter i DRM-system 32 - lisensevaluator 36

Lisensevaluatoren 36 lokaliserer én eller flere lisenser 16 som svarer til det etterspurte digitale innholdet 12, bestemmer hvorvidt disse lisensene 16 er gyldige, går gjennom lisensreglene i de gyldige lisensene 16, og bestemmer, basert på de gjennomgåtte lisensreglene, hvorvidt den etterspørrende brukeren har rettighet til å gjengi det etterspurte digitale innholdet 12 på den søkte måten, blant annet. Som en må forstå er lisensevaluatoren 36 en pålitelig komponent i DRM-systemet 32.1 den foreliggende beskrivelsen betyr det å være "pålitelig" at lisenstjeneren 24 (eller et hvilket som helst annet klarerende element) er sikker på at det pålitelige elementet vil utføre ønskene til eieren av det digitale innholdet 12 i tråd med rettighetsbeskrivelsen i lisensen 16, og at en bruker ikke på en enkel måte kan endre dette pålitelige elementet for noe formål, forbrytersk eller annet.

Lisensevaluatoren 36 må være pålitelig for å sikre at denne lisensevaluatoren 36 faktisk vil evaluere en lisens 16 på skikkelig måte, og for å sikre at lisensevaluatoren 36 ikke har blitt forfalsket eller på annen måte modifisert av en bruker for det formål å unngå faktisk evaluering av en lisens 16. Følgelig kjører lisensevaluatoren 36 i et beskyttet eller innkapslet miljø, slik at brukeren nektes tilgang til denne lisensevaluatoren 36. Andre beskyttelsesmekanismer kan selvføl-gelig anvendes i forbindelse med lisensevaluatoren 36 innenfor idéen bak og rammen til foreliggende oppfinnelse.

Komponenter i DRM-system 32 - sort boks 30

Primært, og som beskrevet ovenfor, utfører den sorte boksen 30 krypterings- og dekrypteringsfunksjoner i DRM-systemet 32. Spesielt jobber den sorte boksen 30 sammen med lisensevaluatoren 36 for å dekryptere og kryptere viss informasjon som del av lisensevalueringsfunksjonen. I tillegg, når lisensevaluatoren 36 bestemmer at en bruker faktisk har rettighet til å gjengi det etterspurte digitale innholdet 12 på den søkte måten, blir den sorte boksen 30 tilveiebragt med en dekrypteringsnøkkel (KD) for dette digitale innholdet 12 og utførerfunk-sjonen med å dekryptere dette digitale innholdet 12 basert på denne dekrypter-ingsnøkkelen (KD).

Den sorte boksen 30 er også en pålitelig komponent i DRM-systemet 32. Spesielt må lisenstjeneren 24 kunne stole på at den sorte boksen 30 vil utføre dekrypteringsfunksjonen kun i henhold til lisensreglene i lisensen 16, og også stole på at denne sorte boksen 30 ikke vil fungere dersom den blir forfalsket eller på annen måte modifisert av en bruker for det forbryterske formål å omgå den faktiske evalueringen av en lisens 16. Følgelig kjører også den sorte boksen 30 i et beskyttet eller innkapslet miljø, slik at brukeren nektes tilgang til denne sorte boksen 30. Også her kan andre beskyttelsesmekanismer anvendes i forbindelse med den sorte boksen 30 innenfor idéen bak og rammen til foreliggende oppfinnelse. Fortrinnsvis, og i likhet med innholdstjeneren 22 og lisenstjeneren 24, har den sorte boksen 30 i DRM-systemet 32 et unikt felles/privat-nøkkelpar (PU-BB, PR-BB) som blir anvendt som del av prosessen med å evaluere lisensen 16 og oppnå en dekrypteringsnøkkel (KD) for å dekryptere det digitale innholdet 12, som vil bli beskrevet mer detaljert nedenfor.

Komponenter i DRM-system 32 - lisenslager 38

Lisenslageret 38 lagrer lisenser 16 som mottas av DRM-systemet 32 for til-hørende digitalt innhold 12. Lisenslageret 38 i seg selv trenger ikke være pålitelig siden lisenslageret 38 bare lagrer lisenser 16, hver av hvilke allerede omfatter innbygde klarerte komponenter, som vil bli beskrevet nedenfor. I én utførelses-form av foreliggende oppfinnelse er lisenslageret 38 ganske enkelt en underkata-log i en stasjon så som en harddiskstasjon eller en nettverksstasjon. Lisenslageret 38 kan imidlertid innlemmes i en hvilken som helst annen form innenfor idéen bak og rammen til foreliggende oppfinnelse, så lenge dette lisenslageret 38 utfø-rer den funksjon å lagre lisenser 16 i et område som er hensiktsmessig for DRM-systemet 32.

Komponenter i DRM-system 32 - tilstandslager 40

Tilstandslageret 40 utfører den funksjon å opprettholde tilstandsinformasjon svarende til lisenser 16 som er eller har vært i lisenslageret 38. Slik tilstandsinformasjon blir generert av DRM-systemet 32 og lagret i tilstandslageret 40 etter behov. For eksempel, dersom en gitt lisens 16 kun tillater et forbestemt antall gjengivelser av tilhørende digitalt innhold 12, opprettholder tilstandslageret 40 tilstandsinformasjon vedrørende hvor mange gjengivelser som har vært gjort i forbindelse med denne lisensen 16. Tilstandslageret 40 fortsetter å opprettholde tilstandsinformasjon om lisenser 16 som ikke lenger finnes lisenslageret 38 for å unngå den situasjonen der det ellers ville være fordelaktig å slette en lisens 16 fra lisenslageret 38 og deretter legge inn en identisk lisens 16 i et forsøk på å slette den tilhørende tilstandsinformasjonen fra tilstandslageret 40.

Tilstandslageret 40 må også være pålitelig for å sikre at informasjonen som er lagret i dette ikke blir tilbakeført til en tilstand som er mer fordelaktig for en bruker. Følgelig kjøres tilstandslageret 40 likeledes i et beskyttet eller innkapslet miljø, slik at brukeren blir nektet tilgang til dette tilstandslageret 40. Igjen kan selvfølgelig andre beskyttende mekanismer anvendes i forbindelse med tilstandslageret 40 innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan tilstandslageret 40 bli lagret av DRM-systemet 32 i beregningsanordningen 14 i en kryptert form.

DRM-system 32 - rendring av innhold, del 2

Igjen med henvisning til figur 5A, og idet det igjen diskuteres rendring av innhold i én utførelsesform av foreliggende oppfinnelse, når DRM-systemet 32 har overtatt kontrollen fra den kallende rendringsapplikasjonen 34, begynner dette DRM-systemet 32 prosessen med å avgjøre hvorvidt brukeren har en rettighet til å gjengi det etterspurte digitale innholdet 12 på den søkte måten. Spesielt lokaliserer DRM-systemet 32 enten en gyldig, fullmaktsgivende lisens 16 i lisenslageret (trinnene 515, 517), eller det forsøker å akkvirere en gyldig, fullmaktsgivende lisens 16 fra lisenstjeneren 24 (dvs. utfører lisensakkvireringsfunksjonen som beskrevet nedenfor og som vist i figur 7).

Som et første trinn, og nå med henvisning til figur 6, sjekker lisensevaluatoren 36 i DRM-systemet 32 lisenslageret 38 for tilstedeværelse av én eller flere mottatte lisenser 16 som svarer til det digitale innholdet 12 (trinn 601). Lisensen 16 er typisk i form av en digital fil, som vil bli beskrevet nedenfor, selv om det vil forstås at lisensen 16 også kan eksistere i andre former innenfor idéen bak og rammen til foreliggende oppfinnelse. Brukeren vil typisk motta det digitale innholdet 12 uten en slik lisens 16, selv om det likeledes vil forstås at det digitale innholdet 12 kan mottas med en tilhørende lisens 16 innenfor idéen bak og rammen til foreliggende oppfinnelse.

Som beskrevet ovenfor i forbindelse med figur 3, er hvert stykke digitalt innhold 12 i en pakke 12p med en innholdsidentifikator (eller pakkeidentifikator) som identifiserer dette digitale innholdet 12 (eller pakken 12p), og en nøkkelidentifika-tor som identifiserer den dekrypteringsnøkkelen (KD) som vil dekryptere det krypterte digitale innholdet 12. Fortrinnsvis er innholdsidentifikatoren (eller pakkeidentifikatoren) og nøkkelidentifikatoren i en ikke-kryptert form. Følgelig, og spesielt, basert på innholdsidentifikatoren for det digitale innholdet 12, leter lisensevaluatoren 36 etter en hvilken som helst lisens 16 i lisenslageret 38 som inneholder en identifikasjon av anvendbarhet for denne innholdsidentifikatoren. Merk at det kan bli funnet flere slike lisenser 16, spesielt dersom eieren av det digitale innholdet 12 har spesifisert flere forskjellige typer lisenser 16 for dette digitale innholdet 12 og brukeren har oppnådd flere slike lisenser 16. Dersom lisensevaluatoren 36 ikke finner, i lisenslageret 38, noen lisens 16 som svarer til det etterspurte digitale innholdet 12, kan da DRM-systemet 32 utføre lisensakkvireringsfunksjonen (trinn 519 i figur 5), som beskevet nedenfor.

Anta nå at DRM-systemet 32 har blitt forespurt om å gjengi et stykke digitalt innhold 12 og at én eller flere lisenser 16 som svarer til dette eksisterer i lisenslageret 38.1 én utførelsesform av foreliggende oppfinnelse, fortsetter da lisensevaluatoren 36 i DRM-systemet 32 for å bestemme for hver slik lisens 16 hvorvidt denne lisensen 16 er gyldig (trinnene 603 og 605 i figur 6). Fortrinnsvis og spesielt, omfatter hver lisens 16 en digital signatur 26 basert på innholdet 28 i lisensen 16. Som en må forstå vil ikke den digitale signaturen 26 overensstemme med lisensen 16 dersom innholdet 28 har blitt forfalsket eller på annen måte modifisert. Lisensevaluatoren 36 kan således på grunnlag av den digitale signaturen 26 bestemme hvorvidt innholdet 28 er i den formen som det ble mottatt fra lisenstjeneren 24 (dvs. er gyldig). Dersom det ikke finnes en gyldig lisens 16 i lisenslageret 38, kan DRM-systemet 32 da utføre lisensakkvireringsfunksjonen som beskrevet nedenfor for å oppnå en gyldig lisens 16.

Antatt at én eller flere gyldige lisenser 16 ble funnet, bestemmer deretter, for hver gyldige lisens 16, lisensevaluatoren 36 i DRM-systemet 32 hvorvidt denne gyldige lisensen 16 gir brukeren rettighet til å gjengi det tilhørende digitale innholdet 12 på den søkte måten (dvs. gir fullmakt) (trinnene 607 og 609). Spesielt avgjør lisensevaluatoren 36 hvorvidt den forespørrende brukeren har rettighet til å spille det etterspurte digitale innholdet 12 basert på rettighetsbeskrivelsen i hver lisens 16 og basert på hva brukeren forsøker å gjøre med det digitale innholdet 12. For eksempel kan en slik rettighetsbeskrivelse tillate brukeren å rendre det digitale innholdet 12 til lyd, men ikke til en dekryptert, digital kopi.

Som en må forstå spesifiserer rettighetsbeskrivelsen i hver lisens 16 hvorvidt brukeren har rettighet til å spille det digitale innholdet 12 basert på en hvilken som helst av mange mulige faktorer, omfattende hvem brukeren er, hvor bruke ren befinner seg, hva slags type beregningsanordning 14 brukeren anvender, hvilken rendringsapplikasjon 34 som kaller DRM-systemet 32, datoen, klokke-slettet, etc. I tillegg kan rettighetsbeskrivelsen foreksempel begrense lisensen 16 til et forbestemt antall avspillinger eller en forbestemt avspilingstid. I slike tilfeller må DRM-systemet 32 referere til tilstandsinformasjon vedrørende lisensen 16 (dvs. hvor mange ganger det digitale innholdet 12 har blitt rendret, den totale tiden det digitale innholdet 12 har blitt rendret, etc), idet slik tilstandsinformasjon er lagret i tilstandslageret 40 i DRM-systemet 32 på brukerens beregningsanordning 14.

Følgelig går lisensevaluatoren 36 i DRM-systemet 32 gjennom rettighetsbeskrivelsen i hver gyldige lisens 16 for å bestemme hvorvidt denne gyldige lisensen 16 overdrar de rettigheter som søkes for brukeren. I forbindese med dette kan lisensevaluatoren 36 være nødt til å referere til andre data lokalt på brukerens beregningsanordning 14 for å avgjøre hvorvidt brukeren har de etterspurte rettigheter. Som kan sees i figur 4, kan slike data omfatte en identifikasjon 42 av brukerens beregningsanordning (maskin) 14 og spesifikke aspekter ved denne, en identifikasjon 44 av brukeren og spesifikke aspekter ved denne, en identifikasjon av rendringsapplikasjonen 34 og spesifikke aspekter ved denne, en system-klokke 46 og liknende. Dersom det ikke finnes en gyldig lisens 16 som gir brukeren rettighet til å gjengi det digitale innholdet 12 på den søkte måten, kan DRM-systemet 32 da utføre den nedenfor beskrevne lisensakkvireringsfunksjonen for å oppnå en slik lisens 16, dersom en slik lisens 16 faktisk er mulig å oppnå.

Selvfølgelig vil brukeren i noen tilfeller ikke kunne oppnå rettighet til å gjengi det digitale innholdet 12 på den ønskede måten fordi eieren av dette digitale innholdet 12 har instruert at en slik rettighet ikke skal gis. For eksempel kan eieren av dette digitale innholdet 12 ha instruert at det ikke skal gis noen lisens 16 som tillater en bruker å skrive ut et tekstdokument eller å kopiere en multimedia-presentasjon til en ukryptert form. I én utførelsesform av foreliggende oppfinnelse omfatter det digitale innholdet 12 data vedrørende hvilke rettigheter som er tilgjengelige ved kjøp av en lisens 16, og typen lisenser 16 som er tilgjengelig. Det vil imidlertid forstås at eieren av et stykke digitalt innhold 12 på et hvilket som helst tidspunkt kan endre hvilke rettigheter som for tiden er tilgjengelig for dette digitale innholdet 12 ved å endre hva slags lisenser 16 som er tilgjengelig for dette digitale innholdet 12.

DRM SYSTEM 32 - Lisensakkvirering

Nå med henvisning til figur 7, dersom lisensevaluatoren 36 ikke finner, i lisenslageret 38, noen gyldig, fullmaktsgivende lisens 16 som svarer til det etterspurte digitale innholdet 12, kan DRM-systemet 32 da utføre lisensakkvireringsfunksjonen. Som vist i figur 3 er hvert stykke digitalt innhold 12 pakket med ukryptert informasjon vedrørende hvordan en kan oppnå en lisens 16 for å gjengi dette digitale innholdet 12 (dvs. lisensakkvireringsinformasjon).

I én utførelsesform av foreliggende oppfinnelse kan slik lisensakkvireringsinformasjon omfatte (blant annet) typen lisenser 16 som er tilgjengelig og ett eller flere web-områder på Internett eller informasjon om andre steder hvor én eller flere gyldige lisenstjenere 24 kan aksesseres, idet hver slik lisenstjener 24 faktisk kan utstede en lisens 16 for det digitale innholdet 12. Selvfølgelig kan lisensen 16 oppnås på andre måter innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan lisensen 16 oppnås fra en lisenstjener 24 ved en elektronisk oppslagstavle, eller også personlig eller via vanlig post i form av en fil på en magnetisk eller optisk disk eller liknende.

Antatt at stedet for å oppnå en lisens 16 er en lisenstjener 24 i et nettverk, etablerer lisensevaluatoren 36 da en nettverksforbindelse til denne lisenstjeneren 24 basert på informasjonen på web-området eller et annet sted og sender en forespørsel om en lisens 16 fra denne tilkoplede lisenstjeneren 24 (trinnene 701, 703). Spesielt, når DRM-systemet 32 har tatt kontakt med lisenstjeneren 24, overfører DRM-systemet 32 passende lisens-forespørselsinformasjon 36 til lisenstjeneren 24.1 én utførelsesform av foreliggende oppfinnelse kan denne lisens 16 -forespørselsinformasjonen 36 omfatte: - fellesnøkkelen til den sorte boksen 30 i DRM-systemet 32 (PU-BB); - versjonsnummeret til den sorte boksen 30 i DRM-systemet 32; - et sertifikat med en digital signatur fra en sertifiserende autoritet som serti-fiserer den sorte boksen 30 (idet sertifikatet kan omfatte ovennevnte fellesnøkkel og versjonsnummer for den sorte boksen 30); - innholdsidentifikatoren (eller pakkeidentifikatoren) som identifiserer det digitale innholdet 12 (eller pakken 12p); - nøkkelidentifikatoren som identifiserer dekrypteringsnøkkelen (KD) for å dekryptere det digitale innholdet 12; - typen lisens 16 som etterspørres (dersom flere typer er tilgjengelig); - typen rendringsapplikasjon 34 som ber om å få gjengi det digitale innholdet 12;

og/eller liknende, blant annet. Selvfølgelig kan større eller mindre mengder lisens 16 -forespørselsinformasjon 36 bli sendt til lisenstjeneren 24 av DRM-systemet 32 innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel trenger ikke informasjon om typen rendringsapplikasjon 34 være nødvendig, mens ytterligere informasjon om brukeren og/eller brukerens beregningsanordning 14 kan være nødvendig.

Når lisenstjeneren 24 har mottatt lisens 16 -forespørselsinformasjonen 36 fra DRM-systemet 32, kan da lisenstjeneren 24 utføre flere sjekker for klarering / autentisering og for andre formål. I én utførelsesform av foreliggende oppfinnelse sjekker denne lisenstjeneren 24 sertifikatet med den digitale signaturen fra den sertifiserende myndigheten for å bestemme hvorvidt denne har blitt forfalsket eller på annen måte modifisert (trinnene 705, 707). Dersom dette er tilfelle nekter lisenstjeneren 24 å utstede en lisens 16 basert på forespørselsinformasjonen 36. Lisenstjeneren 24 kan også opprettholde en liste over kjente "svartelistede" brukere og/eller brukeres beregningsanordninger 14, og kan nekte å utstede en lisens 16 basert på en forespørsel fra en slik svartelistet bruker og/eller en svartelistet bruker-beregningsanordning 14. En slik "svarteliste" kan settes opp på en hvilken som helst hensiktsmessig måte innenfor idéen bak og rammen til foreliggende oppfinnelse.

Basert på den mottatte forespørselen og informasjonen assosiert med denne, og spesielt basert på innholdsidentifikatoren (eller pakkeidentifikatoren) i lisensforespørselsinformasjonen, kan lisenstjeneren 24 henvende seg til inn-holdsnøkkel-databasen 20 (figur 1) og lokalisere en post som svarer til det digitale innholdet 12 (eller pakken 12p) som er grunnlaget for forespørselen. Som beskrevet ovenfor, inneholder en slik post dekrypteringsnøkkelen (KD), nøkkel- identifikatoren og innholdsidentifikatoren for det aktuelle digitale innholdet 12.1 tillegg kan en slit post inneholde lisensdata vedrørende typen lisenser 16 som skal utstedes for det digitale innholdet 12 og betingelsene og forholdene for hver type lisens 16. Alternativt kan posten omfatte en peker, link eller referanse til et sted som har slik ytterligere informasjon.

Som nevnt ovenfor kan flere typer lisenser 16 være tilgjengelige. For eksempel, mot en relativt liten lisensavgift, kan en lisens 16 som tillater et begrenset antall gjengivelser være tilgjengelig. Mot en relativt sett større lisensavgift kan en lisens 16 som tillater ubegrenset gjengivelse inntil en utløpsdato være tilgjengelig. Mot en enda større lisensavgift kan en lisens 16 som tillater ubegrenset gjengivelse uten en utløpsdato være tilgjengelig. Praktisk talt hvilken som helst type lisens 16 som har hvilke som helst typer lisensbetingelser kan bli generert og utstedt av lisenstjeneren 24 innenfor idéen bak og rammen til foreliggende oppfinnelse.

I én utførelsesform av foreliggende oppfinnelse gjøres forespørselen om en lisens 16 via en webside eller liknende som blir sendt fra lisenstjeneren 24 til brukerens beregningsanordning 14. Fortrinnsvis omfatteren slik webside innforma-sjon om alle typer lisenser 16 som er tilgjengelig fra lisenstjeneren 24 for det digitale innholdet 12 som er grunnlaget for forespørselen om lisensen 16.

I én utførelsesform av foreliggende oppfinnelse, før den utsteder en lisens 16, sjekker lisenstjeneren 24 versjonsnummeret til den sorte boksen 30 for å bestemme hvorvidt denne sorte boksen 30 er relativt ny (trinnene 709, 711). Som en må forstå, er den sorte boksen 30 ment å være sikker og beskyttet mot angrep fra en bruker med forbryterske hensikter (dvs. å gjengi det digitale innholdet 12 uten en lisens 16 eller utenfor betingelsene i en tilhørende lisens 16). En må imidlertid forstå at ingen systemer og ingen programvareanordning faktisk er full-stendig sikret mot et slikt angrep.

Som en også må forstå, dersom den sorte boksen 30 er relativt ny, dvs. er oppnådd eller oppdatert relativt nylig, er det mindre sannsynlig at denne sorte boksen 30 med hell har blitt korruptert av en bruker med forbryterske hensikter. Fortrinnsvis, og av klareringsgrunner, dersom lisenstjeneren 24 mottar en lisens-forespørsel med forespørselsinformasjon 36 omfattende et versjonsnummer for en sort boks 30 som ikke er relativt ny, nekter lisenstjeneren 24 å utstede den etterspurte lisensen 16 før den aktuelle sorte boksen 30 har blitt oppgradert til en gyldig versjon, som vil bli beskrevet nedenfor. Sagt på en enkel måte vil ikke lisenstjeneren 24 klarere en sort boks 30 dersom ikke denne sorte boksen 30 er relativt ny.

I forbindelse med den sorte boksen 30 ifølge foreliggende oppfinnelse, kan betegnelser som "oppdatert", "gyldig" eller "relativt ny" ha en hvilken som helst passende betydning innenfor idéen bak og rammen til foreliggende oppfinnelse som er konsistent med den funksjon å påliteligjøre eller klarere den sorte boksen 30 basert på alderen eller bruken av denne. For eksempel kan "gyldig" defineres i henhold til alder (f.eks. mindre enn én måned gammel). Som et alternativt eksempel kan "gyldig" defineres basert på antallet ganger den sorte boksen 30 har dekryptert digitalt innhold 12 (f.eks. mindre enn 200 tilfeller av dekryptering). Videre kan "gyldig" være basert på regler som settes av hver lisenstjener 24, idet én lisenstjener 24 kan definere "gyldig" forskjellig fra en annen lisenstjener 24, og en lisenstjener 24 videre kan definere "gyldig" forskjellig avhengig av det digitale innholdet 12 for hvilket det etterspørres en lisens 16 eller avhengig av typen lisens 16 som blir etterspurt, blant annet.

Antatt at lisenstjeneren 24 er overbevist fra versjonsnummeret til en sort boks 30 eller andre indisier i denne om at denne sorte boksen 30 er gyldig, fortsetter lisenstjeneren 24 da med å forhandle betingelser og omstendigheter for lisensen 16 med brukeren (trinn 713). Alternativt forhandler lisenstjeneren 24 lisensen 16 med brukeren og deretter overbeviser seg fra versjonsnummeret til den sorte boksen 30 om at den sorte boksen 30 er gyldig (dvs. utfører trinn 713 og deretter trinn 711). Selvfølgelig kan forhandlingens omfang variere avhengig av typen lisens 16 som skal utstedes og andre faktorer. For eksempel, dersom lisenstjeneren 24 bare utsteder en "paid-up", ubegrenset brukerlisens 16, er det lite som må forhandles. På den annen side, dersom lisensen 16 skal baseres på slike elementer som varierende verdier, glidende skalaer, gyldighetsdatoer og andre detaljer, kan slike elementer og detaljer måtte klareres mellom lisenstjeneren 24 og brukeren før lisensen 16 kan bli utstedt.

Som en må forstå, avhengig av omstendighetene, kan lisensforhandlingen kreve at brukeren sender ytterligere informasjon til lisenstjeneren 24 (for eksempel informasjon om brukeren, brukerens beregningsanordning 14, etc). Det er viktig at lisensforhandlingen også kan kreve at brukeren og lisenstjeneren 24 bestemmer et gjensidig akseptabelt betalingsmiddel (en kredittkonto, en debiter-ingskonto, en postet sjekk, etc.) og/eller betalingsmetode (betalt umiddelbart, for-delt over et tidsrom, etc), blant annet.

Når alle betingelsene for lisensen 16 er forhandlet og samtykket til av både lisenstjeneren 24 og brukeren (trinn 715), blir en digital lisens 16 generert av lisenstjeneren 24 (trinn 719), idet den genererte lisensen 16 i hvert fall delvis er basert på lisensforespørselen, den sorte boksen 30 sin fellesnøkkel (PU-BB) og dekrypteringsnøkkelen (KD) for det digitale innholdet 12 som er grunnlaget for forespørselen, som oppnådd fra innholdsnøkkel-databasen 20.1 én utførelses-form av foreliggende oppfinnelse, og som kan sees av figur 8, omfatter den genererte lisensen 16: - innholdsidentifikatoren for det digitale innholdet 12 for hvilket lisensen 16 gjelder; - en digital rettighetslisens (DRL) 48 (dvs. rettighetsbeskrivelsen eller de gjeldende betingelser og omstendigheter for lisensen 16 skrevet på en forbestemt form som lisensevaluatoren 36 kan lese), muligens kryptert med dekrypter-ingsnøkkelen (KD) (dvs. KD (DRL)); - dekrypteringsnøkkelen (KD) for det digitale innholdet 12 kryptert med den sorte boksen 30 sin fellesnøkkel (PU-BB) som mottatt i lisensforespørselen (dvs.(PU-BB (KD)); - en digital signatur fra lisenstjeneren 24 (uten et tilknyttet sertifikat) basert på (KD (DRL)) og (PU-BB (KD)) og kryptert med lisenstjeneren 24 sin private nøkkel (dvs. (S (PR-LS))); og - det sertifikatet som lisenstjeneren 24 har oppnådd tidligere fra innholdstjeneren 22, idet dette sertifikatet viser at lisenstjeneren 24 har autorisasjon fra innholdstjeneren 22 til å utstede lisensen 16 (dvs. (CERT (PU-LS) S (PR-CS))).

Som en må forstå blir de ovennevnte elementer og muligens andre pakket inn i en digital fil eller en annen hensiktsmessig form. Som en også må forstå, dersom DRL 48 eller (PU-BB (KD)) i lisensen 16 skulle bli forfalsket eller på annen måte modifisert, vil ikke den digitale signaturen (S (PR-LS)) i lisensen 16 overensstemme, og vil derfor ikke validere denne lisensen 16. Av denne grunn trenger ikke DRL 48 nødvendigvis å være på en kryptert form (dvs. (KD(DRL)) som nevnt ovenfor), selv om en slik kryptert form i noen tilfeller kan være ønskelig og derfor kan anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse.

Når den digitale lisensen 16 har blitt klargjort, blir denne lisensen 16 da levert til etterspørreren (dvs. DRM-systemet 32 på brukerens beregningsanordning 14) (trinn 719 i figur 7). Fortrinnsvis blir lisensen 16 sendt samme vei som forespørselen om denne ble gjort (dvs. Internett eller et annet nettverk), selv om en annen vei kan anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse. Ved mottak derav, plasserer det etterspørrende DRM-systemet 32 fortrinnsvis automatisk den mottatte digitale lisensen 16 i lisenslageret 38 (trinn 721).

En må forstå at en brukers beregningsanordning 14 til tider kan svikte, og lisenser 16 som er lagret i lisenslageret 38 i DRM-systemet 32 i denne brukerens beregningsanordning 14 kan være ugjenopprettelig tapt. Følgelig er det foretrukket at lisenstjeneren 24 opprettholder en database 50 av utstedte lisenser 16

(figur 1), og at denne lisenstjeneren 24 tilveiebringer en bruker med en kopi eller gjenutstedelse (nedenfor "gjenutstedelse") av en utstedt lisens 16 dersom brukeren faktisk har krav på en slik gjenutstedelse. I det ovennevnte tilfelle der lisensene 16 er ugjenopprettelig tapt, er det også sannsynligvis tilfelle at tilstandsinformasjon lagret i tilstandslageret 40 og svarende til lisensene 16 også har gått tapt. Slik tapt tilstandsinformasjon bør tas i betraktning ved gjenutstedelse av en lisens 16. For eksempel kan en lisens 16 for et fast antall rendringer legitimt bli gjenutstedt i en forholdsmessig form etter en relativt kort tidsperiode, og ikke gjenutstedes i det hele tatt etter en lengre tidsperiode.

DRM SYSTEM 32 - Installasjon/oppgradering av sort boks 30

Som beskrevet ovenfor, som del av den funksjon å akkvirere en lisens 16, kan lisenstjeneren 24 nekte en forespørsel om en lisens 16 fra en bruker dersom brukerens beregningsanordning 14 har et DRM-system 32 med en sort boks 30 som ikke er relativt ny, dvs. har et relativt gammelt versjonsnummer. I dette tilfell-let er det foretrukket at den sorte boksen 30 i dette DRM-systemet 32 blir oppgradert slik at lisensakkvireringsfunksjonen deretter kan fortsette. Selvfølgelig kan den sorte boksen 30 oppgraderes til andre tider innenfor idéen bak og rammen til foreliggende oppfinnelse.

Som del av prosessen med å installere DRM-systemet 32 i en brukers beregningsanordning 14, blir det fortrinnsvis tileiebragt en ikke-unik "lett" versjon av en sort boks 30. Denne "lette" sorte boksen 30 blir deretter oppgradert til en unik, vanlig versjon før gjengivelse av digitalt innhold 12. Som en må forstå, dersom hver sorte boks 30 i hvert DRM-system 32 er unik, kan ikke et sikkerhets-brudd i én sort boks 30 på en enkel måte bli reprodusert med en annen sort boks 30.

Nå med henvisning til figur 9, oppnår DRM-systemet 32 den unike sorte boksen 30 ved å be om denne fra en sort boks-tjener 26 eller liknende (som beskrevet ovenfor og som vist i figur 1) (trinn 901). En slik forespørsel blir typisk gjort via Internett, selv om andre aksessmetoder kan anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan forbindelsen til en sort boks-tjener 26 være en direkte forbindelse, enten lokalt eller fjernt. En oppgradering fra én unik, ordinær sort boks 30 til en annen unik, ordinær sort boks 30 kan også bli etterspurt av DRM-systemet 32 på et hvilket som helst tidspunkt, så som for eksempel et tidspunkt da en lisenstjener 24 avgjør at den sorte boksen 30 ikke er gyldig, som beskrevet ovenfor.

Deretter genererer sort boks-tjeneren 26 en ny unik sort boks 30 (trinn 903). Som kan sees i figur 3, blir hver nye sorte boks 30 tilveiebragt med et versjonsnummer og et sertifikat med en digital signatur fra en sertifiserende myndighet. Som beskrevet ovenfor i forbindelse med lisensakkvireringsfunksjonen, angir versjonsnummeret til den sorte boksen 30 den relative alderen og/eller anvendel-sen av denne. Sertifikatet med den digitale signaturen fra den sertifiserende myndigheten, også beskrevet ovenfor i forbindelse med lisensakkvireringsfunksjonen, er en tilbyder- eller attesteringsmekanisme fra den sertifiserende myndigheten som angir at en lisenstjener 24 skal klarere den sorte boksen 30. Selvføl- gelig må lisenstjeneren 24 stole på at den sertifiserende myndigheten utsteder et slikt sertifikat til en sort boks 30 som faktisk er klarert. Det kan forekomme at lisenstjeneren 24 faktisk ikke stoler på en gitt sertifiserende myndighet, og nekter å godta et sertifikat som er utstedt av denne sertifiserende myndigheten. Klareringen kan for eksempel underkjennes dersom en gitt sertifiserende myndighet finnes å delta i et mønster av ukorrekt utstedelse av sertifikater.

Fortrinnsvis, og som beskrevet ovenfor, inkluderer sort boks-tjeneren 26 et nytt unikt felles/privat-nøkkelpar (PU-BB, PR-BB) med den nygenererte, unike sorte boksen 30 (trinn 903 i figur 9). Fortrinnsvis er den private nøkkelen for den sorte boksen 30 (PR-BB) kun tilgjengelig for denne sorte boksen 30, og er skjult fra og utilgjengelig for alle andre, inklusive den beregningsanordningen 14 som har DRM-systemet 32 med denne sorte boksen 30 samt brukeren av denne.

Nesten et hvilket som helst tildekkingsskjema kan anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse, så lenge dette tildekkingsskjemaet faktisk utfører den funksjon å skjule den private nøkkelen (PR-BB) fra verden. Som kun ett eksempel, kan den private nøkkelen (PR-BB) bli delt inn i flere del-komponenter, og hver delkomponent kan bli unikt kryptert og lagret i et forskjellig område. I et slikt tilfelle er det foretrukket at disse delkomponentene aldri blir satt sammen i sin helhet for å produsere hele den private nøkkelen (PR-BB).

I én utførelsesform av foreliggende oppfinnelse blir denne private nøkkelen (PR-BB) kryptert i henhold til kodebaserte krypteringsteknikker. Spesielt, i en slik utførelsesform, blir den faktiske programkoden for den sorte boksen 30 (eller annen programkode) anvendt som krypteringsnøkkel/nøkler. Følgelig, dersom koden for den sorte boksen 30 (eller nevnte annen programkode) blir forfalsket eller på annen måte modifisert, for eksempel av en bruker med forbryterske hensikter, kan ikke den private nøkkelen (PR-BB) dekrypteres.

Selv om hver nye sorte boks 30 blir levert med et nytt felles/privat-nøkkel-par (PU-BB, PR-BB), gis en slik ny sort boks 30 også fortrinnsvis tilgang til gamle felles/privat-nøkkelpar fra gamle sorte bokser 30 som tidligere har blitt levert til DRM-systemet 32 i brukerens beregningsanordning 14 (trinn 905). Følgelig kan den oppgraderte sorte boksen 30 fortsatt anvende de gamle nøkkelparene for å aksessere gammelt digitalt innhold 12 og eldre tilhørende lisenser 16 som har blitt generert med slike gamle nøkkelpar, som vil bli beskrevet mer detaljert nedenfor.

Fortrinnsvis er den oppgraderte sorte boksen 30 som er levert av sort boks-tjeneren 26 tett bundet til eller assosiert med brukerens beregningsanordning 14. Følgelig kan ikke den oppgraderte sorte boksen 30 bli operativt overført mellom flere beregningsanordninger 14 for forbryterske formål eller annet. I én utførel-sesform av foreliggende oppfinnelse, som del av forespørselen om den sorte boksen 30 (trinn 901), tilveiebringer DRM-systemet 32 maskinvareinformasjon som er unik for dette DRM-systemet 32 og/eller unik for brukerens beregningsanordning 14 til sort boks-tjeneren 26, og sort boks-tjeneren 26 genererer en sort boks 30 for DRM-systemet 32 basert delvis på slik tilveiebragt maskinvareinnfor-masjon. Den genererte, oppgraderte sorte boksen 30 blir deretter levert til og installert i DRM-systemet 32 i brukerens beregningsanordning 14 (trinnene 907, 909). Dersom den oppgraderte sorte boksen 30 da på en eller annen måte blir overført til en annen beregningsanordning 14, detekterer den overførte sorte boksen 30 at den ikke er ment for denne andre beregningsanordningen 14, og tillater ingen etterspurt rendring å forløpe på denne andre beregningsanordningen 14.

Når den nye sorte boksen 30 er installert i DRM-systemet 32, kan dette DRM-systemet 32 fortsette med en lisensakkvireringsfunksjon eller med en hvilken som helst annen funksjon.

DRM-system 32 - rendring av innhold, del 3

Nå med henvisning til figur 5B, og med antagelsen om at lisensevaluatoren 36 har funnet minst én gyldig lisens 16 og at minst én av disse gyldige lisensene

16 gir brukeren de nødvendige rettigheter for å gjengi det motsvarende digitale innholdet 12 på den søkte måten (dvs. gir fullmakt), velger lisensevaluatoren 36 da én av disse lisensene 16 for videre anvendelse (trinn 519). Spesifikt, for å gjengi det etterspurte digitale innholdet 12, oppnår lisensevaluatoren 36 og den sorte boksen 30 i kombinasjon dekrypteringsnøkkelen (KD) fra denne lisensen 16, og den sorte boksen 30 anvender denne dekrypteringsnøkkelen (KD) for å dekryptere det digitale innholdet 12.1 én utførelsesform av foreliggende oppfin- neise, og som beskrevet ovenfor, er dekrypteringsnøkkelen (KD) som oppnådd fra lisensen 16 kryptert med den sorte boksen 30 sin fellesnøkkel (PU-BB(KD)), og den sorte boksen 30 dekrypterer denne krypterte dekrypteringsnøkkelen med sin private nøkkel (PR-BB) og for å generere dekrypteringsnøkkelen (KD) (trinnene 521, 523). Andre metoder for å oppnå dekrypteringsnøkkelen (KD) for det digitale innholdet 12 kan imidlertid anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse.

Når den sorte boksen 30 har dekrypteringsnøkkelen (KD) for det digitale innholdet 12 og tillatelse fra lisensevaluatoren 36 til å gjengi det digitale innholdet 12, kan kontrollen returneres til rendringsapplikasjonen 34 (trinnene 525, 527). I én utførelsesform av foreliggende oppfinnelse kaller rendringsapplikasjonen 34 da DRM-systemet 32 / den sorte boksen 30 og sender i hvert fall en del av det krypterte digitale innholdet 12 til den sorte boksen 30 for dekryptering i henhold til dekrypteringsnøkkelen (KD) (trinn 529). Den sorte boksen 30 dekrypterer det digitale innholdet 12 basert på dekrypteringsnøkkelen (KD) for det digitale innholdet 12, og deretter returnerer den sorte boksen 30 det dekrypterte digitale innholdet 12 til rendringsapplikasjonen 34 for faktisk rendring (trinnene 533, 535). Rendringsapplikasjonen 34 kan enten sende en del av det krypterte digitale innholdet 12 eller hele det digitale innholdet 12 til den sorte boksen 30 for dekryptering basert på dekrypteringsnøkkelen (KD) for dette digitale innholdet 12 innenfor idéen bak og rammen til foreliggende oppfinnelse.

Fortrinnsvis, når rendringsapplikasjonen 34 sender digitalt innhold 12 til den sorte boksen 30 for dekryptering, autentiserer den sorte boksen 30 og/eller DRM-systemet 32 denne rendringsapplikasjonen 34 for å sikre at dette faktisk er samme rendringsapplikasjon 34 som initielt forespurte DRM-systemet 32 om å kjøre (trinn 531). Ellers finnes det en mulighet for at godkjenning av gjengivelse kan oppnås på ulovlig vis ved å basere rendringsforespørselen på én type rendringsapplikasjon 34 og faktisk utføre rendringen med en annen type rendringsapplikasjon 34. Antatt at autentiseringen var vellykket og det digitale innholdet 12 har blitt dekryptert av den sorte boksen 30, kan rendringsapplikasjonen 34 da gjengi det dekrypterte digitale innholdet 12 (trinnene 533, 535).

Sekvens av nøkkeltransaksjoner

Nå med henvisning til figur 10, i én utførelsesform av foreliggende oppfinnelse, blir det utført en sekvens av nøkkeltransaksjoner for å oppnå dekrypter-ingsnøkkelen (KD) og evaluere en lisens 16 for etterspurt digitalt innhold 12 (dvs. for å utføre trinnene 515-523 i figurene 5A og 5B). I hovedsak, i en slik sekvens, oppnår DRM-systemet 32 dekrypteringsnøkkelen (KD) fra lisensen 16, anvender informasjon oppnådd fra lisensen 16 og det digitale innholdet 12 til å autentisere eller sikre gyldigheten til begge, og bestemmer deretter hvorvidt lisensen 16 faktisk gir rettighet til å gjengi det digitale innholdet 12 på den søkte måten. I så fall kan det digitale innholdet 12 gjengis.

Idet en husker på at hver lisens 16 for det digitale innholdet 12, som kan sees i figur 8, omfatter: - innholdsidentifikatoren for det digitale innholdet 12 for hvilket lisensen 16 gjelder; - den digitale rettighetslisensen (DRL) 48, eventuelt kryptert med dekrypter-ingsnøkkelen (KD) (dvs. KD (DRL)); - dekrypteringsnøkkelen (KD) for det digitale innholdet 12 kryptert med den sorte boksen 30 sin fellesnøkkel (PU-BB) (dvs.(PU-BB (KD)); - den digitale signaturen fra lisenstjeneren 24 basert på (KD (DRL)) og (PU-BB (KD)) og kryptert med lisenstjeneren 24 sin private nøkkel (dvs.

(S (PR-LS))); og

- det sertifikatet som lisenstjeneren 24 oppnådde tidligere fra innholdstjeneren 22 (dvs. (CERT (PU-LS) S (PR-CS))), og en også husker på at pakken 12p som inneholder det digitale innholdet 12, som kan sees i figur 3, omfatter: - innholdsidentifikatoren for dette digitale innholdet 12; - det digitale innholdet 12 kryptert med KD (dvs. (KD(CONTENT)));

- et lisensakkvireringsskript som ikke er kryptert; og

- nøkkelen KD som krypterer innholdstjeneren 22 sin fellesnøkkel (PU-CS), signert av innholdstjeneren 22 sin private nøkkel (PR-CS) (dvs.

(KD (PU-CS) S (PR-CS))),

er, i én utførelsesform av foreliggende oppfinnelse, den spesifikke sekven-sen av nøkkeltransaksjoner som utføres med hensyn til en spesifikk av lisensene 16 for det digitale innholdet 12 som følger: 1. Basert på (PU-BB (KD)) fra lisensen 16, anvender den sorte boksen 30 i DRM-systemet 32 i brukerens beregningsanordning 14 sin private nøk-kel (PR-BB) for å oppnå (KD) (trinn 1001). (PR-BB (PU-BB (KD)) = (KD)). Merk, hvilket er viktig, at den sorte boksen 30 da vil kunne fortsette å anvende KD for å dekryptere det digitale innholdet 12 uten ytterligere omveier. Imidlertid, og også viktig, så stoler lisenstjeneren 24 på at den sorte boksen 30 ikke gjør dette. Denne tilliten ble etablert når lisenstjeneren 24 utstedte lisensen 16 basert på sertifikatet fra den sertifiserende myndigheten som attesterte for klareringen av denne sorte boksen 30. Følgelig, til tross for at den sorte boksen 30 oppnår dekrypteringsnøkkelen (KD) som et innledende trinn heller enn et endelig trinn, fortsetter DRM-systemet 32 å utføre alle validerings- og evalueringsfunksjoner på lisensen 16, som beskrevet nedenfor. 2. Basert på (KD (PU-CS) S (PR-CS)) fra det digitale innholdet 12, anvender den sorte boksen 30 den nyoppnådde dekrypteringsnøkkelen (KD) for å oppnå (PU-CS) (trinn 1003). (KD (KD (PU-CS)) = (PU-CS)). I tillegg kan den sorte boksen 30 anvende (PU-CS) som mot signaturen (S (PR-CS)) for å overbevise seg om at denne signaturen og dette digitale innholdet 12 / denne pakken 12p er gyldig (trinn 1005). Dersom de ikke er gyldige, blir prosessen avbrutt og aksess til det digitale innholdet 12 blir nektet. 3. Basert på (CERT (PU-LS) S (PR-CS)) fra lisensen 16, anvender den sorte boksen 30 den nyoppnådde fellesnøkkelen (PU-CS) til innholdstjeneren 22 for å overbevise seg om at sertifikatet er gyldig (trinn 1007), hvilket betyr at den lisenstjeneren 24 som utstedte lisensen 16 hadde autorisasjon fra innholdstjeneren 22 til å gjøre dette, og eksaminerer deretter sertifikatets innhold for å oppnå (PU-LS) (trinn 1009). Dersom det ikke er gyldig, blir prosessen avbrutt og aksess til det digitale innholdet 12 basert på lisensen 16 blir nektet. 4. Basert på (S (PR-LS)) fra lisensen 16, anvender den sorte boksen 30 den nyoppnådde fellesnøkkelen (PU-LS) til lisenstjeneren 24 for å overbevise seg om at lisensen 16 er gyldig (trinn 1011). Dersom den ikke er gyldig, blir pro sessen avbrutt og aksess til det digitale innholdet 12 basert på lisensen 16 blir nektet. 5. Antatt at alle valideringstrinn blir godkjent, og at DRL 48 i lisensen 16 faktisk er kryptert med dekrypteringsnøkkelen (KD), anvender lisensevaluatoren 36 da den allerede oppnådde dekrypteringsnøkkelen (KD) på (KD(DRL)) som oppnådd fra lisensen 16 for å oppnå lisensenbetingelsene fra lisensen 16 (dvs. DRL 48) (trinn 1013). Dersom DRL 48 i lisensen 16 ikke er kryptert med de-krypteringsnøkkelen (KD), kan selvfølgelig trinn 1013 utelates. Lisensevaluatoren 36 evaluerer/sjekker deretter DRL 48 og avgjør hvorvidt brukerens beregningsanordning 14 har rettighet basert på DRL 48 i lisensen 16 til å gjengi det motsvarende digitale innholdet 12 på den søkte måten (dvs. hvorvidt DRL 48 gir fullmakt) (trinn 1015). Dersom lisensevaluatoren 36 avgjør at en slik rettighet ikke eksisterer, blir prosessen avbrutt og aksess til det digitale innholdet 12 basert på lisensen 16 blir nektet. 6. Endelig, antatt at evalueringen av lisensen 16 resulterer i en positiv bestemmelse av at brukerens beregningsanordning 14 har rettighet basert på betingelsene i DRL 48 til å gjengi det motsvarende digitale innholdet 12 på den søkte måten, informerer lisensevaluatoren 36 den sorte boksen 30 om at den kan gjengi det motsvarende digitale innholdet 12 med dekrypteringsnøkkelen (KD). Den sorte boksen 30 anvender deretter dekrypteringsnøkkelen (KD) til å dekryptere det digitale innholdet 12 fra pakken 12p (dvs. (KD(KD(CONTENT)) =

(CONTENT)) (trinn 1017).

Det er viktig å merke seg at den ovenfor spesifiserte serien av trinn representerer en alternering eller "ping-ponging" mellom lisensen 16 og det digitale innholdet 12. Slik alternering sikrer at det digitale innholdet 12 er tett bundet til lisensen 16, i det at validerings- og evalueringsprosessen bare kan gjennomfø-res dersom både det digitale innholdet 12 og lisensen 16 foreligger i en korrekt utstedt og gyldig form. I tillegg, ettersom samme dekrypteringsnøkkel (KD) er nødvendig for å oppnå innholdstjeneren 22 sin fellesnøkkel (PU-CS) fra lisensen 16 og det digitale innholdet 12 fra pakken 12p i en dekryptert form (og eventuelt lisensbetingelsene (DRL 48) fra lisensen 16 i en dekryptert form), er disse elementene også tett bundet. Signaturvalidering sikrer også at det digitale innholdet 12 og lisensen 16 er i samme tilstand som utstedt henholdsvis fra innholdstjeneren 22 og lisenstjeneren 24. Følgelig er det vanskelig, om ikke umulig, å dekryptere det digitale innholdet 12 ved å omgå lisenstjeneren 24, og også vanskelig om ikke umulig å endre og deretter dekryptere det digitale innholdet 12 eller lisensen 16.

I én utførelsesform av foreliggende oppfinnelse blir signaturverifisering, og

spesielt signaturverifisering av lisensen 16, utført alternerende som følger. Heller enn å ha en signatur kryptert med den private nøkkelen til lisenstjeneren 16 (PR-LS), som kan sees i figur 8, har hver lisens 16 en signatur kryptert med en privat rotnøkkel (PR-R) (ikke vist), idet den sorte boksen 30 i hvert DRM-system 32 omfatter en felles rotnøkkel (PU-R) (heller ikke vist) som svarer til den private rot-nøkkelen (PR-R). Den private rotnøkkelen (PR-R) er kun kjent for en rot-entitet, og en lisenstjener 24 kan bare utstede lisenser 16 dersom denne lisenstjeneren 24 har tillatelse fra rot-entiteteten til å utstede lisenser 16.

Spesielt, i en slik utførelsesform:

1. tilveiebringer lisenstjeneren 24 sin fellesnøkkel (PU-LS) til rot-entiteten; 2. returnerer rot-entiteten lisenstjenerens fellesnøkkel (PU-LS) til denne lisenstjeneren 24 kryptert med den private rotnøkkelen (PR-R) (dvs.

(CERT (PU-LS) S (PR-R))); og

3. utsteder lisenstjeneren 24 da en lisens 16 med en signatur kryptert med lisenstjenerens private nøkkel (S (PR-LS)), og vedlegger også til lisensen sertifikatet fra rot-entiteten (CERT (PU-LS) S (PR-R)).

For at et DRM-system 18 skal kunne validere en slik utstedt lisens 16, ut-fører da DRM-systemet 18 de trinn å: 1. anvende den felles rotnøkkelen (PU-R) på det vedlagte sertifikatet (CERT (PU-LS) S (PR-R)) for å oppnå lisenstjenerens fellesnøkkel (PU-LS); og 2. anvende den oppnådde lisenstjener-fellesnøkkelen (PU-LS) på signaturen for lisensen 16 (S (PR-LS).

Det er viktig å forstå at akkurat som rot-entiteten ga lisenstjeneren 24 tillatelse til å utstede lisenser 16 ved å tilveiebringe sertifikatet

(CERT (PU-LS) S (PR-R)) til denne lisenstjeneren 24, kan denne lisenstjeneren 24 tilveiebringe et tilsvarende sertifikat til en andre lisenstjener 24 (dvs.

(CERT (PU-LS2) S (PR-LS1)), og med det gjøre at den andre lisenstjeneren også kan utstede lisenser 16. Som nå skulle være åpenbart, vil en lisens 16 som er utstedt av den andre lisenstjeneren omfatte et første sertifikat (CERT (PU-LS1) S (PR-R)) og et andre sertifikat (CERT (PU-LS2) S (PR-LS1)). Tilsvarende blir denne lisensen 16 validert ved å følge kjeden gjennom det første og det andre sertifikatet. Selvfølgelig kan det legges til og følges ytterligere ledd i kjeden.

Én fordel ved den ovennevnte signaturverifiseringsprosessen er at rot-entiteten regelmessig kan endre den private rotnøkkelen (PR-R), og med det således regelmessig kreve at hver lisenstjener 24 oppnår et nytt sertifikat (CERT (PU-LS) S (PR-R)). Viktig, som et krav for å oppnå et slikt nytt sertifikat, kan hver lisenstjener måtte oppgradere seg. Som med den sorte boksen 30, dersom en lisenstjener 24 er relativt ny, dvs. har blitt oppgradert relativt nylig, er det mindre sannsynlig at lisenstjeneren 24 har blitt utsatt for et vellykket angrep. Følgelig, som en klareringssak, må hver lisenstjener 24 fortrinnsvis oppgraderes regelmessig via en egnet oppgraderings-triggermekanisme, så som signaturverifiseringsprosessen. Naturligvis kan andre oppgraderingsmekanismer anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse.

Selvfølgelig, dersom den private rotnøkkelen (PR-R) blir endret, må da felles-rotnøkkelen (PU-R) i hvert DRM-system 18 også endres. En slik endring kan for eksempel finne sted under en normal sort boks 30 oppgradering, eller kan faktisk kreve at en sort boks 30 oppgradering blir utført. Selv om en endret felles rotnøkkel (PU-R) potensielt vil kunne forstyrre signaturvalideringen for en eldre lisens 16 som er utstedt basert på en eldre privat rotnøkkel (PR-R), kan denne forstyrrelsen minimeres ved å kreve at en oppgradert sort boks 30 husker alle gamle felles-rotnøkler (PU-R). Alternativt kan denne forstyrrelsen minimeres ved å bare kreve signaturverifikasjon av en lisens 16 én gang, for eksempel den første gangen denne lisensen 16 blir evaluert av lisensevaluatoren 36 i et DRM-system 18.1 et slikt tilfelle må det tilveiebringes tilstandsinformasjon om hvorvidt signaturverifikasjon er gjennomført, og denne tilstandsinformasjon må lagres i tilstandslageret 40 i DRM-systemet 18.

Digital rettighetslisens 48

I én utførelsesform av foreliggende oppfinnelse evaluerer lisensevaluatoren 36 en digital rettighetslisens (DRL) 48 som rettighetsbeskrivelsen eller betingelsene for en lisens 16 for å bestemme om denne DRL 48 tillater gjengivelse av et motsvarende digitalt innhold 12 på den søkte måten. I én utførelsesform av foreliggende oppfinnelse kan DRL 48 være skrevet av en lisensgiver (dvs. innholdseieren) i et hvilket som helst DRL-språk.

Som en må forstå finnes det mange mulige måter å spesifisere en DRL 48. Følgelig må det tilveiebringes en høy grad av fleksibilitet i ethvert DRL-språk. Det er imidlertid upraktisk å spesifisere alle aspekter ved en DRL 48 i et spesifikt lisensspråk, og det er høyst usannsynlig at forfatteren av et slikt språk vil se alle mulige lisensieringsaspekter som en spesifikk digital lisensgiver måtte ønske. Dessuten kan et veldig sofistikert lisensspråk være unødvendig og til og med en hindring for en lisensgiver som tilveiebringer en relativt enkel DRL 48. Allikevel må ikke en lisensgiver være unnødig begrenset i hvordan en DRL 48 skal spesifiseres. Samtidig må lisensevaluatoren 36 alltid kunne oppnå svar fra en DRL 48 vedrørende et antall spesifikke lisensieringsspørsmål.

I foreliggende oppfinnelse, og nå med henvisning til figur 11, kan en DRL 48 være spesifisert i et hvilket som helst lisensspråk, men omfatter en språk-identifikator eller -definisjonsverdi 54. Den lisensevaluatoren 36 som evaluerer lisensen 16 utfører da det innledende trinn å lese språkdefinisjonsverdien 54 for å identifisere språket, og velger deretter en assosiert lisensspråkmotor 52 for å aksessere lisensen 16 i det identifiserte språket. Som en forstår må en slik lisensspråkmotor 52 foreligge og være tilgjengelig for lisensevaluatoren 36. Dersom en slik ikke foreligger, omfatter språkdefinisjonsverdien 54 og/eller DRL 48 fortrinnsvis en lokasjon 56 (typisk et web-område) der en kan oppnå en slik språkmotor 52.

Språkmotoren 52 er typisk i form av en eksekverbar fil eller et sett av filer som befinner seg et minne i brukerens beregningsanordning 14, så som en harddisk. Språkmotoren 52 hjelper lisensevaluatoren 36 direkte med å sjekke DRL 48, lisensevaluatoren 36 sjekker DRL 48 indirekte via språkmotoren 48 som tjener som mellomstasjon, eller liknende. Når den eksekveres, kjører språkmotoren 52 i et arbeidrom i et minne i brukerens beregningsanordning 14, så som RAM. En hvilken som helst annen form for språkmotor 52 kan imidlertid anvendes innenfor idéen bak og rammen til foreliggende oppfinnelse.

Fortrinnsvis støtter enhver språkmotor 52 og ethvert DRL-språk i hvert fall et antall spesifikke lisensieringsspørsmål som lisensevaluatoren 36 forventer at besvares av enhver DRL 48, som vil bli beskrevet nedenfor. Følgelig er ikke lisensevaluatoren 36 bundet til et spesifikt DRL-språk; en DRL 48 kan være skrevet i et hvilket som helst hensiktsmessig DRL-språk; og en DRL 48 som er spesifisert i et nytt lisensspråk kan anvendes av en eksisterende lisensevaluator 36 ved at denne lisensevaluatoren 36 oppnår en tilhørende ny språkmotor 52.

DRL-språk

To eksempler på DRL språk, som anvendt i respektive DRL-lisenser 48, er gitt nedenfor. Den første, "enkle" DRL-lisensen 48 er skrevet i et DRL-språk som spesifiserer lisensattributter, mens den andre, "skript" DRL-lisensen 48 er skrevet i et DRL-språk som kan utføre funksjoner i henhold til skriptet som er spesifisert i DRL-lisensen 48. Selv om de er skrevet i et DRL-språk, skulle betydningen av hver kodelinje være åpenbar basert på språknormene i denne og/eller på den etterfølgende attributt-beskrivelsestabellen:

Metoder

Som diskutert ovenfor, er det foretrukket at enhver språkmotor 52 og ethvert DRL-språk støtter i hvert fall et antall spesifikke lisensieringsspørsmål som den digitale lisensevaluatoren 36 forventer at besvares av enhver DRL 48. Idet en innser at slike støttede spørsmål kan omfatte hvilke som helst spørsmål innenfor idéen bak og rammen til foreliggende oppfinnelse, og i overensstemmelse med terminologien som ble anvendt i de to eksemplene på DRL-lisenser 48 ovenfor, omfatter, i én utførelsesform av foreliggende oppfinnelse, slike støttede spørsmål eller "metoder" "aksessmetoder", "DRL-metoder" og "bruksgyldighetsmetoder", som følger:

Aksessmetoder

Aksessmetoder anvendes for å forespørre en DRL 48 om toppnivå-attributer.

VARIANT QueryAttribute (BSTR nøkkel)

Gyldige nøkler omfatter Licence.Name, Licence.ld, Content.Name, Content.ld, Content.Type, Owner.Name, Owner.ld, Owner.PublicKey, Licencee.Name, Licencee.ld, Licencee.PublicKey, Description og Terms, som alle returnerer en BSTR variant; og Issued, Validity.Start og Validity.End, som alle returnerer en Date Variant.

DRL-metoder

Implementasjonen av de følgende DRL-metoder varierer fra DRL 48 til DRL 48. Mange av DRL-metodene omfatter en variant-parameter merket "data", som er ment for å kommunisere mer avansert informasjon med en DRL 48. Denne er for tiden hovedsaklig for fremtidige utvidelsesmuligheter.

Boolean lsActivated(Variant data)

Denne metoden returnerer en Boolean som angir hvorvidt DRL 48 / lisens 16 er aktivert. Et eksempel på en aktivert lisens 16 er en begrenset lisens 16 som etter første avspilling kun er aktiv i 48 timer.

Activate(Variant data)

Denne metoden blir anvendt for å aktivere en lisens 16. Når en lisens 16 er aktivert, kan den ikke bli deaktivert.

Variant QueryDRL(Variant data)

Denne metoden blir anvendt for å kommunisere med en mer avansert DRL 48. Den er hovedsaklig for fremtidig utvidelse av DRL 48 funksjonaliteten.

Variant GetExpires(BSTR action, Variant data)

Denne metoden returnerer utløpsdatoen for en lisens 16 med hensyn til den innsendte action-parameteren. Dersom returverdien er NULL, antas at lisensen 16 aldri utløper eller at den foreløpig ikke har fått en utløpsdato fordi den ikke har blitt aktivert, eller liknende.

Variant GetCount(BSTR action, Variant data)

Denne metoden returnerer antallet operasjoner som er igjen for den innsendte action-parameteren. Dersom NULL blir returnert, kan operasjonen utføres et ubgrenset antall ganger.

Boolean lsEnabled(BSTR action, Variant data)

Denne metoden angir hvorvidt lisensen 16 berettiger den etterspurte handlingen assosiert med action-parameteren på det aktuelle tidspunkt.

Boolean lsSunk(BSTR action, Variant data)

Denne metoden angir hvorvidt lisensen 16 har blitt betalt. En lisens 16 som er betalt på forhånd vil returnere TRUE, mens en lisens 16 som ikke er betalt på forhånd, så som en lisens 16 som innkrever betaling når den anvendes, vil returnere FALSE.

Bruksgyldighetsmetoder

Disse metodene blir anvendt for å gyldiggjøre en lisens 16 for anvendelse for å dekryptere innhold.

Boolean Validate (BSTR nøkkel)

Denne metoden blir anvendt for å validere en lisens 16. Den innsendte nøkkel-parameteren er den sorte boksen 30 sin fellesnøkkel (PU-BB) kryptert med dekrypteringsnøkkelen (KD) for det motsvarende digitale innholdet 12 (dvs.

(KD(PU-BB))) for anvendelse til å validere signaturen til lisensen 16. Returverdien TRUE angir at lisensen 16 er gyldig. Returverdien FALSE angir ugyldig.

int OpenLicence 16(BSTR action, BSTR nøkkel, Variant data)

Denne metoden blir anvendt for å klargjøre for å aksessere de dekrypterte gyldighetsgjørende bit. Den innsendte nøkkel-parameteren er (KD(PU-BB)) som beskrevet ovenfor. Returverdien 0 angir suksess. Andre returverdier kan defineres.

BSTR GetDecryptedEnablingBits (BSTR action, Variant data)

Variant GetDecryptedEnablingBitsAsBinary (BSTR action, Variant Data)

Disse metodene blir anvendt for å aksessere de gyldiggjørende bits i dekryptert form. Dersom dette ikke er mulig av en blant flere mulige årsaker, blir en nullstreng eller null-variant returnert.

void CloseLicence (BSTR action, Variant data)

Denne metoden blir anvendt for å frigi aksess til de gyldiggjørende bits for å utføre handlingen assosiert med den innsendte action-parameteren. Dersom dette ikke er mulig av en blant flere mulige årsaker, blir en nullstreng returnert.

Heuristikk

Som beskrevet ovenfor, dersom det foreligger flere lisenser 16 for samme digitale innhold 12, må én av lisensene 16 velges for videre bruk. Ved anvendelse av metodene beskrevet ovenfor, kan følgende heuristikk bli implementert for å foreta et slikt valg. Spesielt, for å utføre en handling (f.eks "AVSPILLE") på et stykke digitalt innhold 12, kan følgende trinn bli utført: 1. Oppnå alle lisenser 16 som gjelder for det aktuelle digitale innholdet 12. 2. Eliminere hver lisens 16 som ikke tillater handlingen ved å kalle IsEnabled-funksjonen for denne lisensen 16. 3. Eliminere hver lisens 16 som ikke er aktiv ved å kalle IsActivated for denne lisensen 16. 4. Eliminere hver lisens 16 som ikke er betalt på forhånd ved å kalle IsSunk for denne lisensen 16. 5. Dersom det er igjen en lisens 16, anvende den. Anvende en ubegrenset-antall-avspillinger lisens 16 før en begrenset-antall-avspillinger lisens 16, spesielt dersom ubegrenset-antall-avspillinger lisensen 16 har en utløpsdato. Til enhver tid må brukeren kunne velge en spesifikk lisens 16 som allerede har blitt oppnådd selv om dette valget ikke er kostnadseffektivt. Følgelig kan brukeren velge en lisens 16 basert på kriterier som kanskje ikke er åpenbare for DRM-systemet 32. 6. Dersom det ikke er noen lisenser 16 igjen, angis dette av retursta-tusen. Brukeren vil deretter bli mulighet for å: anvende en lisens 16 som ikke er betalt på forhånd, hvis tilgjengelig;

aktivere en lisens 16, hvis tilgjengelig; og/eller

utføre lisensakkvirering fra en lisenstjener 24.

FORENKLET DEKRYPTERING FOR EN RELATIVT ENKEL ANORDNING

Som en må forstå er den DRM-arkitekturen 10 som har blitt beskrevet ovenfor en teknologi for å beskytte digitalt innhold 12 ved blant annet å tvinge en brukers beregningsanordning 14 til å autentisere seg som en legitim DRM-komponent i arkitekturen før den mottar en lisens 16 for å gjengi innholdet 12. Denne autentiseringen omfatter en interaktiv prosess som inkluderer signerte sertifikater, forhandlinger, utvekslinger av asymmetriske og symmetriske nøkler og liknende, der den interaktive prosessen utføres over en nettverksforbindelse eller liknende mellom beregningsanordningen 14 og en fjernlokalisert entitet, så som en lisenstjener 24.

En skal imidlertid være klar over at i noen tilfeller, den anordningen på hvilken innholdet 12 skal gjengis er relativt liten og/eller enkel og ikke innehar relativt komplekse muligheter så som det å utføre asymmetrisk nøkkel dekryptering og kommunisere med en fjernlokalisert entitet over en nettverksforbindelse eller liknende i den interaktive prosessen beskrevet ovenfor. Istedet kan en slik relativt liten og/eller enkel anordning typisk motta innhold 12 og liknende på et lagringsmedium eller laste ned slikt innhold 12 og liknende fra en vertsdatamaskin til et internt minne. Følgelig eksisterer det et behov for en mekanisme og fremgangsmåte som utvider DRM-arkitekturen 10 til en slik relativt liten og/eller enkel anordning, der anordningen ikke trenger å utføre asymmetrisk nøkkel dekryptering og ikke krever web- eller nettverks-tilkopling.

Kort fortalt, i foreliggende oppfinnelse, blir en slik anordning forhåndsautori-sert ved at den tilveiebringes med en anordningsnøkkel (DK) og en form for et DRM-system, og autorisasjonen blir bekreftet gjennom en tabell, idet DRM-systemet anvender (DK) for å eksponere en hemmelighet så som et passord eller en ytterligere dekrypteringsnøkkel. Tabellen kan bli levert sammen med innholdet 12 på et forhåndslagret media så som en magnetisk eller optisk datadisk eller et datakort, eller i en kringkasting eller annen massepublikasjon av innholdet direkte til et minne i anordningen. Anordningen er autorisert for å anvende innholdet 12 i kraft av å inneha (DK) og DRM-systemet, som tilveiebringer aksess til

tabellen.

Nå med henvisning til figur 13, kan det sees at med én måte å oppnå og gjengi digitalt innhold 12, blir dette digitale innholdet 12 lastet ned fra en kilde 60 og plassert i et lagringsmedium 61 som enten blir montert til en relativt liten og/eller enkel anordning 62 eller som er en intern del av en slik anordning 62. Kilden 60 kan være en hvilken som helst passende kilde innenfor idéen bak og rammen til foreliggende oppfinnelse, idet en husker på at det må finnes en egnet forbindelse mellom kilden 60 og lagringsmediet 61. Tilsvarende kan lagringsmediet 61 også være et hvilket som helst egnet medium innenfor idéen bak og rammen til foreliggende oppfinnelse.

For eksempel kan kilden 60 være en vertsdatamaskin, en fjernlokalisert tjener eller en kombinasjon av slike, med innholdet 12 i denne eller tilgjengelig gjennom denne. Tilsvarende kan lagringsmediet 61 være flyttbart, så som en optisk disk, en magnetdisk, et mediakort eller liknende, eller kan være et internt minne i anordningen 62. I førstnevnte tilfelle kan det for eksempel være slik at innholdet 12 og assosierte data blir lastet ned fra kilden 60 ved en kiosk, muligens ved et detaljutsalg. I det sistnevnte tilfellet kan det for eksempel være slik at anordningen 62 blir koblet til en kilde 60, så som for eksempel en vertsdatamaskin, og innholdet 12 og assosierte data blir lastet ned direkte til denne.

I én utførelsesform av foreliggende oppfinnelse, når innholdet 12 lastes ned til mediet 61, blir en tilhørende digital lisens 16 også oppnådd og lastet ned eller på annen måte plassert i mediet 61. Lisensen 16 kan være en lisens som er oppnådd for mediet 61, eller kan være en under-lisens 16s som er avledet fra en lis ens 16 som er oppnådd for en annen beregningsanordning 14, så som for eksempel en vertsdatamaskin. En fremgangsmåte for å avlede en under-lisens 16s fra en lisens 16 er beskrevet i U.S.-patentsøknaden 09/892,371, innlevert 27. juni 2001, som med dette innlemmes ved referanse her i sin helhet. Alternativt kan det oppnådde innholdet 12 omfatte den oppnådde lisensen 16 deri.

Anordningen 62 har typisk en relativt liten minneplass reservert for avspil-lingsoperasjoner så som å dekryptere innhold, gjengi innhold og liknende. Med en relativt liten minneplass vil anordningen 62 mest sannsynlig ikke kunne utføre asymmetrisk (dvs. fellesnøkkel - privat nøkkel) dekryptering. Følgelig, i én utfør-elsesform av foreliggende oppfinnelse, utfører anordningen 62 symmetrisk dekryptering bare ved hjelp av et flyttbart DRM-system 32p (figur 13) instansiert i et minne i dette.

I én utførelsesform av foreliggende oppfinnelse, og som med temaet beskrevet i den ovennevnte U.S.-patentsøknaden 09/892,371, blir all innhenting av digitalt innhold 12 og tilhørende digitale lisenser 16 eller under-lisenser 16s for mediet 61 utført ved hjelp av en vertsdatamaskin eller liknende, så som for eksempel en privat PC eller en datamaskin i en kiosk i en forhandlerlokasjon. Spesielt oppnår vertsdatamaskinen en lisens 16 for tilhørende digitalt innhold 16, og utsteder da (om nødvendig) en under-lisens 16s til mediet 61 for å gjengi det digitale innholdet 12 på anordningen 62. En slik under-lisens 16s kan bli utstedt under nedlastingen av det digitale innholdet 12 fra kilden 60 til mediet 61, eller kan bli utstedt på et tidspunkt før eller etter nedlasting av det digitale innholdet 12 fra kilden 60 til mediet 61, eller ved et annet tidspunkt, alt innenfor idéen bak og rammen til foreliggende oppfinnelse.

Som en forstår, dersom det blir utstedt en under-lisens 16s, kan denne utstedte under-lisensen 16s spesifisere begrensningene, om noen, som må være tilfredsstilt for å gjengi det motsvarende innholdet 12 på mediet 61 i anordningen 62. Selvfølgelig kan en slik under-lisens 16s kun bli utstedt dersom det er tillatt i henhold til betingelsene i den tilhørende lisensen 16 som er oppnådd fra en tilgjengelig lisenstjener 24. Når under-lisensen 16s utstedes, blir i hvert fall en del av denne omskrevet til en form som er mer hensiktsmessig for anordningen 62. Spesielt rekrypterer datamaskinen 60 innholdsnøkkelen (KD) for å dekryptere innholdet 12 til en form som er mer egnet for dekryptering av anordningen 62. Her, og i én utførelsesform av foreliggende oppfinnelse, blir innholdsnøkkelen re kryptert med en symmetrisk nøkkel som lagres i en tabell 64 i mediet 61, idet den symmetriske nøkkelen er kryptert med en anordningsnøkkel (DK) for anordningen 62.

Spesielt, og antatt at innholdsnøkkelen (KD) i lisensen 16 i datamaskinen 60 er kryptert med en asymmetrisk nøkkel, så som fellesnøkkelen til den sorte boksen i vertsdatamaskinen (PU-BB-HC), på den måten som er beskrevet ovenfor, oppnår vertsdatamaskinen innholdsnøkkelen (KD) ved å anvende den private nøkkelen til den sorte boksen i vertsdatamaskinen (PR-BB-HC) på den måten som er beskrevet ovenfor, og rekrypterer deretter innholdsnøkkelen (KD) med den symmetriske nøkkelen (DK) til i hvert fall anordningen 62. Derfor, og som en må forstå, kan innholdsnøkkelen (KD) oppnås av anordningen 62 på det ønskede tidspunktet ved anvendelse av (DK) og under-lisensen 16s. Som en må forstå, uten å rekryptere innholdsnøkkelen (KD), vil ikke anordningen 62, som ikke ville kjenne (PR-BB-HC), være i stand til å dekryptere (PU-BB-HC(KD)) for å oppnå (KD).

Prosedyrer for å generere under-lisensen 16s er beskrevet mer detaljert i ovennevnte U.S.-patentsøknad 09/892,371, og trenger derfor ikke beskrives her i detalj. Hvilke som helst variasjoner av slike prosedyrer som er nødvendig i lys av foreliggende oppfinnelse skulle være åpenbart for fagmannen basert på U.S.-patentsøknaden 09/892,371.

Fortsatt med henvisning til figur 13, for å laste ned det digitale innholdet 12 og den tilhørende lisensen 16 eller under-lisensen 16s til mediet 61, må dette mediet 61 være koblet til kilden 60 ved hjelp av en forbindelse 63 som kan være en hvilken som helst passende forbindelse innenfor idéen bak og rammen til foreliggende oppfinnelse. Som en må forstå, dersom mediet 61 er en eller annen form for flyttbar, skrivbar lagringsenhet, er forbindelsen 63 en passende stasjon i hvilken mediet 61 er anbragt. Likeledes, dersom mediet 61 er internt i anordningen 62, kan forbindelsen 63 være en passende kabel, en trådløs link så som en RF- eller IR-link eller liknende. Slike forbindelser 63 og maskinvare og/eller programvare som støtter denne er kjent eller vil være åpenbare for fagmannen, og trenger derfor ikke beskrives i ytterligere detalj her.

Anordningen 62 kan ansees som spesielt pålitelig basert på dens enkelhet. Nærmere bestemt kan den enkle anordningen 62 ha begrenset funksjonalitet og aksesserbarhet, og derfor være spesielt usårbar for angrep av en innholdstyv eller et annet forbrytersk individ. Følgelig, og i et slikt tilfelle, er ikke under-lisensen 16s strengt tatt nødvendig. Istedet kan innholdet 12 plasseres i mediet 61 kryptert med en symmetrisk nøkkel som er tilgjengelig for anordningen 62 ved hjelp av tabellen 64, og anordningen 62 kan gjengi det krypterte innholdet 12 etter ønske ved hjelp av den symmetriske nøkkelen i tabellen 64. Selvfølgelig, for å gjøre dette, må innholdet 12 som oppnådd fra vertsdatamaskinen 60 mest sannsynlig dekrypteres og deretter rekrypteres med den symmetriske nøkkelen på en tilsvarende måte som den beskrevet ovenfor. Detaljer og fremgangsmåter for å gjøre dette skulle være åpenbare for fagmannen basert på foreliggende beskrivelse.

Alternativt kan innholdet 12 plasseres i mediet 61 i en unkryptert form, men kun aksesserbart for anordningen med et passord eller liknende som er tilgjengelig for anordningen 62 fra tabellen 64, og anordningen 62 kan gjengi det krypterte innholdet 12 etter ønske ved hjelp av passordet i tabellen 64. Her, også, må innholdet 12 som oppnådd av vertsdatamaskinen 60 mest sannsynlig dekrypteres og deretter passordbeskyttes. Detaljer og fremgangsmåter for å gjøre dette skulle være åpenbare for fagmannen.

Som angitt ovenfor er innholdsnøkkelen (KD), passordet for innholdet 12 eller liknende (nedenfor "hemmelighet") for å aksessere innholdet 12 i mediet 61 kryptert i hvertfall med anordningsnøkkelen (DK) til anordningen 62. En slik anordning 62 antas for formål ifølge foreliggende oppfinnelse ikke å være i stand til å kommunisere sin anordningsnøkkel (DK) til mediet 61 eller vertsdatamaskinen 60, selv om slik evne kan være tilveiebragt innenfor idéen bak og rammen til foreliggende oppfinnelse. Følgelig må den entiteten som krypterer innholdsnøk-kelen (KD) for innholdet 12 allerede være i besittelse av denne anordningsnøk-kelen (DK). Merk at det potensielt vli kunne finnes millioner av slike anordninger 62, hvis ikke flere, og hver anordning 62 vil kunne ha sin egen, antageligvis unike anordningsnøkkel (DK). Den ovennevnte krypterende entiteten kan mest sannsynlig ikke forventes å kjenne den unike anordningsnøkkelen (DK) for hver slik anordning 62.

I én utførelsesform av foreliggende oppfinnelse har derfor hver anordning 62 en ikke-unik anordningsnøkkel (DK), hvorved antallet anordningsnøkler (DK) som ovennevnte entitet må være i besittelse av holdes på et håndterbart nivå. Ikke desto mindre vil hver anordning 62 kunne ha sin egen unike anordningsnøk-kel (DK) innenfor idéen bak og rammen til foreliggende oppfinnelse. Likevel, antatt at hver anordning 62 har en ikke-unik anordningsnøkkel (DK), kan det å distribuere de ikke-unike anordningsnøklene (DK) til anordninger 62 utføres på en hvilken som helst passende måte innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan hver produsent av en anordning 62 bli tilordnet en spesifikk anordningsnøkkel (DK), hvorpå alle anordninger 62 produsert av denne blir tilveiebragt med denne produsent-spesifikke (DK). Likeledes kan hver modell av en anordning 62 tilordnes en spesifikk (DK). Tilsvarende kan hver produsent eller modell av en anordning 62 tilordnes et antall anordningsnøkler (DK) som enten blir tilfeldig eller deterministisk generert for spesifikke anordninger 62.

En vertsdatamaskin 60 som laster ned beskyttet innhold 12 (enten kryptert eller passordbeskyttet) til et medium 61 vet ikke nødvendigvis hva slags anordning 62 mediet 61 skal monteres til eller er en intern del av. Følgelig, og som kan sees av figur 13, i én utførelsesform av foreliggende oppfinnelse, laster vertsdatamaskinen 60 også ned tabellen 64, idet denne tabellen 64 inneholder hemmeligheten for innholdet 12 kryptert med hver av flere anordningsnøkler (DK) som er kjente. Som en ser har hver krypterte hemmelighet en tilhørende indeksverdi som spesifiserer en identifikator for den anordningsnøkkelen (DK) som krypterte hemmeligheten.

I én utførelsesform av foreliggende oppfinnelse inneholder derfor tabellen 64 hemmeligheten kryptert med anordningsnøkkelen (DK) til den anordningen 62 som skal anvendes for å gjengi det tilhørende innholdet 12. Merk at tabellen 64 kan inneholde hemmeligheten kryptert med hver anordningsnøkkel (DK) som er kjent for vertsdatamaskinen 60, eller for en spesifikk delmengde av disse, alt innenfor idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan en bruker som effektuerer en slik nedlasting spesifisere at anordningen 62 er produsert av en gitt produsent, og tabellen 64 omfatter således hemmeligheten kryptert med hver av anordningsnøklene (DK) for den produsenten. Likeledes kan brukeren spesifisere at anordningen 62 er en hvilken som helst blant et antall spesifikke anordninger 62, og tabellen 64 omfatter således hemmeligheten kryptert med anordningsnøkkelen (DK) for hver av disse spesifikke anordningene 62.

For å gjengi innholdet 12 i mediet 61, refererer da anordningen 62 til den

tabellen 64 i mediet 61 som svarer til innholdet 12, og indekserer seg til den hemmeligheten som er kryptert med anordningsnøkkelen (DK) for denne anordningen 62. Spesielt, og nå med henvisning til figur 14, oppnår anordningen 62, når den blir instruert om å gjengi innholdet 12 (trinn 1401), den tabellen 64 som svarer til dette (trinn 1403), oppnår anordningsnøkkelen (DK) for denne og indeksverdien til denne (DK) (trinn 1405), indekserer inn i tabellen 64 basert på den oppnådde indeksverdien (trinn 1407), og velger den motsvarende krypterte hemmeligheten (trinn 1409). Anordningen 62 anvender deretter den oppnådde anordningsnøkkelen (DK) på den krypterte hemmeligheten for å eksponere hemmeligheten (trinn 1411), og anvender den eksponerte hemmeligheten til å gjengi det motsvarende innholdet 12 (trinn 1413). Merk at hemmeligheten direkte kan

muliggjøre gjengivelse av innholdet 12, for eksempel dersom hemmeligheten kan anvendes for å dekryptere innholdet 12 eller hemmeligheten kan anvendes på en lisens 16 eller under-lisens 16s for å muliggjøre gjengivelse av innholdet 12.

I én utførelsesform av foreliggende oppfinnelse, er tabellen 64 i mediet 61 en felles tabell 64 som representerer flere forskjellige innhold 12 i mediet 61, idet hvert av de forskjellige innholdene 12 er beskyttet med én enkelt, felles hemmelighet. Følgelig, for å gjengi et hvilket som helst av innholdene 12 i mediet 61, trenger en anordning bare å referere til den felles tabellen 64 for å oppnå den fellles hemmeligheten. Hovedsakelig samme fremgangsmåte som vist i figur 14 kan derfor anvendes.

Som beskrevet ovenfor, kan tabellen 64 som er generert av vertsdatamaskinen 60 omfatte hemmeligheten kryptert med alle anordningsnøkler (DK) som er kjent for vertsdatamaskinen 60 eller med en spesifikk delmengde av disse. I sistnevnte tilfelle hindrer det å ekskludere en anordningsnøkkel (DK) fra del-mengden i tabellen 64 en motsvarende anordning 62 i å gjengi det tilhørende innholdet 12.1 førstnevnte tilfelle blir en motsvarende anordning 62 tilsvarende hindret i å gjengi innholdet 12 ved å etterlate feltet i tabellen 64 for den motsvarende krypterte hemmeligheten blankt. Alternativt kan et slikt felt fylles med hvilke som helst alternative data, så som forbestemte eller meningsløse data.

I én utførelsesform av foreliggende oppfinnelse er hver anordning 62 tilveiebragt med flere enn én anordningsnøkkel (DK). Følgelig førsøker anordningen 62 å anvende hver (DK) i tabellen 64 inntil den finner en som eksponerer den hemmeligheten som er nødvendig for å gjengi innholdet 12.1 en slik utførelsesform, dersom det finnes nødvendig å ugyldiggjøre anordningen 62 (f.eks. som ikke-pålitelig), må vertsdatamaskinen utelate fra tabellen 64 de elementene som svarer til alle anordningsnøklene (DK) for anordningen 62.1 et slikt tilfelle vil en ugyldiggjort anordning 62 med anordningsnøkler A, B, C og D resultere i "kansellering" av disse anordningsnøklene A, B, C og D fra tabellen 64. Merk at i et slikt tilfelle, en anordning 62 med anordningsnøkler B, C, D og E fortsatt vil kunne aksessere fra tabellen 64 den hemmeligheten som er indeksert under anordningsnøkkel E, antatt at ikke anordningsnøkkel E også er kansellert, men ikke hemmeligheten som er indeksert under anordningsnøklene B, C eller D.

I én utførelsesform av foreliggende oppfinnelse, når vertsdatamaskinen 60 oppretter tabellen 64 som skal lastes ned til mediet 61 og beskytter innholdet 12 som skal lastes ned til mediet, så binder den tabellen 64 og innholdet 12 til mediet 61. Tabellen 64 og innholdet 12 kan således ikke fritt flyttes til andre medier 61. Her skjer bindingen av innholdet 12 ved at innholdet 12 må eksponeres ved hjelp av en endelig hemmelighet som er en kombinasjon av hemmeligheten som oppnådd fra tabellen 64 og en identifikator som identifiserer mediet 61. Identifikatoren for mediet 61 kan være en hvilken som helst passende identifikator uten å fjerne seg fra idéen bak og rammen til foreliggende oppfinnelse. For eksempel kan identifikatoren være et serienummer som er permanent assosiert med mediet 61. Den endelige hemmeligheten kan være et en-veis hash av hemmeligheten og identifikatoren, som for eksempel kan oppnås basert på en SHA- eller HMAC-algoritme. Følgelig kan ikke den endelige hemmeligheten dekomponeres til hemmeligheten på en enkel måte.

I én utførelsesform av foreliggende oppfinnelse blir tabellen 64 bundet til mediet 61 ved at identifikatoren for mediet 61 bygges inn på en sikker måte. Identifikatoren kan på en sikker måte bygges inn tabellen 64 ved at den blir anvendt som minst ett grunnlag for en signatur som er bundet til tabellen. Alternativt kan identifikatoren bli kryptert eller signert med hemmeligheten i tabellen 64.

Som en må forstå, blir identifikatoren for mediet 61 innhentet av vertsdatamaskinen 60 før den konstruerer tabellen 64 og genererer innholdet 12 for dette mediet 61, og tabellen 64 og innholdet 12 blir konstruert / generert av vertsdatamaskinen 60 på en slik måte at det er bundet til mediet 61. For å verifisere at tabellen 64 er assosiert med mediet 61, aksesserer da, og nå med henvisning til figur 15, anordningen 62 identifikatoren fra mediet 61 (trinn 1501), aksesserer identifikatoren fra tabellen 64 (trinn 1503), og sammenlikner de to identifikatorene for å bestemme hvorvidt de overensstemmer (trinn 1505). I så fall tillates rendringen å fortsette (trinn 1507). Merk at det å aksessere identifikatoren fra tabellen 64 i trinn 1503 kan omfatte det å verifisere signaturen til tabellen 64 for å bekrefte at den aksesserte identifikatoren ikke har blitt forfalsket (trinn 1503a), eller det å anvende den eksponerte hemmeligheten (trinn 1411 i figur 14) på den krypterte identifikatoren for å eksponere denne (trinn 1503b).

For å verifisere at innholdet 12 er assosiert med mediet 61, anvender anordningen 62 den eksponerte hemmeligheten og den verifiserte identifikatoren på hash-dataene for å generere den endelige hemmeligheten (trinn 1509). Denne verifiseringen skjer selvfølgelig dersom den endelige hemmeligheten tillater gjengivelse av innholdet 12 (trinn 1511). Merk at anordningen 62 kan forenkle det å verifisere identifikatoren ved bare å aksessere identifikatoren fra mediet (trinn 1501) og anvende den eksponerte hemmeligheten og den aksesserte identifikatoren på hash-dataene for å generere den endelige hemmeligheten (trinn 1509). Dersom den genererte endelige hemmeligheten ikke kan gjengi innholdet 12, kan anordningen 62 da verifisere tabellen 64 i et forsøk på å forklare hva som gikk galt.

Som beskrevet ovenfor kan en første signatur fra tabellen 64 basert på identifikatoren for mediet 61 anvendes for å verifisere identifikatoren assosisert med tabellen 64. Tilsvarende kan hele tabellen eller en del av denne være

grunnlaget for en andre signatur tilveiebragt av en autoriseringsmekanisme. Den andre signaturen er ikke nødvendig for anordningen 64 for å gjengi innholdet 12, men kan anvendes som en sikkerhetsforanstaltning for anordninger eller applika-sjoner som legger til nytt innhold 12 i et medium 61 med en eksisterende tabell 64. Spesielt verifiserer den andre signaturen at den eksisterende tabellen 64 er generert av autoriseringsmekanismen, og ikke av en forbrytersk entitet. Den andre signaturen bidrar også til å validere versjonsnummeret (se nedenfor) til

tabellen 64, og således hvor "fersk" tabellen 64 er.

En må forstå at detaljer i tabellen 64 i mediet 61 kan måtte oppdateres eller modifiseres fra tid til annen. For eksempel kan en anordning 62 bli ugyldiggjort, og tabellelementene med anordningsnøklene (DK) for denne kan måtte fjernes, og/eller nye elementer kan måtte legges til og/eller hemmeligheten i tabellen 64 kan måtte endres. Det oppstår spesielt vanskeligheter når mediet 61 kan oppdateres, men gammelt innhold 12 og muligheter samtidig må beholdes. Dette er tilfelle når en vertsdatamaskin 60 skriver nytt (beskyttet) innhold 12 til mediet 61 og gammelt (beskyttet) innhold allerede finnes i dette, spesielt dersom tabellen 64 er relativt gammel. I dette tilfellet, og i én utførelsesform av foreliggende oppfinnelse, blir den gamle tabellen 64 i mediet 61 som har en gammel hemmelighet erstattet med en ny, oppdatert tabell 64 som har en ny hemmelighet. Den nye tabellen 64 med den nye hemmeligheten støtter selvfølgelig det nye innholdet 12 i mediet 61 som er beskyttet med denne nye hemmeligheten. Det er viktig at den nye tabellen 64 også må støtte det gamle innholdet 12 i mediet 61, som er beskyttet med den gamle hemmeligheten. Alle anordninger 62, inklusive ugyldig-gjore anordninger 62, må beholde tilgangen til gammelt innhold 12.

Dette oppnås med en tabell 64, så som den vist i figur 16, der tabellen 64 selv og hvert element i tabellen 64 er tilveiebragt med et ikke-avtakende versjon-nummer i forhold til en master-tabell 68 som holdes av en administrator. Administratoren kan være en hvilken som helst hensiktsmessig entitet innenfor idéen bak og rammen til foreliggende oppfinnelse, og er prinsipielt ansvarlig for å opprettholde i master-tabellen 68 hver og én symmetrisk anordningsnøkkel (DK) som kan tenkes å skulle legges inn i en tabell 64.

I tillegg til hver anordningsnøkkel (DK), kan administratoren også opprettholde annen informasjon i master-tabellen 68, så som for eksempel en indeksverdi og et gyldig-flagg for hver anordningsnøkkel (DK). Som en forstår, avgjør administratoren når en anordningsnøkkel (DK) ikke lenger er pålitelig og derfor skal ugyldiggjøres, eller mottar en slik avgjørelse fra en annen entitet og følgelig merker gyldig-flagget for denne anordningsnøkkelen (DK). Selvfølgelig kan master-tabellen 68 inneholde annen informasjon innenfor idéen bak og rammen til foreliggende oppfinnelse. Spesielt inkluderer master-tabellen 68 også en ver-sjonsverdi, og hver gang administratoren endrer master-tabellen 68 blir versjonsverdien til denne inkrementert. Denne versjonsverdien kan være et versjonsnummer, en dato eller en annen økende verdi.

Hver gang en tabell(N) 64 i et medium 61 med hemmelighet(N) blir erstattet med en ny tabell(N+1) 64 med en ny hemmelighet(N+1), blir nytt innhold 12 som er plassert i mediet 61 deretter bundet til den nye hemmeligheten(N+1). Samtidig, i enhver ny tabell 64, krypterer og beskytter hver hemmelighet(N) den tidligere hemmeligheten(N-l), slik at alle hemmelighetene som noensinne har vært assosiert med mediet 61 og innholdet 12 i dette kan aksesseres via en "daisy-kjede" av hemmelighetene. Dette gjør det mulig for en anordning 62 som kan aksessere en spesifikk hemmelighet i daisy-kjeden til ved utvidelse å aksessere alle tidligere hemmeligheter i daisy-kjeden, men ikke noen av de senere hemmelighetene. Selvfølgelig må en anordning 62 kunne aksessere den seneste hemmeligheten i mediet 61 dersom ikke denne anordningen 62 har blitt ugyldiggjort.

Basert på det ovennevnte blir fremgangsmåter for å forenkle, effektuere og støtte innholdet 12 og tabellen 64 i mediet 61 beskrevet nedenfor.

Nå med henvisning til figur 17, for å skrive en ny hemmelig tabell 64 til et

medium 61 uten en tabell 64, oppnår vertsdatamaskinen 60 først denne tabellen 64 fra et hurtigbuffer 66 (figur 13) (trinn 1701). Hurtigbufferet 66 inneholder minst én hemmelig tabell 64, idet hver tabell 64 er basert på en forskjellig hemmelighet som er oppnådd fra master-tabellen 68 og administratoren for denne ved hjelp av

en tabell-tjener eller liknende (ikke vist). Generering av tabellene 64 av eller for tabell-tjeneren som skal distribueres til hurtigbufferet 66 kan gjennomføres med en hvilken som helst egnet fremgangsmåte innenfor idéen bak og rammen til foreliggende oppfinnelse.

For eksempel, for å generere en tabell 64, kan tabell-tjeneren eller en annen anordning ha tilgang til master-listen og en generator for tilfeldige tall, og kan anvende tilfeldig tall generatoren for å generere en hemmelig verdi. For hver gyldige anordningsnøkkel (DK) i master-listen, anvendes da denne anordningsnøk-kelen (DK) for å kryptere den genererte hemmeligheten, og denne krypterte hemmeligheten blir lagret i tabellen 64 som blir generert. Merk at for hver ugyldige anordningsnøkkel (DK) i master-tabellen 68, hemmeligheten ikke blir kryptert med denne og plassert i tabellen 64 som blir generert. Istedet blir plassen for denne (DK-X(SECRET)) bare etterlatt blank eller blir fylt med en forbestemt verdi, så som 0.1 tillegg blir versjonsnummeret til master-listen anvendt som versjonsnummer for tabellen 64 som blir generert og plasseres i denne på et passende sted, og tabellen 64 inklusive dens versjonsnummer blir signert med en privat nøkkel for administratoren eller en annen passende entitet (dvs. autoriseringsmekanismen ovenfor).

Som en nå må forstå, blir én eller flere tabeller 64 plassert i hurtigbufferet 66 til passende tider, basert på etterspørsel eller liknende. Det kan alternativt være slik at en ny tabell 64 oppnås ved behov direkte fra tabell-tjeneren som tjener som hurtigbufferet 66. Merk at vertsdatamaskinen 64 kan anvende en tabell 64 fra hurtigbufferet 66 én gang eller mer enn én gang innenfor idéen bak og rammen til foreliggende oppfinnelse.

Som med anordningen 62, har vertsdatamaskinen 60 en anordningsnøkkel (DK) som indekserer inn i en hvilken som helst tabell 64. Følgelig anvender vertsdatamaskinen 60 anordningsnøkkelen (DK) og indeksverdien til denne for å finne det motsvarende elementet i den oppnådde tabellen 64 og eksponere hemmeligheten i denne tabellen 64 (trinn 1703). Merk at vertsdatamaskinen 60 kan ha mange anordningsnøkler (DK). Dersom det er slik at ingen av nøklene i den oppnådde tabellen 64 overensstemmer med den seneste tabellversjonen, er an-ordningsnøklene (DK) i vertsdatamaskinen foreldet eller annullert, og må oppdateres før noe som helst innhold 12 kan bli skrevet til mediet 61.

Med hemmeligheten i den oppnådde tabellen 64 eksponert, oppnår vertsdatamaskinen ID-nummeret til mediet 61 fra denne (trinn 1705) og legger til dette ID-nummeret i den oppnådde tabellen 64 (trinn 1707). Siden tabellen 64 er den første som blir lagret i mediet 61, tilordner enten vertsdatamaskinen 60 et versjonsnummer så som 0 eller 1 til tabellen, eller tabellen 64 omfatter allerede et slikt versjonsnummer. Vertsdatamaskinen 60 krypterer eller signerer deretter med hemmeligheten for å binde tabellen 64 til mediet 61 ved hjelp av dettes ID-nummer (trinn 1709), idet det er antatt at det faktisk anvendes et ID-nummer. Deretter kopierer vertsdatamaskinen 60 tabellen 64 til mediet 61 (trinn 1711).

Nå med antagelsen om at mediet 61 allerede inneholder en tabell 64 og skal motta nytt innhold 12, og med henvisning til figur 18, forhåndssjekker vertsdatamaskinen tabellen 64 i mediet 61 for å se om signaturene i denne verifiserer (trinn 1801). Hvis ikke er mediet 61 sannsynligvis korrupt, og må reformatteres. I tillegg oppnår vertsdatamaskinen 60 versjonsnummeret til tabellen 64 og/eller annen informasjon i mediet 61 (trinn 1801), og bestemmer basert på denne hvorvidt tabellen 64 er foreldet (trinn 1803). For eksempel kan vertsdatamaskinen 60 bestemme basert på det oppnådde versjonsnummeret og/eller annen innforma-sjon at tabellen 64 er relativt gammel eller at tabellen 64 ikke reflekterer visse ugyldiggjorte anordninger 62.1 tillegg til, eller alternativt, kan en betingelse i en lisens 16 som svarer til det nye innholdet 12 kreve at tabellen 64 blir oppdatert til et nyere versjonsnummer. For eksempel, dersom versjonsnummeret til tabellen 64 i mediet 61 er 40 og lisensbetingelsen krever at dette versjonsnummeret er minst 60, må tabellen 64 oppdateres.

Dersom tabellen 64 i mediet 61 faktisk må oppdateres, oppretter vertsdatamaskinen en ny (N+1 )-te tabell 64 for å erstatte den (N)-te tabellen 64 som allerede finnes i mediet 61 (trinn 1805) og plasserer denne i dette (trinn 1807). Spesielt, og nå med henvisning til figur 18A, oppnår vertsdatamaskinen den (N+1)-te tabellen 64 med en (N+1)-te hemmelighet fra hurtigbufferet 66 (trinn 1805a), oppnår den (N+1 )-te hemmeligheten som i figur 17 (trinn 1805b) og binder den (N+1)-te tabellen 64 til mediet 61 som i figur 17 (trinn 1805c). Merk at den (N+1)-te tabellen 64 som oppnådd fra tabell-tjeneren via hurtigbufferet 66 allerede har et nyere versjonsnummer i et passende område. Videre oppnår vertsdatamaskinen 60 den (N)-te hemmeligheten fra den (N)-te tabellen 64 i mediet 61 og, om en slik finnes, en daisy-kjede med tidligere hemmeligheter i den (N)-te tabellen 64 (trinn 1805d). Vertsdatamaskinen utvider da den oppnådde daisy-kjeden med én for å legge til den (N)-te hemmeligheten i denne kryptert i henhold til den (N+1)-te hemmeligheten som neste ledd i daisy-kjeden av hemmeligheter (trinn 1805e), og legger til den utvidede daisy-kjeden i den (N+1)-te tabellen 64 (trinn 1805f).

Vertsdatamaskinen 60 modifiserer også den (N+1)-te tabellen til å omfatte gamle hemmeligheter for anordningsnøkler (DK) som har blitt ugyldiggjort, og tilordner et versjonsnummer til hvert element. Spesielt bestemmer vertsdatamaskinen 60 fra den (N+1 )-te tabellen 64 hvilke anordningsnøkler (DK) som er ugyldiggjort (trinn 1805 g), og fyller inn elementet i denne (N+1)-te tabellen 64 for hver ugyldiggjorte (DK) med det motsvarende elementet i den (N)-te tabellen 64, sammen med versjonsnummeret til dette motsvarende elementet (trinn 1805h). Merk at vertsdatamaskinen 60 for eksempel kan bestemme fra den (N+1 )-te tabellen 64 hvilke anordningsnøkler (DK) som er ugyldiggjort ved å bestemme hvilke elementer i denne (N+1 )-te tabellen som er tomme eller er fylt med en forbestemt verdi, for eksempel 0.

Vertsdatamaskinen 60 kan deretter tilordne versjonsnummeret til den (N+1)-te tabellen 64 til alle anordningsnøkkel-elementer i denne som ikke er endret og derfor fortsatt gyldig. Alternativt har tabell-tjeneren som genererte den (N+1)-te tabellen 64 allerede utført denne tilordningen. En gyldig anordning 62 med en gyldig anordningsnøkkel (DK) kan således aksessere den seneste ((N+1)-te) hemmeligheten i den (N+1)-te tabellen 64. Tilsvarende kan en ugyldiggjort anordning 62 med en ugyldiggjort anordningsnøkkel (DK) aksessere en motsvarende hemmelighet i den (N+1)-te tabellen 64, men hemmeligheten er den for en tidligere tabell 64 for mediet 61, ikke fra den (N+1 )-te tabellen 64. Som beskrevet ovenfor, med en slik aksessert hemmelighet, kan anordningen 62 ved utvidelse aksessere alle tidligere hemmeligheter i daisy-kjeden, men ikke noen av de senere hemmelighetene.

Når elementene i den (N+1)-te tabellen er korrekt innrettet, krypterer eller signerer deretter vertsdatamaskinen 60 den (N+1)-te tabellen 64 med den (N+1)-te hemmeligheten for å binde den (N+1)-te tabellen 64 til mediet 61 ved hjelp av dettes ID-nummer som i figur 17 (trinn 1805i). Endelig blir den (N+1)-te tabellen 64 kopiert til mediet 61 som i trinn 1807 for å erstatte den (N)-te tabellen 64 deri.

Nå med antagelsen om at et medium 61 inneholder en gjeldende tabell 64 med en gjeldende hemmelighet, et versjonsnummer i forhold til master-tabellen 68, et ID-nummer, og ved utvidelse en endelig hemmelighet som kan avledes fra hemmeligheten og ID-nummeret, kan vertsdatamaskinen 60 skrive innhold 12 til mediet 61. For å gjøre dette, og nå med henvisning til figur 19, oppnår vertsdatamaskinen 60 ID-nummeret fra mediet 61 (trinn 1901), oppnår hemmeligheten fra tabellen 64 i mediet 61 (trinn 1903), bekrefter signaturene i tabellen 64 (trinn 1905) og bekrefter at ID-nummeret i tabellen 64 overensstemmer med ID-nummeret til mediet 61 (trinn 1907). Antatt at bekreftelsene er positive, kombinerer vertsdatamaskinen 60 da den oppnådde hemmeligheten og ID-nummeret for å bestemme den endelige hemmeligheten i henhold til en forbestemt funksjon, så som den som ble beskrevet ovenfor (trinn 1909), krypterer innholdet 12 som skal skrives til mediet 61 med den endelige hemmeligheten (trinn 1911), og binder med det innholdet 12 til mediet 61, og kopierer det krypterte innholdet 12 til mediet 61 (trinn 1913). Deretter kan vertsdatamaskinen 60 utføre en hvilken som helst passende påfølgende handling som nødvendig og hensiktsmessig. For eksempel, dersom innholdet 12 har blitt levert som del av en finansiell transaksjon, kan vertsdatamaskinen merke transaksjonen som fullført, endre en konto, inkrementere eller dekrementere en tellerverdi, etc.

Merk at trinnene som utføres i forbindelse med figur 19 ikke tar hensyn til hvorvidt den anordningen 62 til hvilken mediet 61 skal monteres eller er en intern del av er gyldig og således har én eller flere gyldige anordningsnøkler (DK). Faktum er at vertsdatamaskinen 60 mest sannsynlig ikke har noen mulighet for å verifisere dette før den skriver innholdet 12 til mediet 61. Dersom en ugyldiggjort anordning 62 forsøker å gjengi innholdet 12 i mediet 61, idet innholdet 12 er kryptert med en hemmelighet som er nyere enn de hemmeligheter som er tilgjengelige for den ugyldiggjorte anordningen 62 fra tabellen 64 i mediet 61, vil forsøket ikke lykkes.

Når innhold 12 har blitt kopiert til mediet 61, kan dette innholdet 12 gjengis

av en hvilken som helst anordning 62 som har kompatibel programvare, som kan lese mediet 61 og som kan ta imot dette (dersom mediet 61 er separat fra anordningen). Naturligvis må anordningen 62 ha et legalt DRM-system 32s og en symmetrisk anordningsnøkkel (DK) som indekserer inn i tabellen 64 i mediet 61.1 tillegg kan ikke anordningen 62 være annullert eller ugyldiggjort fra tabellen 64 og ikke være i stand til å aksessere fra tabellen 64 den hemmeligheten som er nød-vendig for å gjengi innholdet 12.

For å gjengi innholdet 12 i mediet 61 med anordningen 62, og nå med henvisning til figur 20, oppnår denne anordningen 62 ID-nummeret fra mediet 61 og fra tabellen 64 i mediet 61 (trinn 2001), og sammenlikner dette med ID-nummeret i tabellen 64 i denne for å bekrefte at tabellen 64 hører til i mediet 61 (trinn 2003). Antatt at sammenlikningen overensstemmer, oppnår anordningen 62 da et versjonsnummer som er assosiert med innholdet 12 som skal gjengis (trinn 2005). Merk at versjonsnummeret til innholdet 12 kan være lokalisert på et hvilket som helst egnet sted innenfor idéen bak og rammen til foreliggende oppfinnelse, og svarer til versjonsnummeret til tabellen 64, hemmeligheten i hvilken har blitt be-nyttet for å beskytte innholdet 12. Foreksempel kan versjonsnummeret bli lagret i eller vedlagt innholdet 12 av vertsdatamaskinen 60 før den laster ned disse til mediet 61, eller kan bli plassert av vertsdatamaskinen i en lisens 16 eller under-lisens 16s som ledsager innholdet 12.

Anordningen 62 anvender deretter indeksverdien(e) for anordningsnøkke-len/nøklene for denne for å oppnå den eller de motsvarende krypterte hemmelighetene og versjonsnumrene for disse fra tabellen 64 (trinn 2007). Som en forstår, bestemmer deretter anordningen 62 hvorvidt det høyeste versjonsnummeret til den eller de oppnådde krypterte hemmelighetene er lavere enn versjonsnummeret til innholdet 12.1 så fall kan ikke innholdet 12 gjengis av anordningen (trinn 2009). Hvis ikke blir én av de krypterte hemmelighetene som har et versjons nummer som er høyere enn eller lik versjonsnummeret til innholdet 12 valgt (trinn 2011). Den valgte, krypterte hemmeligheten bør ha samme versjonsnummer som innholdet 12, slik at det ikke er nødvendig å traversere gjennom daisy-kjeden, eller bør være nærmest mulig versjonnummeret til innholdet 12 slik at tra-verseringen av daisy-kjeden blir så kort som mulig.

Anordningen 62 oppnår deretter den anordningsnøkkelen (DK) for denne som svarer til den valgte krypterte hemmeligheten (trinn 2013), og anvender den for å eksponere hemmeligheten (trinn 2015). Om nødvendig blir den eksponerte hemmeligheten deretter anvendt for å traversere daisy-kjeden i tabellen 64 til-bake til den hemmeligheten som ble anvendt for å beskytte innholdet 12, og denne hemmeligheten for innholdet 12 blir med dette eksponert (trinn 2017). Som en må forstå blir versjonsnummeret til den valgte krypterte hemmeligheten anvendt for å bestemme hvor en skal entre daisy-kjeden, og anordningen 62 traverserer bakover i daisy-kjeden til det korrekte versjonsnummeret som avdekker hemmeligheten for innholdet 12.

Når hemmeligheten for innholdet 12 er eksponert, blir denne hemmeligheten og ID-nummeret til mediet 61 anvendt for å bestemme den endelige hemmeligheten (trinn 2019), og den endelige hemmeligheten kan deretter anvendes for å gjengi innholdet 12, betinget at en motsvarende lisens 16 eller under-lisens 16s som svarer til innholdet 12 er oppfylt.

Merk at mens en (N+1)-te tabell 64 tilveiebringes til et medium som erstat-ning for en (N)-te tabell 64 som allerede befinner seg i dette, kan det være tilfelle at versjonsnummeret til den (N+1)-te tabellen 64 ikke er det neste versjonnummeret for den (N)-te tabellen 64. Istedet, og som kan sees i figur 16, kan det være slik at den (N)-te tabellen 64 er generert fra versjonsnummer 19 av master-tabellen 68 og derfor har versjonsnummer 19, og at den (N+1)-te tabellen 64 er generert fra versjonsnummer 25 for master-tabellen 68 og derfor har versjonsnummer 25. Siden alt innhold 12 som lastes ned til mediet 61 blir beskyttet med hemmeligheten i den gjeldende tabellen 64, og tabellen 64 i mediet 61 ble endret fra versjonsnummer 19 med SECRET 19 til versjonsnummer 25 med SECRET 25, er det mest sannsynlig ikke mulig at innhold 12 som er lastet ned etter at tabellen 64 ble endret til versjonsnummer 19 vil kunne være beskyttet med en hemmelighet som er forskjellig fra SECRET 19 eller SECRET 25.

Som beskrevet ovenfor blir tabellen 64 som generert av tabell-tjeneren eller liknende signert med en privat nøkkel for administratoren eller en annen passende entitet. Ved trinn 1805h i figur 18 fyller imidlertid vertsdatamaskinen 60 opp elementet i denne (N+1)-te tabellen 64 for hver ugyldiggjorte (DK) med det motsvarende elementet i den (N)-te tabellen 64, sammen med versjonsnummeret til dette motsvarende elementet. Når vertsdatamaskinen 60 bekrefter denne tabell-tjenerens signatur som i trinn 1905 i figur 19, vil således denne bekreftelsen feile dersom ikke vertsdatamaskinen 60 først fikser opp hvert fylte element slik at det reflekterer tilstanden til dette ved tidspunktet for tabell-tjenerens signatur. Denne oppfiksingen skulle være åpenbar for fagmannen, og trenger derfor ikke beskrives i detalj her.

Som beskrevet i forbindelse med figurene, kan hemmeligheten eller den endelige hemmeligheten som oppnådd fra tabellen 64 dekryptere eller tilveiebringe tilgang til innholdet 12. Alternativt kan det være slik at hemmeligheten eller den endelige hemmeligheten som oppnådd fra tabellen 64 dekrypterer eller tilveiebringer tilgang til en innholdsnøkkel for innholdet 12, idet innholdsnøkkelen er lokalisert i innholdet 12, en lisens 16 eller under-lisens 16s for innholdet 12 eller et annet sted. Som en forstår, betyr det å beskytte innholdsnøkkelen med hemmeligheten eller den endelige hemmeligheten at innholdet 12 ikke trenger å bli beskyttet på en måte som er spesifikk for et spesifikt medium. Likevel er innholdet 12 fortsatt bundet til mediet 61 i kraft av det at det kun kan aksesseres med innholdsnøkkelen, som er bundet til mediet 61 ved at det er beskyttet av hemmeligheten eller den endelige hemmeligheten i tabellen 64 i mediet 61.

Videre, som også beskrevet i forbindelse med figurene, løper versjonsnummeret med master-tabellen 68. Det kan imidlertid istedet være slik at versjonsnummeret løper med mediet 61, for eksempel, innenfor idéen bak og rammen til foreliggende oppfinnelse. Merk at dersom versjonsnummeret løper med mediet 61, så vil vertsdatamaskinen 60 blant annet være ansvarlig for å bestemme versjonsnummeret til en (N)-te tabell 64 og inkrementere dette under opprettelsen av en (N+1 )-te tabell 64 for et medium 61.

Etter hvert som versjonsnummeret til master-tabellen 68 øker, vil det bli færre og færre gyldige anordningsnøkkel-elementer i enhver tabell 64. Det kan derfor være ønskelig å utvide master-tabellen 68 og tabellene 64 for å legge til nye elementer. Anta for eksempel at en master-tabell 68 omfatter 10 elementer, 1-10. Over tid blir anordningsnøklene (DK) som er grunnlaget for elementene kompromittert og ugyldiggjøres i master-tabellen 68. Når ett enkelt gyldig element (for eksempel 3) er igjen i master-tabellen 68, blir det bestemt å utvide denne master-tabellen 68 ved å legge til elementer 11-20. Alle nye tabeller 64 blir således basert på den utvidede master-tabellen 68 der elementene 1, 2 og 4-10 er ugyldige og elementene 3 og 11-20 er gyldige. Anordningsnøkler (DK) svarende til elementene 3 og 11-20 kan deretter distribueres til den neste gene-rasjonen anordninger 62 for å lese nytt innhold 12.

Det er viktig at den siste anordningsnøkkelen som ble ugyldiggjort (DK-9, for eksempel) også blir distribuert til neste generasjon anordninger 62. Det vil si at hver nye anordning 62 må omfatte anordningsnøkkelen (DK-9) svarende til elementet 9. Selv om (DK-9) allerede er kompromittert, vil ikke ytterligere distribusjon svekke den inntrengningen. Men ettersom alt "første generasjons" innhold 12 betraktet (DK-9) som gyldig, kan (DK-9) anvendes på slikt første generasjons innhold 12 for å gi tilgang til dette.

På denne måten har den siste ugyldiggjorte anordningsnøkkelen (DK) en spesiell verdi. Siden den har blitt kompromittert, kan den være distribuert i utstrakt grad. Men siden den ikke har vært annullert før utstedelsen av den "andre generasjons" utvidede tabellen 64, gir den tilgang til alt første generasjons innhold 12. Den siste ugyldiggjorte anordningsnøkkelen (DK) tjener således som en bro mellom de to generasjonene og tjener som det viktige elementet for å utvide den nye tabellen 64. Merk at i dette eksempelet, DK-3 også kunne ha tjent som bro siden den tilveiebringer tilgang til alt gammelt innhold 12, men det kan være motvillighet til å distribuere denne i for utstrakt grad, siden den ikke har blitt kompromittert enda.

Selv om foreliggende oppfinnelse er spesielt rettet mot en enkel anordning 62 som kun kan utføre symmetrisk kryptering og dekryptering, kan foreliggende oppfinnelse også anvendes av en enkel anordning 62 eller en hvilken som helst annen anordning som utfører asymmetrisk kryptering og dekryptering. Selvfølge-lig, for å gjøre dette, vil spesifikke elementer i tabellen 64 kryptere hemmeligheten i denne med en privat nøkkel, og anordningen vil har en motsvarende felles-nøkkel. Andre nødvendige endringer for å anpasse for asymmetrisk kryptering og dekryptering skulle være åpenbare for fagmannen, og trenger derfor ikke beskrives i detalj her.

Selv om foreliggende oppfinnelse er spesielt nyttig i forbindelse med en forholdsvis liten og/eller enkel anordning 62 med begrenset funksjonalitet, så som beskrevet ovenfor, kan foreliggende oppfinnelse praktiseres med hensyn til en hvilken som helst egnet anordning, det være seg en forholdsvis enkel eller en relativt kompleks, alt innenfor idéen bak og rammen til foreliggende oppfinnelse, så som for eksempel en personlig datamaskin, en tjener, et intelligent apparat, etc. Mer konkret kan foreliggende oppfinnelse for eksempel anvendes for å gjøre det mulig for en CD-spiller å spille av en CD med beskyttet musikk, for å gi en set-top boks tilgang til en beskyttet fjernsynskringkasting, etc. Følgelig skal "enkel anordning" fortolkes til å omfatte en hvilken som helst anordning 62 som har en anordningsnøkkel (DK) og som kan motta innhold 12 og en ledsagende tabell 64 av hemmeligheter og oppnå hemmeligheten for å gjengi det mottatte innholdet 12 fra tabellen basert på (DK) eller liknende.

Programmeringen som er nødvendig for å effektuere prosessene som utfø-res i forbindelse med foreliggende oppfinnelse er relativt rett frem, og skulle være åpenbar for en programmerer. Følgelig er ikke slik programmering innlemmet i denne søknaden. Enhver programmering kan anvendes for å realisere foreliggende oppfinnelse innenfor idéen bak og rammen til denne.

I den foregående beskrivelsen kan det sees at foreliggende oppfinnelse omfatter en ny og nyttig fremgangsmåte og mekanisme som gjør at den digitale rettighetsforvaltningsarkitekturen 10 kan utvides til en forholdsvis liten og/eller enkel anordning 62. Denne arkitekturen 10 muliggjør kryptering og databeskyttelse for innhold 12 på den forholdsvis lille anordningen 62, selv om den anordningen 62 på hvilken innholdet 12 skal gjengis er relativt liten og/eller enkel og ikke har relativt komplekse muligheter så som det å utføre asymmetrisk nøkkel dekryptering og kommunisere med en fjernlokalisert entitet over en nettverksforbindelse eller liknende. Det må forstås at det vil kunne foretas endringer i de ut-førelsesformene som er beskrevet ovenfor uten å avgå fra de oppfunnede kon-septene i disse. Det må derfor forstås at foreliggende oppfinnelse ikke er begrenset til de spesifikke utførelsesformene som er beskrevet, men at den er ment å dekke modifikasjoner innenfor idéen bak og rammen til foreliggende oppfinnelse, som defineres av de etterfølgende patentkravene.

Claims

1. Fremgangsmåte som utføres i kombinasjon med en vertsdatamaskin og en anordning som haren anordningsnøkkel (DK) med en forvalgt indeksverdi, der anordningen er for å motta et lagringsmedium eller omfatter lagringsmediet, idet lagringsmediet har lagret deri digitalt innhold som er beskyttet i henhold til en hemmelighet og en tabell som inneholder flere elementer, og hvert element omfatter hemmeligheten kryptert med en nøkkel som kan dekrypteres med anord-ningsnøkkelen (DK) for én av flere mulige anordninger og en indeksverdi, idet fremgangsmåten er for at anordningen skal gjengi innholdet i mediet og omfatter de trinn å: motta en forespørsel om å gjengi innholdet i mediet; oppnå tabellen fra mediet; oppnå anordningsnøkkelen (DK) for anordningen og indeksverdien til denne (DK); indeksere inn i et element i tabellen basert på den oppnådde indeksverdien; velge den krypterte hemmeligheten fra det indekserte elementet; anvende den oppnådde anordningsnøkkelen (DK) på den valgte krypterte hemmeligheten for å eksponere hemmeligheten; og anvende den eksponerte hemmeligheten for å gjengi det motsvarende innholdet.

2. Fremgangsmåte ifølge krav 1, der hemmeligheten omfatter én av en symmetrisk nøkkel, en innholdsnøkkel for innholdet og et passord.

3. Fremgangsmåte ifølge krav 1, der anordningen har flere anordningsnøkler (DK), hver med en forhåndsvalgt indeksverdi, og fremgangsmåten omfatter de trinn å: oppnå anordningsnøklene (DK) for anordningen og indeksverdiene til disse anordningsnøklene (DK); og for hver oppnådde anordningsnøkkel (DK) å: indeksere inn i et element i tabellen basert på den tilhørende oppnådde indeksverdien; velge den krypterte hemmeligheten fra det indekserte elementet; og anvende den oppnådde anordningsnøkkelen (DK) på den valgte krypterte hemmeligheten for å eksponere hemmeligheten, inntil hemmeligheten er eksponert.

4. Fremgangsmåte ifølge krav 1, der mediet inkluderer en identifikator for dette deri og har lagret deri det digitale innholdet beskyttet i henhold til en endelig hemmelighet som er avledet fra en kombinasjon av hemmeligheten og identifikatoren, der innholdet bindes til mediet av identifikatoren, og hvor fremgangsmåten omfatter de trinn å: anvende den oppnådde anordningsnøkkelen (DK) på den valgte krypterte hemmeligheten for å eksponere hemmeligheten; oppnå identifikatoren for mediet fra dette; anvende den eksponerte hemmeligheten og den oppnådde identifikatoren på en forbestemt funksjon for å generere den endelige hemmeligheten; og anvende den genererte, endelige hemmeligheten for å gjengi det motsvarende innholdet.

5. Fremgangsmåte ifølge krav 4, omfattende det å anvende den eksponerte hemmeligheten og den oppnådde identifikatoren på en en-veis hash-funksjon for å generere den endelige hemmeligheten.

6. Fremgangsmåte ifølge krav 1, der mediet omfatter en identifikator for dette deri og tabellen omfatter identifikatoren for mediet lagret deri, idet tabellen bindes til mediet av identifikatoren, og hvor fremgangsmåten videre omfatter de trinn å: oppnå identifikatoren for mediet fra dette; oppnå identifikatoren for mediet som lagret i tabellen; sammenlikne de oppnådde identifikatorene og kun fortsette dersom identifikatorene overensstemmer.

7. Fremgangsmåte ifølge krav 6, der tabellen omfatter en signatur som i hvert fall delvis er basert på identifikatoren for mediet som lagret i dette, og hvor fremgangsmåten videre omfatter det å verifisere signaturen for å verifisere identifikatoren.

8. Fremgangsmåte ifølge krav 6, der tabellen omfatter identifikatoren for mediet kryptert i henhold til hemmeligheten som avdekket, hvor identifikatoren oppnås ved å anvende hemmeligheten på den krypterte identifikatoren for å avdekke denne.

9. Fremgangsmåte ifølge krav 1, der tabellen i mediet oppdateres periodisk med en ny hemmelighet og omfatter en daisy-kjede av tidligere hemmeligheter, idet hver tidligere hemmelighet i daisy-kjeden er kryptert i henhold til en umiddelbart følgende hemmelighet for å danne en serie av ledd, idet hvert element i tabellen omfatter den nye hemmeligheten eller én av de tidligere hemmelighetene kryptert med anordningsnøkkelen (DK) for én blant flere mulige anordninger, en indeksverdi og et versjonsnummer for den krypterte hemmeligheten i elementet, og idet innholdet som skal gjengis har et versjonsnummer som svarer til den hemmeligheten i daisy-kjeden som beskytter dette innholdet, og fremgangsmåten omfatter de trinn å: bestemme innholdets versjonsnummer; velge den krypterte hemmeligheten fra det indekserte elementet; bestemme versjonsnummeret til den valgte krypterte hemmeligheten; anvende den oppnådde anordningsnøkkelen (DK) på den valgte krypterte hemmeligheten for å avdekke den valgte krypterte hemmeligheten; bestemme basert på versjonsnummeret til den valgte krypterte hemmeligheten et inngangspunkt i daisy-kjeden; traversere bakover fra inngangspunktet i daisy-kjeden for å eksponere hemmeligheten som beskytter innholdet; og anvende den eksponerte hemmeligheten for å gjengi det motsvarende innholdet, idet en anordning kan traversere daisy-kjeden fra inngangspunktet for å oppnå tidligere hemmeligheter, men ikke senere hemmeligheter.

10. Fremgangsmåte ifølge krav 9, videre omfattende de trinn å: bestemme basert på versjonsnummeret til den valgte krypterte hemmeligheten og versjonsnummeret til innholdet hvorvidt hemmeligheten kan anvendes for å gjengi innholdet, og fortsette bare dersom versjonsnummeret til den valgte krypterte hemmeligheten ikke er lavere enn versjonsnummeret til innholdet, og derfor kan anvendes for å gjengi innholdet.

11. Fremgangsmåte ifølge krav 1, der anordningsnøkkelen (DK) er en symmetrisk nøkkel.

12. Fremgangsmåte som utføres i kombinasjon med en vertsdatamaskin og flere anordninger som hver har en anordningsnøkkel (DK) med en forhåndsvalgt indeksverdi, der hver anordning er for å motta et lagringsmedium eller omfatter lagringsmediet, idet lagringmediet omfatter en identifikator for dette deri og har lagret deri digitalt innhold som er beskyttet med en hemmelighet samt en tabell som inneholder flere elementer, der hvert element omfatter hemmeligheten kryptert med en nøkkel som kan dekrypteres med anordningsnøkkelen (DK) for én blant flere mulige anordninger og en indeksverdi, idet fremgangsmåten er for at vertsdatamaskinen skal forsyne mediet med tabellen, og omfatter de trinn å: oppnå tabellen fra et hurtigbuffer; oppnå identifikatoren for mediet fra dette; legge til den oppnådde identifikatoren for mediet i den oppnådde tabellen; anvende en anordningsnøkkel (DK) og indeksverdien for denne for å finne det motsvarende elementet i den oppnådde tabellen og avdekke hemmeligheten i denne tabellen; binde tabellen til mediet med identifikatoren for mediet og den eksponerte hemmeligheten; og kopiere den tilknyttede tabellen til mediet.

13. Fremgangsmåte ifølge krav 12, der det å binde tabellen til mediet omfatter det å legge til i tabellen en signatur som i hvert fall delvis er basert på identifikatoren for mediet og den eksponerte hemmeligheten.

14. Fremgangsmåte ifølge krav 12, der det å binde tabellen til mediet med identifikatoren for mediet omfatter det å kryptere identifikatoren i henhold til den eksponerte hemmeligheten og legge til den krypterte identifikatoren i tabellen.

15. Fremgangsmåte ifølge krav 12, omfattende det å oppnå tabellen fra et hurtigbuffer som inneholder flere tabeller, som hver er basert på en forskjellig hemmelighet.

16. Fremgangsmåte ifølge krav 12, videre omfattende det å tilordne et versjonsnummer til tabellen.

17. Fremgangsmåte ifølge krav 12, der tabellen som tilveiebringes er en (N)-te tabell, idet fremgangsmåten videre omfatter at vertsdatamaskinen tilveiebringer mediet med en (N+1 )-te, oppdatert tabell som erstatter den (N)-te tabellen i mediet og omfatter de trinn å: oppnå (N+1)-te tabellen 64 med en (N+1)-te hemmelighet fra hurtigbufferet; oppnå identifikatoren for mediet fra dette; legge til den oppnådde identifikatoren for mediet i den (N+1)-te tabellen; oppnå den (N+1)-te hemmeligheten fra den (N+1)-te tabellen; oppnå den (N)-te hemmeligheten fra den (N)-te tabellen i mediet og, om en slik eksisterer, en daisy-kjede av tidligere hemmeligheter i den (N)-te tabellen, idet hver tidligere hemmelighet i daisy-kjeden krypteres i henhold til en umiddelbart følgende hemmelighet for å danne en serie av linker; utvide den oppnådde daisy-kjeden og legge til den (N)-te hemmeligheten i denne kryptert i henhold til den (N+1)-te hemmeligheten som et nytt ledd i daisy-kjeden; legge til den utvidede daisy-kjeden i den (N+1)-te tabellen; modifisere den (N+1)-te tabellen til å omfatte gamle hemmeligheter for ugyldiggjorte anordningsnøkler (DK) og tilordne et versjonsnummer til hvert element; binde den (N+1)-te tabellen til mediet med identifikatoren for mediet og den oppnådde (N+1)-te hemmeligheten; og kopiere den modifiserte (N+1 )-te tabellen i mediet for å erstatte den (N)-te tabellen.

18. Fremgangsmåte ifølge krav 17, hvor det å binde den (N+1)-te tabellen til mediet omfatter det å legge til i den (N+1 )-te tabellen en signatur som i hvert fall delvis er basert på identifikatoren for mediet og den eksponerte hemmeligheten.

19. Fremgangsmåte ifølge krav 17, der det å binde den (N+1 )-te tabellen til mediet med identifikatoren for mediet omfatter det å kryptere identifikatoren i henhold til den oppnådde (N+1 )-te hemmeligheten og legge til den krypterte identifikatoren i den (N+1)-te tabellen.

20. Fremgangsmåte ifølge krav 17, der hvert element i den (N)-te tabellen videre omfatter et versjonsnummer for den motsvarende krypterte hemmeligheten og der det å modifisere den (N+1)-te tabellen til å omfatte gamle hemmeligheter for ugyldiggjorte anordningsnøkler (DK) og det å tilordne et versjonsnummer til hvert element omfatter de trinn å: bestemme fra den (N+1 )-te tabellen hvilke anordningsnøkler (DK) i denne som er ugyldiggjort; fylle elementet i denne (N+1)-te tabellen for hver ugyldiggjorte (DK) med det motsvarende elementet i den (N)-te tabellen, sammen med versjonsnummeret til nevnte motsvarende element; tilordne versjonsnummeret til den (N+1)-te tabellen til alle elementene deri som ikke fylles fra den (N)-te tabellen og derfor fortsatt er gyldige, hvorved en gyldig anordning med en gyldig anordningsnøkkel (DK) kan aksessere den seneste ((N+1)-te) hemmeligheten i den (N+1)-te tabellen, og en ugyldiggjort anordning med en ugyldiggjort anordningsnøkkel (DK) kan aksessere en tilhørende hemmelighet i den (N+1)-te tabellen som er tidligere enn den (N+1)-te hemmeligheten og hvorved, med den aksesserte hemmeligheten, anordningen ved utvidelse kan aksessere alle tidligere hemmeligheter i daisy-kjeden, men ikke noen senere hemmeligheter.

21. Fremgangsmåte ifølge krav 12, der anordningsnøkkelen (DK) er en symmetrisk nøkkel.

22. Fremgangsmåte som utføres i kombinasjon med en vertsdatamaskin og et lagringsmedium som omfatter en identifikator for dette deri og som har lagret deri en tabell som inneholder flere elementer, der hvert element omfatter en hemmelighet som er kryptert i henhold til en nøkkel som kan dekrypteres av en anord-ningsnøkkel (DK) for én blant flere mulige anordninger og en indeksverdi, idet minst én av hemmelighetene er en gjeldende hemmelighet for tabellen, idet fremgangsmåten er for å lagre digitalt innhold i mediet i henhold til den gjeldende hemmeligheten for tabellen og omfatter det å: oppnå identifikatoren fra mediet; oppnå den gjeldende hemmeligheten fra tabellen; anvende den oppnådde, gjeldende hemmeligheten og den oppnådde identifikatoren i en forbestemt funksjon for å generere en endelig hemmelighet; beskytte innholdet som skal lagres i mediet i henhold til den endelige hemmeligheten, og med det binde innholdet til mediet ved identifikatoren for dette; og kopiere det beskyttede innholdet til mediet.

23. Fremgangsmåte ifølge krav 22, omfattende det å anvende den oppnådde, gjeldende hemmeligheten og den oppnådde identifikatoren i en en-veis hash-funksjon for å generere den endelige hemmeligheten.

24. Fremgangsmåte ifølge krav 22, der tabellen inneholder identifikatoren for mediet deri og en signatur deri basert på identifikatoren for mediet, idet fremgangsmåten videre omfatter det å sjekke signaturen for å verifisere at identifikatoren for mediet i tabellen overensstemmer med identifikatoren som ble oppnådd fra mediet.

25. Fremgangsmåte ifølge krav 22, der anordningsnøkkelen (DK) er en symmetrisk nøkkel.