NO332664B1

NO332664B1 - Fremgangsmate for bruk av en rettighetsmal for a oppna et signert rettighetsmerke (SRL) for digitalt innhold i et digitalt rettighetsforvaltningssystem

Info

Publication number: NO332664B1
Application number: NO20032991A
Authority: NO
Inventors: Vinay Krishnaswamy; Chandramouli Venkatesh; Steven Bourne
Original assignee: Microsoft Corp
Priority date: 2002-06-28
Filing date: 2003-06-27
Publication date: 2012-11-26
Also published as: EP1378812A2; NO20032991D0; US7549060B2; NO20032991L; JP4724360B2; JP2004054937A; US20040003268A1; EP1378812A3

Abstract

Innhold blir kryptert med en innholdsnøkkel (CK) ((CK(content))), (CK) blir beskyttet med en lisensserver sin fellesnøkkel (PU-DRM) og rettighetsdata assosiert med innholdet blir innhentet fra en rettighetsmal og beskyttet med (PU-DRM). De beskyttede elementene og en digital signatur fra rettighetsmalen blir sendt inn som et rettighetsmerke til lisensserveren for signering. Lisensserveren verifiserer rettighetsmalens signatur, og, dersom denne signaturen verifiserer, signerer rettighetsmerket for å danne et signert rettighetsmerke (SRL) og returnerer dette. Nevnte SRL blirsammenkjedet med (CK(content)), og begge blir distribuert til en bruker. For å rendre innholdet sender brukeren inn nevnte SRL til lisensserveren for å be om en lisens.

Description

De følgende US-patentsøknader beskriver temaer som er beslektet med temaet for foreliggende søknad, og hver inntas med dette ved referanse her: - US-patentsøknaden 10/185,527, innlevert samtidig med foreliggende søknad og gitt tittelen "Obtaining a Signed Rights Label (SRL) for Digital Content and Obtaining a Digital License Corresponding to the Content Based on the SRL in a Digital Rights Management System"; og

US-patentsøknaden 10/185,511, innlevert samtidig med foreliggende søknad og gitt tittelen "Systems And Methods For Issuing Usage Licences For Digital Content And Services".

Foreliggende oppfinnelse vedrører et digitalt rettighetsforvaltnings- eller DRM-system. Mer spesielt vedrører oppfinnelsen trinn som utføres ved bruk av en rettighetsmal for å oppnå et signert rettighetsmerke (SRL) fra en lisenstjener for et stykke digitalt innhold i et slikt DRM-system.

US 6,226,618 B1 beskriver en fremgangsmåte og en anordning for sikkert å tilveiebringe data til en brukersystem. Dataene krypteres slik at disse bare kan de krypteres av en datadekrypteringsnøkkel, hvor datadekrypteringsnøkkelen blir kryptert ved hjelp av en første felles eller offentlig nøkkel, og de krypterte dataene blir tilgjengelig for brukersystemet. Metoden består av følgende trinn: overføring av den krypterte data-dekrypteringsnøkkelen til en avregningssentral eller -sted som innehar en første privat-nøkkel tilsvarende den første offentlige nøkkelen; dekryptering av datadekrypterings-nøkkelen ved å bruke den første private nøkkelen, re-kryptering av datadekrypterings-nøkkelen ved å bruke en andre felles eller offentlig nøkkel; overføring av den re-krypterte datadekrypteringsnøkkelen til brukersystemet, idet brukersystemet innehar en andre privatnøkkel tilsvarende den andre offentlige nøkkelen; og dekryptering av den re-krypterte datadekrypteringsnøkkelen ved å rbuke den andre privatnøkkelen.

Administrasjon og håndheving av digitale rettigheter er sterkt ønskelig i forbindelse med digitalt innhold så som digital lyd, digital video, digital tekst, digitale data, digitale multimedier, osv., der slikt digitalt innhold skal distribueres til én eller flere brukere. Digitalt innhold kan være statisk, så som for eksempel et tekstdokument, eller det kan være streamet, så som streamede lyd/bilde-data for en "levende" hendelse. Typiske distribusjonsmåter omfatter fysiske anordninger så som en magnetisk (floppy) disk, et magnetbånd, en optisk (kompakt) disk (CD), osv., samt ikke-fysiske medier så som en elektronisk oppslagstavle, et elektronisk nettverk, Internett, osv. Når det mottas av brukeren, rendrer eller "avspiller" denne brukeren det digitale innholdet ved hjelp av en egnet rendringsanordning så som en media-avspiller på en personlig datamaskin eller liknende.

I ett scenario ønsker en innholdseier eller rettighetshaver, så som en forfatter, en forlegger, en kringkaster, osv. å distribuere digitalt innhold til hver av mange brukere eller mottakere mot en lisensavgift eller en annen godtgjørelse. I dette scenarioet kan innholdet være en sang, et album med sanger, en film, osv., og formålet med distribusjonen er å oppnå lisensavgiftene. 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 lisensavgift fra denne andre brukeren.

I tillegg kan innholdseieren ønske å gi brukeren fleksibilitet til å kjøpe forskjellige typer brukerlisenser til forskjellig lisensavgift, idet 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, kun på en viss type media-spiller, kun av en viss type bruker, osv.

I et annet scenario ønsker en innholdsutvikler, så som en ansatt i en organisasjon, å distribuere digitalt innhold til én eller flere andre ansatte i organisasjonen eller til andre individer utenfor organisasjonen, men vil hindre andre i å kunne rendre innholdet. I dette tilfellet er distribusjonen av innholdet mer beslektet med organisasjonsbasert innholds-deling på en konfidensiell eller restriktert måte, i motsetning til offentlig distribusjon mot en lisensavgift eller en annen godtgjørelse. I dette scenarioet kan innholdet være en dokumentpresentasjon, et elektronisk regneark, en database, e-post eller liknende, så som kan bli utvekslet i et kontormiljø, og innholdsutvikleren kan ønske å sikre at innholdet forblir innenfor dette kontormiljøet og ikke blir rendret av ikke-autoriserte individer, for eksempel konkurrenter eller motstandere. Igjen ønsker en slik innholdsutvikler å begrense hva en mottaker skal kunne gjøre med det distribuerte digitale inn holdet. For eksempel vil innholdseieren kunne ønske å hindre brukeren i å kopiere og re-distribuere innholdet til en andre bruker, i hvert fall på en måte som eksponerer innholdet utover den avgrensede gruppen av individer som skal tillates å rendre innholdet.

I tillegg kan innholdsutvikleren ønske å gi forskjellige mottakere forskjellige nivåer av rendringsrettigheter. For eksempel kan innholdsutvikleren ønske å tillate beskyttet digitalt innhold å være visbart, men ikke printbart for én klasse av individer og visbart og printbart for en annen klasse av individer.

I begge scenarioer, etter at distribusjonen har funnet sted, har imidlertid en slik innholdseier / utvikler veldig liten, om noen, kontroll over det digitale innholdet. Dette er spesielt problematisk i lys av det faktum at praktisk talt alle personlige datamaskiner innehar 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 en transaksjon der innholdet blir distribuert, kan innholdseieren / utvikleren kreve at brukeren / mottakeren av det digitale innholdet lover å ikke redistribuere det digitale innholdet på ulovlig måte. Et slikt løfte er imidlertid lett å gi og lett å bryte. En innholdseier / utvikler 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 bestemt bruker i å dekryptere kryptert digitalt innhold, lagre dette digitale innholdet på en ukryptert form og deretter redistribuere det.

Det eksisterer derfor et behov for tilveiebringelse av en arkitektur og en fremgangsmåte for forvaltning og håndheving av digitale rettigheter som muliggjør kontrollert rendring eller gjengivelse av vilkårlige former for digitalt innhold, der denne kontrollen er fleksibel og kan defineres av innholdseieren / utvikleren av slikt digitalt innhold. Mer spesifikt eksisterer det et behov for en slik arkitektur som muliggjør og letter slik kontrollert rendring, spesielt i et kontor- eller organisasjonsmiljø eller liknende der doku-menter skal deles mellom en definert gruppe av individer eller klasser av individer.

Oppfinnelsen fyller de ovennevnte behovene innenfor teknikken ved å tilveiebringe systemer og fremgangsmåter for å utstede brukerlisenser for digitalt innhold og tjenester via et signert rettighetsmerke.

Hovedtrekkene til oppfinnelsen fremgår av det selvstendige krav. Ytterligere trekk ved oppfinnelsen er angitt i de uselvstendige krav.

Ifølge oppfinnelsen utsteder en komponent for å utstede digital rettighetsforvaltnings-("DRM")-lisenser lisenser som gjør det mulig for en annen programvareapplikasjon eller-komponent å konsumere digitalt innhold eller tjenester i henhold til betingelser spesifisert av lisensen. For å utstede en lisens, anvender den lisensutstedende komponenten et rettighetsmerke som spesifiserer et sett av forutsetninger under hvilke det er mulig å utstede en enkelt, spesifikk lisens. Lisensforutsetningene spesifiserer rettigheter, betingelser og aktører for anvendelse av innholdet eller tjenesten. En "rettighet", som den termen blir anvendt her, refererer til en spesifikk handling som forstås av den konsumerende komponenten (for eksempel "Spille av" for en digital media-spiller, eller "Rediger" for et dokumentstyringssystem). En "betingelse", som den termen blir anvendt her, refererer til spesifikke kriterier som må være oppfylt før den konsumerende komponenten kan tillate konsumeringen å finne sted (for eksempel "Ikke senere enn 1. desember"). I tillegg kan lisensen også omfatte kryptografisk nøkkelmateriale som blir anvendt for å frigi det beskyttede innholdet eller tjenesten som er lisensiert. Et rettighetsmerke i henhold til oppfinnelsen omfatter en definisjon som definerer grensene for alle lisenser som lovlig kan bli utstedt med hensyn til det innholdet eller den tjenesten med hvilken rettighetsmerket er assosiert. En lisens omfatter således generelt en undergruppe av de rettighetene og betingelsene som er spesifisert i rettighetsmerket.

Oppfinnelsen kan tilveiebringes i form av en protokoll og/eller et applikasjons-program og/eller et API for å utføre funksjoner omfattende det å: motta en rettighetsbeskrivelse og assosiert beskyttet kryptografisk nøkkelmateriale for et stykke innhold; validere og generere digitale signaturer over disse dataene for å generere rettighetsmerket; gjøre det mulig for en applikasjon å spørre etter en lisens for spesifisert innhold; gjøre det mulig for DRM-lisensserveren å utføre en autorisasjonssjekk av den ovennevnte forespørselen; gjøre det mulig for DRM-lisensserveren å utstede en lisens til etterspørreren basert på forespørselen; og beskytte innholdets kryptografiske materiale til den applikasjonen eller brukeren som fremsetter forespørselen.

I en utførelsesform av foreliggende oppfinnelse blir digitalt innhold publisert for å gjøre det mulig for en lisensserver å utstede en digital lisens for innholdet til én eller flere brukere som ønsker å rendre innholdet. Innholdet blir kryptert med en innholdsnøkkel

(CK), hvilket gir (CK(content)), og (CK) blir beskyttet med en fellesnøkkel for lisensserveren (PU-DRM). En rettighetsmal blir innhentet, og rettighetsdata som skal assosieres med innholdet blir hentet fra rettighetsmalen, og de innhentede rettighetsdataene blir beskyttet med (PU-DRM).

De beskyttede rettighetsdataene og den beskyttede nøkkelen (CK) blir sendt som et rettighetsmerke til lisensserveren for signering av denne. Lisensserveren validerer rettighetsmerket og, dersom den er gyldig, genererer en digital signatur basert på en privat nøkkel (PR-DRM) som svarer til (PU-DRM) og basert i hvert fall delvis på de beskyttede rettighetsdataene for å oppnå et signert rettighetsmerke (SRL, signed-rights-label), og returnerer nevnte SRL. Nevnte returnerte SRL blir mottatt og sammenkjedet med (CK(content)) for å danne en innholdspakke, og innholdspakken blir distribuert til én eller flere brukere.

En bruker som ønsker å rendre innholdet innhenter nevnte SRL fra innholdspakken og sender inn nevnte innhentede SRL til lisensserveren som del av en forespørsel om lisensen for innholdet. Lisensserveren verifiserer signaturen i nevnte SRL basert på (PU-DRM) og basert i hvert fall delvis på de beskyttede rettighetsdataene, aksesserer de beskyttede rettighetsdataene i nevnte SRL og undersøker disse for å bestemme hvorvidt brukeren har rettighet til lisensen, og utsteder i så fall lisensen til brukeren. Lisensen omfatter (CK) på en beskyttet form som kan aksesseres av brukeren.

I en utførelsesform av oppfinnelsen omfatter rettighetsmerket rettighetsdataene som oppnådd fra en offisiell rettighetsmal (ORT, official-rights-template) og beskyttet med (PU-DRM), og omfatter også en digital signatur fra nevnte ORT, idet signaturen er basert på en privat nøkkel (PR-DRM) som svarer til (PU-DRM) og er basert i hvert fall delvis på rettighetsdataene i nevnte ORT (S(PR-DRM-T)). Lisensserveren verifiserer S(PR-DRM-T) basert i hvert fall delvis på de beskyttede rettighetsdataene i rettighetsmerket, og signerer rettighetsmerket kun dersom S(PR-DRM-T) verifiserer.

Andre trekk ved oppfinnelsen fremkommer fra den følgende detaljerte beskrivelsen av utførelsesformene av foreliggende oppfinnelse, sett sammen med de vedlagte figurene. Figur 1 er et blokkdiagram som illustrerer et eksempel på ikke-begrensende databehandlingsmiljø i hvilket foreliggende oppfinnelse kan bli implementert. Figur 2 er et blokkdiagram som illustrerer et eksempel på nettverksmiljø som omfatter flere dataanordninger i hvilke foreliggende oppfinnelse kan bli implementert. Figur 3 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for å publisere digitalt innhold. Figur 4 viser et flytdiagram av en foretrukket utførelsesform av en fremgangsmåte ifølge oppfinnelsen for å publisere rettighetsforvaltet digitalt innhold. Figur 4A er et blokkdiagram som viser strukturen til et signert rettighetsmerke som generert av fremgangsmåten i figur 4. Figur 5 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for lisensiering av rettighetsforvaltet digitalt innhold. Figurene 6A og 6B viser et flytdiagram av en foretrukket utførelsesform av en fremgangsmåte ifølge oppfinnelsen for lisensiering av rettighetsforvaltet digitalt innhold. Figur 7 er et flytdiagram som viser nøkkeltrinn som utføres for re-publisering av et rettighetsmerke i henhold til en utførelsesform av foreliggende oppfinnelse. Figur 8 er et blokkdiagram som viser et sertifikat utstedt av en DRM-server til en bruker for å gi brukeren mulighet for å utføre offline publisering i henhold til en utførelsesform av foreliggende oppfinnelse. Figur 9 er et blokkdiagram som viser en rettighetsmal som spesifiserer informasjon som skal innlemmes i et rettighetsmerke i henhold til en utførelsesform av foreliggende oppfinnelse. Figur 10 er et flytdiagram som viser nøkkeltrinn som utføres under generering av rettighetsmalen i figur 9 og under generering av det signerte rettighetsmerket i figur 4A basert på rettighetsmalen i henhold til en utførelsesform av foreliggende oppfinnelse. Figur 11 er et blokkdiagram som viser en håndhevelsesarkitektur i et eksempel på et tillitsbasert system.

Eksempel på dataanordning

Figur 1 og den følgende beskrivelsen er ment for å tilveiebringe en kort, generell

beskrivelse av et egnet databehandlingsmiljø i hvilket oppfinnelsen kan bli implementert. Det skal imidlertid forstås at håndholdte, flyttbare og andre dataanordninger av alle typer er mulige for anvendelse i forbindelse med foreliggende oppfinnelse. Selv om en generell

datamaskin er beskrevet nedenfor, er dette kun ett eksempel, og foreliggende oppfinnelse krever kun en tynn klient som har nettverkstjener-interoperabilitet og -interaksjon. Foreliggende oppfinnelse kan således bli implementert i et miljø av nettverksomfattede tjenester der veldig lite eller minimalt med klientressurser er påkrevet, f.eks. et nettverksmiljø der klientanordningen kun tjener som en browser eller et grensesnitt mot World-Wide-Web.

Selv om det ikke er nødvendig kan oppfinnelsen være implementert via et API for anvendelse av en utvikler og/eller omfattet i nettleser-programvaren som vil bli beskrevet i den generelle sammenhengen datamaskin-eksekverbare instruksjoner, så som programmoduler, som eksekveres av én eller flere datamaskiner, så som klientarbeids-stasjoner, tjenere eller andre anordninger. Generelt omfatter programmoduler rutiner, programmer, objekter, komponenter, datastrukturer og liknende som utfører spesifikke oppgaver eller implementerer spesifikke abstrakte datatyper. Funksjonaliteten til programmodulene kan typisk kombineres eller distribueres som ønsket i forskjellige utførelsesformer. Videre vil fagmannen forstå at oppfinnelsen kan praktiseres med andre datasystemkonstruksjoner. Andre velkjente datasystemer, -miljøer og/eller -konstruk-sjoner som kan være egnet for anvendelse med oppfinnelsen omfatter, men er ikke begrenset til, personlige datamaskiner (PC-er), automatiserte kassaapparater, tjenerdatamaskiner, håndholdte eller laptop-anordninger, flerprosessorsystemer, mikro-prosessorbaserte systemer, programmerbar forbrukerelektronikk, personlige datamaskiner i nettverk, minidatamaskiner, stormaskiner og liknende. Oppfinnelsen kan også praktiseres i distribuerte databehandlingsmiljøer der oppgaver blir utført av fjernlokaliserte prosesseringsanordninger som er forbundet gjennom et kommunikasjonsnettverk eller et annet dataoverføringsmedium. I et distribuert databehandlingsmiljø kan programmoduler være lokalisert i både lokale og fjernlokaliserte datamaskin-lagringsmedier som omfatter minnelagringsanordninger.

Figur 1 illustrerer således et eksempel på et egnet databehandlingsmiljø 100 i hvilket oppfinnelsen kan bli implementert, selv om, som presisert ovenfor, datamiljøet 100 bare er ett eksempel på et egnet datamiljø og ikke er ment for å antyde noen begrensning vedrørende oppfinnelsens bruksområde eller funksjonalitet. Heller ikke skal datamiljøet 100 fortolkes å ha noen som helst avhengighet eller krav vedrørende noen enkelt komponent eller noen kombinasjon av komponenter som er illustrert i det eksemplifiserte datamiljøet 100.

Med henvisning til figur 1 omfatter et eksempel på system for å implementere oppfinnelsen en generell databehandlingsanordning i form av en datamaskin 110. Komponenter av datamaskin 110 kan omfatte, men er ikke begrenset til, en prosesseringsenhet 120, et systemminne 130 og en systembuss 121 som kopler forskjellige systemkompo-nenter omfattende systemminnet til prosesseringsenheten 120. Systembussen 121 kan være en hvilken som helst av mange typer busstrukturer, omfattende en minnebuss eller minnekontroller, en periferenhet-buss og en lokal buss, som anvender en hvilken som helst av en rekke tilgjengelige bussarkitekturer. Som eksempler, og uten begrensning, omfatter slike arkitekturer en ISA (Industry-Standard-Architecture)-buss, en MCA (Micro-Channel- Architecture)-buss, en EISA (Enhanced ISA)-buss, en lokal VESA (Video-Electronics-Standards-Association)-buss, og en PCI (Peripheral-Component-lnter-connect)-buss (også kjent som en Mezzanine-buss).

Datamaskinen 110 omfatter typisk flere datamaskinlesbare medier. Datamaskinlesbare medier kan være et hvilket som helst tilgjengelig medium som kan aksesseres av datamaskinen 110, og omfatter både volatile og ikke-volatile medier, samt flyttbare og ikke-flyttbare medier. Som eksempler, uten begrensning, kan datamaskinlesbare medier omfatte datamaskin-lagringsmedier og kommunikasjonsmedier. Datamaskin-lagringsmedier omfatter både volatile og ikke-volatile samt flyttbare og ikke-flyttbare medier som er realisert med en hvilken som helst metode eller teknologi for lagring av informasjon så som datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data. Datamaskin-lagringsmedier omfatter, men er ikke begrenset til, RAM, ROM, EEPROM, flash-minne eller annen minneteknologi, CDROM, DVD (digital-versatile-disk) eller andre optisk-disk lagre, magnetkassetter, magnetbånd, magnetdisklagre eller andre magnet-lagringsanordninger, eller et hvilket som helst annet medium som kan anvendes for å lagre den ønskede informasjonen og som kan aksesseres av datamaskinen 110. Kommunikasjonsmedier omfatter typisk datamaskinlesbare instruksjoner, datastrukturer, programmoduler eller andre data i et modulert datasignal så som en bærebølge eller en annen transportmekanisme, og omfatter ethvert informasjonsleveringsmedium. Med betegnelsen "modulert datasignal" menes et signal som får én eller flere av sine karakte-ristika satt eller endret for det formål å innkode informasjon i signalet. Som et eksempel, og uten begrensning, omfatter kommunikasjonsmedier kablede medier så som et kabel-nettverk eller en direktekoplet forbindelse, samt trådløse medier så som akustiske, RF-baserte, infrarøde og andre trådløse medier. Enhver kombinasjon av det ovennevnte er også omfattet innenfor rammen av datamaskinlesbare medier.

Systemminnet 130 omfatter datamaskin-lagringsmedier i form av volatilt og/eller ikke-volatilt minne så som et leseminne (ROM) 131 og et direkteaksessminne (RAM) 132. Et BIOS (basic input/output system) 133, som inneholder de grunnleggende rutinene som overfører informasjon mellom elementer i datamaskinen 110, for eksempel under oppstart, er typisk lagret i ROM 131. RAM 132 inneholder typisk data og/eller programmoduler som er umiddelbart tilgjengelige for og/eller som opereres på av prosesseringsenheten 120. Som et eksempel, og uten begrensning, illustrerer figur 1 et operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137.

Datamaskinen 110 kan også omfatte andre flyttbare/ikke-flyttbare, volatile/ikke-volatile datamaskin-lagringsmedier. Kun som et eksempel illustrerer figur 1 en harddisk-stasjon 141 som leser fra eller skriver til ikke-flyttbare, ikke-volatile magnetiske medier, en magnetdiskstasjon 151 som leser fra eller skriver til en flyttbar, ikke-volatil magnetdisk 152 og en optisk-disk stasjon 155 som leser fra eller skriver til en flyttbar, ikke-volatil optisk disk 156, så som et CD-ROM eller et annet optisk medium. Andre flyttbare/ikke-flyttbare, volatile/ikke-volatile datamaskin-lagringsmedier som kan anvendes i det eksemplifiserte driftsmiljøet omfatter, men er ikke begrenset til, magnetbåndkassetter, flashminnekort, DVD-plater, digitale bildebånd, statisk RAM, statisk ROM og liknende. Harddiskstasjonen 141 er typisk koplet til systembussen 121 via et ikke-flyttbart minne-grensesnitt, så som grensesnittet 140, og magnetdiskstasjonen 151 og optisk-disk stasjonen 155 er typisk koplet til systembussen 121 via et flyttbart minne-grensesnitt, så som grensesnittet 150.

De stasjonene og deres assosierte datamaskin-lagringsmedier som er diskutert ovenfor og illustrert i figur 1 tilveiebringer lagring av datamaskinlesbare instruksjoner, datastrukturer, programmoduler og andre data for datamaskinen 110.1 figur 1, for eksempel, er harddiskstasjonen 141 vist som lagrende et operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147. Merk at disse komponentene enten kan være de samme som eller forskjellige fra operativsystem 134, applikasjonsprogrammer 135, andre programmoduler 136 og programdata 137. Operativsystem 144, applikasjonsprogrammer 145, andre programmoduler 146 og programdata 147 er gitt forskjellige referansenummer her for å illustrere det at de i det minste er forskjellige kopier. En bruker kan sende inn kommandoer og informasjon til datamaskinen 110 via innmatingsanordninger så som et tastatur 162 og en pekeranordning 161, vanligvis omfattende en mus, en styreball eller en berøringsmatte. Andre innmatingsanordninger (ikke vist) kan omfatte en mikrofon, styrespak, spillkontroll, parabolantenne, skanner eller liknende. Disse og andre innmatingsanordninger er ofte koplet til prosesseringsenheten 120 via et brukerinnmatingsgrensesnitt 160 som er koplet til systembussen 121, men kan også være tilkoplet via andre grensesnitt- og buss-struk-turer, så som en parallellport, en spillutgang eller en universell seriell buss (USB-port).

En monitor 191 eller en annen type skjermanordning er også koplet til systembussen 121 via et grensesnitt, så som et skjermkort 190. Et grafikk-grensesnitt 182, så som Northbridge, kan også være koplet til systembussen 121. Northbridge er et chipset som kommuniserer med CPU-enheten, eller vertsprosesseringsenheten 120, og tar ansvaret for akselerert grafikkport(AGP)-kommunikasjoner. Én eller flere grafikk-prosesseringsenheter (GPU-enheter) 184 kan kommunisere med grafikk-grensesnittet 182.1 denne henseende omfatter GPU-enhetene 184 generelt interne (on-chip) minne-lagre, så som registerlagre, og GPU-enhetene 184 kommuniserer med et videominne 186. GPU-enhetene 184 er imidlertid kun ett eksempel på en ko-prosessor, og det kan således være inkludert en rekke forskjellige ko-prosesseringsanordninger i datamaskinen 110. En monitor 191 eller en annen type skjermanordning er også koplet til systembussen 121 via et grensesnitt, så som et skjermkort 190, som i sin tur kan kommunisere med videominnet 186.1 tillegg til monitoren 191 kan datamaskiner også omfatte andre periferi-utmatingsanordninger så som høyttalere 197 og en skriver 196, som kan være tilkoplet via et periferienhet-utmatingsgrensesnitt 195.

Datamaskinen 110 kan operere i et nettverket miljø via logiske forbindelser til én eller flere fjerndatamaskiner, så som en fjerndatamaskin 180. Fjerndatamaskinen 180 kan være en personlig datamaskin, en server, en ruter, en nettverks-PC, en peer-anordning eller en annen vanlig nettverksnode, og omfatter typisk mange av eller alle de elementene som er beskrevet ovenfor i forbindelse med datamaskinen 110, selv om kun en minnelagringsanordning 181 er illustrert i figur 1. De logiske forbindelsene som er vist i figur 1 omfatter et lokalt nettverk (LAN) 171 og et regionalt nettverk (WAN) 173, men kan også omfatte andre typer nettverk. Slike nettverksmiljøer er vanlige i kontorer, bedriftsomspennende datanettverk, intranett og Internett.

Når den anvendes i et LAN-nettverksmiljø, er datamaskinen 110 forbundet til LAN 171 via et nettverksgrensesnitt eller nettverkskort 170. Når den anvendes i et WAN-nettverksmiljø, omfatter datamaskinen 110 typisk et modem 172 eller andre anordninger for å etablere kommunikasjon over WAN 173, for eksempel Internett. Modemet 172, som kan være internt eller eksternt, kan være koplet til systembussen 121 via bruker-innmatingsgrensesnittet 160 eller en annen dertil egnet mekanisme. I et nettverksmiljø kan programmoduler som er vist i forbindelse med datamaskinen 110, eller deler av disse, være lagret i den fjernlokaliserte minnelagringsanordningen. Som et eksempel, og uten begrensning, illustrerer figur 1 fjern-applikasjonsprogrammer 185 som lagret i minneanordningen 181. En vil forstå at de viste nettverksforbindelsene kun er eksempler, og at det kan anvendes andre mekanismer for å etablere en kommunikasjonslink mellom datamaskinene.

Fagmannen vil forstå at en datamaskin 110 eller en annen klientanordning kan anvendes som del av et datanettverk. I denne henseende passer foreliggende oppfinnelse for et hvilket som helst datasystem som omfatter et hvilket som helst antall minne-eller lagringsenheter og et hvilket som helst antall applikasjoner og prosesser som opptrer på tvers av et hvilket som helst antall lagringsenheter eller -volumer. Foreliggende oppfinnelse kan anvendes i et miljø med server-datamaskiner og klient-datamaskiner ut-plassert i et nettverksmiljø og som har fjernlokaliserte eller lokale lagringsenheter. Foreliggende oppfinnelse kan også anvendes i en alene-stående databehandlingsanordning som støtter programmeringsspråk-funksjonalitet, -interpretasjon og -eksekvering.

Distribuert databehandling letter deling av dataressurser og -tjenester ved direkte kommunikasjon mellom dataanordninger og -systemer. Disse ressursene og tjenestene omfatter utveksling av informasjon, bufferlagring og disklagring av filer. Distribuert databehandling utnytter nettverkskonnektivitet slik at klienter kan anvende sin kollektive kraft til nytte for hele virksomheten. I denne henseende kan en rekke forskjellige anordninger ha applikasjoner, objekter eller ressurser som kan interaktere for å tilveiebringe autenti-seringsteknikker ifølge foreliggende oppfinnelse for én eller flere pålitelige grafikk-pipeliner.

Figur 2 viser et skjematisk diagram av et eksempel på nettverket eller distribuert databehandlingsmiljø. Det distribuerte databehandlingsmiljøet omfatter databehandlingsobjekter 10a, 10b, osv. og databehandlingsobjekter eller-anordninger 110a, 110b, 110c, osv. Disse objektene kan omfatte programmer, metoder, datalagre, programmerbar logikk, osv. Objektene kan omfatte deler av samme eller forskjellige anordninger så som PDA-enheter, fjernsyn, MP3-spillere, fjernsyn, personlige datamaskiner, osv. Hvert objekt kan kommunisere med et annet objekt via kommunikasjonsnettverket 14. Dette nettverket kan selv omfatte andre databehandlingsobjekter og dataanordninger som tilveiebringer tjenester til systemet i figur 2. Ifølge et aspekt ved oppfinnelsen kan hvert objekt 10 eller 110 inneholde en applikasjon som vil kunne etterspørre autentiserings-teknikkene ifølge foreliggende oppfinnelse for én eller flere pålitelige grafikk-pipeliner.

Det kan også forstås at et objekt, så som 110c, kan befinne seg på en annen dataanordning 10 eller 110. Selv om det fysiske miljøet som er skildret viser de forbundede anordningene som datamaskiner, er således denne illustrasjonen bare et eksempel, og det fysiske miljøet kunne alternativt ha blitt vist eller beskrevet som omfattende forskjellige digitale anordninger så som PDA-enheter, fjernsyn, MP3-spillere, osv., programvare-objekter så som grensesnitt, COM-objekter, og liknende.

Det finnes en rekke systemer, komponenter og nettverkskonfigurasjoner som støtter distribuerte databehandlingsmiljøer. For eksempel kan datasystemer være forbundet via kablede eller trådløse systemer, via lokale eller regionale nettverk. For tiden er mange av nettverkene koplet til Internett, som tilveiebringer infrastruktur for bredt distribuert databehandling og omfatter mange forskjellige nettverk.

I hjemmenettverksmiljøer finnes det minst fire uensartede nettverkstransportmedier som hvert kan støtte en unik protokoll, så som kraftforsynings-, data- (både trådløse og i kabel), tale- (f.eks. telefon) og underholdningsmedier. De fleste styringsanordninger så som lysbrytere og husholdningsapparater for private hjem kan anvende kraftforsynings-linjen for konnektivitet. Datatjenester kan bringes inn i hjemmet via bredbånd (f.eks. enten DSL eller kabelmodem) og kan aksesseres innenfor hjemmet ved anvendelse av enten trådløs (f.eks. HomeRF eller 802.11b) eller kablet (f.eks. Home PNA, Cat 5, like-strømslinje) tilkopling. Taletrafikk kan bringes inn i hjemmet enten via kabler (f.eks. Cat 3) eller trådløst (f.eks. mobiltelefon), og kan bli distribuert innenfor hjemmet ved anvendelse av Cat 3 kabling. Underholdningsmedier kan bringes inn i hjemmet enten via satellitt eller kabel, og blir typisk distribuert innenfor hjemmet ved anvendelse av koaksialkabel. IEEE 1394 og DVI vokser også frem som digital sammenkopling for grupper av media-anordninger. Alle disse nettverksmiljøene og andre som kan oppstå som protokollstandarder kan være koplet sammen og danne et intranett som kan være forbundet med omverde-nen via Internett. Kort sagt eksisterer det en rekke uensartede kilder for lagring og over-føring av data, og følgelig vil, i fremtiden, dataanordninger kreve metoder for å beskytte innhold i alle deler av dataprosesserings-pipelinen.

Internett refererer i alminnelighet til den samlingen av nettverk og systemporter som anvender TCP/IP-settet av protokoller, som er velkjent for fagmannen. TCP/IP er et akronym for "Transport Control Protocol/lnterface Program". Internett kan beskrives som et system av geografisk distribuerte nettverk av fjernlokaliserte datamaskiner som er forbundet av datamaskiner som eksekverer nettverksprotokoller som gjør det mulig for brukere å interaktere og dele informasjon over nettverkene. Som følge av denne omfattende informasjonsdelingen har fjern-nettverk så som Internett hittil generelt utviklet seg til et åpent system for hvilket utviklere kan tilveiebringe programvare-applikasjoner for å utføre spesialiserte operasjoner eller tjenester, stort sett uten begrensning.

Nettverk-infrastrukturen muliggjør således et mangfold av nettverkstopologier så som klient/tjener, peer-til-peer eller hybridarkitekturer. En "klient" er et medlem av en klasse eller gruppe som anvender tjenestene fra en annen klasse eller gruppe til hvilken den ikke er relatert. Innenfor databehandling er en klient således en prosess, dvs. essen-sielt et sett av instruksjoner eller oppgaver, som etterspør en tjeneste som tilveiebringes av et annet program. Klientprosessen anvender den etterspurte tjenesten uten å måtte "kjenne til" funksjonsdetaljer vedrørende det andre programmet eller tjenesten selv. I en klient/tjener-arkitektur, spesielt et nettverket system, er en klient vanligvis en datamaskin som aksesserer delte nettverksressurser som tilveiebringes av en annen datamaskin, f.eks. en tjener. I eksempelet i figur 2 kan datamaskinene 110a, 110b, osv. betraktes som klienter og datamaskinene 10a, 10b, osv. kan betraktes som tjeneren, idet tjeneren 10a, 10b, osv. opprettholder dataene som da blir replikert i klient-datamaskinene 110a, 110b, osv.

En tjener er typisk et fjernlokalisert datasystem som kan aksesseres via et fjern-aksessnett så som Internett. Klientprosessen kan være aktiv i et første datamaskinsystem og tjenerprosessen kan være aktiv i et andre datamaskinsystem, som kommuni serer med hverandre over et kommunikasjonsmedium og på denne måte tilveiebringer distribuert funksjonalitet og gjør det mulig for flere klienter å utnytte tjenerens informa-sjonsamlingsevne.

Klient og tjener kommuniserer med hverandre ved anvendelse av den funksjonaliteten som tilveiebringes av et protokollag. For eksempel er HTTP (Hypertext-Transfer Protocol) en vanlig protokoll som blir anvendt i forbindelse med World-Wide-Web (WWW). En nettverksadresse, så som en URL (Universal Resource Locator) eller en IP (Internet Protocol)-adresse, blir typisk anvendt for å identifisere tjener- eller klient-datamaskinene for hverandre. Nettverksadressen kan refereres til som en URL-adresse. For eksempel kan kommunikasjon være tilveiebragt over et kommunikasjonsmedium. Spesielt kan klienten og tjeneren være koplet til hverandre via TCP/IP-forbindelser for høykapasitetskommunikasjon.

Figur 2 illustrerer således et eksempel på et nettverket eller distribuert miljø, med en tjener i kommunikasjon med klient-datamaskiner via et nettverk/en buss, der foreliggende oppfinnelse kan anvendes. Mer detaljert er et antall tjenere 10a, 10b, osv., innbyrdes forbundet via kommunikasjonsnettverk/buss 14, som kan være et LAN, et WAN, et intranett, Internett, osv., med et antall klienter eller fjernlokaliserte dataanordninger 110a, 110b,

110c, 11 Od, 11 Oe, osv., så som en flyttbar datamaskin, en håndholdt datamaskin, en tynn klient, et nettverket husholdningsapparat, eller en annen anordning, så som en videomaskin, en TV, en ovn, en lampe, en oppvarmer og liknende i henhold til foreliggende oppfinnelse. Det er således kontemplert at foreliggende oppfinnelse kan anvendes for en hvilken som helst databehandlingsanordning i forbindelse med hvilken det er ønskelig å prosessere, lagre eller rendre sikkert innhold fra en pålitelig kilde.

I et nettverksmiljø der kommunikasjonsnettverket/bussen 14 er Internett, kan for eksempel tjenerne 10 være web-servere med hvilke klientene 110a, 110b, 110c, 11 Od, 110e, osv. kommuniserer over en hvilken som helst av et antall kjente protokoller så som HTTP. Tjenerne 10 kan også tjene som klienter 110, som kan være karakteristisk for et distribuert databehandlingsmiljø. Kommunikasjoner kan gå via kabel eller være trådløse, etter ønske og egnethet. Klientanordningene 110 kan, men trenger ikke kommunisere via kommunikasjonsnettverk/buss 14, og kan være assosiert med uavhengige kommunika-sjonsanordninger. For eksempel, i tilfellet med en TV eller videomaskin, så kan det eventuelt være et nettverket aspekt ved styringen av denne. Hver klientdatamaskin 110 og tjenerdatamaskin 10 kan være tilveiebragt med forskjellige applikasjonsprogram-moduler eller objekter 135 og med forbindelser eller tilgang til forskjellige typer lagrings-elementer eller -objekter, på tvers av hvilke filer kan bli lagret eller til hvilke deler av filer kan bli lastet ned eller flyttet. Foreliggende oppfinnelse kan således anvendes i et data-nettverksmiljø som har klientdatamaskiner 110a, 110b, osv. som kan aksessere og interaktere med et datanettverk / en buss 14 og tjenerdatamaskiner 10a, 10b, osv. som kan interaktere med klientdatamaskiner 110a, 110b, osv., samt andre anordninger 111 og databaser 20.

Digital rettighetsforvaltning ( DRM) - Oversikt

Som kjent, og nå med henvisning til figur 11, er forvaltning og håndheving av digitale rettigheter sterkt ønskelig i forbindelse med digitalt innhold 12 så som digital lyd, digitale bilder, digital tekst, digitale data, digitale multimedier, osv., der dette digitale innholdet 12 skal distribueres til brukere. Når det mottas av brukeren, rendrer eller "spiller" denne brukeren det digitale innholdet ved hjelp av en passende rendringsanordning så som en media-avspiller på en personlig datamaskin 14 eller liknende.

En innholdseier eller -utvikler (i det følgende "eier") som distribuerer digitalt innhold 12 ønsker typisk å begrense hva brukeren skal kunne gjøre med dette distribuerte digitale innholdet 12. For eksempel kan innholdseieren ønske å hindre brukeren i å kopiere og re-distribuere innholdet 12 til en andre bruker, eller kan ønske å tillate distribuert digitalt innhold 12 å bli avspilt kun et begrenset antall ganger, kun for en gitt total tid, kun på en viss type maskin, kun på en viss type media-avspiller, kun av en viss type bruker, osv.

Etter at distribusjonen har funnet sted har en slik innholdseier veldig liten, om noen, kontroll over det digitale innholdet 12. Et DRM-system 10 muliggjør kontrollert rendring eller avspilling av vilkårlige former for digitalt innhold 12, idet denne kontrollen er fleksibel og kan defineres av eieren av det digitale innholdet. Innhold 12 blir typisk distribuert til brukeren i form av en pakke 13 via en hvilken som helst egnet distribusjons-kanal. Den distribuerte digitale innholdspakken 13 kan omfatte det digitale innholdet 12 kryptert med en symmetrisk krypterings / dekrypteringsnøkkel (KD), (dvs.

(KD(CONTENT))), så vel som annen informasjon som identifiserer innholdet, hvordan en kan oppnå en lisens for dette innholdet, osv.

Det tillitsbaserte DRM-systemet 10 gjør det mulig for en eier av digitalt innhold 12 å spesifisere lisensregler som må være oppfylt før dette digitale innholdet 12 tillates rendret på en brukers databehandlingsanordning 14. Slike lisensregler kan omfatte det ovennevnte tidsbaserte kravet, og kan være innlemmet i en digital lisens 16 som brukeren / brukerens databehandlingsanordning 14 (i det følgende anvendes disse betegnelsene om hverandre dersom ikke omstendighetene tilsier annet) må oppnå fra innholdseieren eller en agent for denne. En slik lisens 16 omfatter også dekrypterings-nøkkelen (KD) for å dekryptere det digitale innholdet, eventuelt kryptert med en nøkkel som kan dekrypteres av brukerens databehandlingsanordning.

Eieren av et stykke digitalt innhold 12 må stole på at brukerens databehandlingsanordning 14 vil rette seg etter de regler og krav som er spesifisert av denne innholdseieren i lisensen 16, dvs. at det digitale innholdet 12 ikke vil bli rendret dersom ikke reglene og kravene i lisensen 16 er oppfylt. Fortrinnsvis er brukerens databehandlingsanordning 14 derfor tilveiebragt med en pålitelig komponent eller mekanisme 18 som ikke vil rendre det digitale innholdet 12 bortsett fra i henhold til de lisensreglene som er omfattet i den lisensen 16 som er assosiert med det digitale innholdet 12 og oppnådd av brukeren.

Den pålitelige komponenten 18 omfatter typisk en lisensevaluator 20 som avgjør hvorvidt lisensen 16 er gyldig, går gjennom lisensreglene og -kravene i denne gyldige lisensen 16 og bestemmer basert på de gjennomgåtte lisensreglene og kravene hvorvidt den forespørrende brukeren har rettighet til å rendre det etterspurte digitale innholdet 12 på den søkte måten, blant annet. Som en forstår stoler DRM-systemet 10 på at lisensevaluatoren 20 utfører ønskene til eieren av det digitale innholdet 12 i henhold til reglene og kravene i lisensen 16, og brukeren må ikke på en enkel måte kunne endre et slik pålitelig element for noe formål, forbrytersk eller annet.

Som en forstår kan reglene og kravene i lisensen 16 spesifisere hvorvidt brukeren har rettighet til å rendre det digitale innholdet 12 basert på en hvilken som helst av mange faktorer, omfattende hvem brukeren er, hvor brukeren befinner seg, hva slags type databehandlingsanordning brukeren anvender, hvilken rendringsapplikasjon som kaller DRM-systemet, datoen, klokkeslettet, osv. I tillegg kan reglene og kravene i lisensen 16 begrense lisensen 16 for eksempel til et forbestemt antall avspillinger eller en forbestemt total avspillingstid.

Reglene og kravene kan være spesifisert i lisensen 16 med ethvert egnet språk og enhver syntaks. For eksempel kan språket ganske enkelt spesifisere attributter og verdier som må være oppfylt (f.eks. at DATO må være senere enn X), eller kan kreve utførelse av funksjoner i henhold til et spesifisert skript (f.eks. IF DATO større enn X, THEN DO...).

Når lisensevaluatoren 20 bestemmer at lisensen 16 er gyldig og at brukeren opp-fyller reglene og kravene i denne, kan det digitale innholdet 12 bli rendret. Spesielt, for å rendre innholdet 12, oppnås dekrypteringsnøkkelen (KD) fra lisensen 12 og anvendes på

(KD(CONTENT)) fra innholdspakken 13, slik at en oppnår det faktiske innholdet 12, og det faktiske innholdet 12 blir da rendret.

Publisering av digitalt innhold

Figur 3 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for å publisere digitalt innhold. "Publisering", som denne termen anvendes her, refererer til en prosess som en applikasjon eller tjeneste følger for å etablere med en pålitelig eller klarert entitet et sett av rettigheter og betingelser som entiteten kan utstede for dette innholdet, så vel som til hvem disse rettigheter og betingelser kan bli utstedt. Ifølge oppfinnelsen omfatter publiserings-prosessen det å kryptere det digitale innholdet og assosiere en liste av persistente hånd-hevbare rettigheter som forfatteren av innholdet har tiltenkt for alle mulige brukere av innholdet. Denne prosessen kan utføres på en sikker måte for å hindre aksess til noen av rettighetene eller til innholdet dersom dette ikke er tiltenkt av forfatteren av innholdet.

I en foretrukket utførelsesform av oppfinnelsen kan spesielt tre entiteter bli anvendt for å publisere sikkert digitalt innhold: en innholdsklargjøringsapplikasjon 302 som kjører på klienten 300 og klargjør innholdet for publisering, et DRM-(digital rights management)-API 306 som også befinner seg på klientanordningen 300 samt en DRM-server 320 som er kommuniserbart koplet til klienten 300 via et kommunikasjonsnettverk 330.1 en foretrukket utførelsesform av oppfinnelsen omfatter kommunikasjonsnettverket 330 Internett, selv om det må forstås at kommunikasjonsnettverket 330 vil kunne være et hvilket som helst lokalt eller regionalt nettverk, for eksempel et proprietært intranett.

Innholdsklargjøringsapplikasjonen 302 kan være en hvilken som helst applikasjon som produserer digitalt innhold. For eksempel kan applikasjonen 302 være en tekst-behandler eller en annen publiserer som produserer digitale tekstfiler, digital musikk, video eller annet slikt innhold. Innholdet kan også omfatte streamet innhold, så som streamet lyd/video for en "levende" hendelse eller et opptak. Ifølge oppfinnelsen ber innholdsklargjøringsapplikasjonen brukeren om å kryptere innholdet ved anvendelse av en nøkkel som brukeren tilveiebringer. Applikasjonen 302 anvender nøkkelen til å kryptere det digitale innholdet, og danner på denne måte en kryptert digital innholdsfil 304. Klientapplikasjonen ber også brukeren om å tilveiebringe rettighetsdata for den digitale innholdsfilen 304. Rettighetsdataene omfatter en respektiv identitet for hver entitet som har rettigheter vedrørende det digitale innholdet. En slik entitet kan for eksempel være et individ, en klasse av individer eller en anordning. For hver slik entitet omfatter rettighetsdataene også en liste av rettigheter som denne entiteten har vedrørende innholdet, samt hvilke som helst betingelser som kan være lagt på hvilke som helst av eller alle disse rettighetene. Slike rettigheter kan omfatte rettighet til å lese, redigere, kopiere, skrive ut, osv. det digitale innholdet. I tillegg kan rettigheter være inklusive eller eksklusive. Inklusive rettigheter angir at en spesifisert bruker har en spesifisert rettighet vedrørende innholdet { foreksempel at brukeren kan redigere det digitale innholdet). Eksklusive rettigheter angir at en spesifisert bruker har alle rettigheter vedrørende innholdet bortsett fra de som er spesifisert ( foreksempel kan brukeren gjøre hva som helst med det digitale innholdet bortsett fra å kopiere det).

I henhold til en utførelsesform av oppfinnelsen kan klient-API 306 sende det krypterte digitale innholdet og rettighetsdataene til DRM-serveren 320. Gjennom en prosess som er beskrevet i detalj nedenfor, bestemmer DRM-server 320 hvorvidt den kan håndheve de rettigheter som brukeren har overdratt, og i så fall signerer DRM-serveren 320 rettighetsdataene og danner et signert rettighetsmerke (SRL) 308. Generelt imidlertid, kan en hvilken som helst pålitelig entitet signere rettighetsdataene, fortrinnsvis ved anvendelse av en nøkkel som er klarert av DRM-serveren 320. For eksempel kan en klient signere rettighetsdataene ved anvendelse av en nøkkel som er tilveiebragt til den av DRM-serveren 320.

Rettighetsmerket 308 kan omfatte data som representerer rettighetsbeskrivelsen, den krypterte innholdsnøkkelen og den digitale signaturen over rettighetsbeskrivelsen og den krypterte innholdsnøkkelen. Dersom DRM-serveren signerer rettighetsmerket, sender den det signerte rettighetsmerket 308 tilbake til klienten gjennom klient-API 306, som lagrer det signerte rettighetsmerket 308 på klientanordningen 300. Innholdsklar- gjøringsapplikasjonen 302 assosierer da det signerte rettighetsmerket 308 med den krypterte digitale innholdsfilen 304. For eksempel kan SRL 308 bli sammenkjedet med den krypterte digitale innholdsfilen for å danne en rettighetsforvaltet innholdsfil 310. Generelt trenger imidlertid ikke rettighetsdataene være kombinert med det digitale innholdet. For eksempel vil rettighetsdataene kunne være lagret på et kjent sted, og en referanse til de lagrede rettighetsdataene kan være kombinert med det krypterte digitale innholdet. Referansen kan omfatte en identifikator som angir hvor rettighetsdataene er lagret { f. eks. datalageret som inneholder rettighetsdataene) samt en identifikator som svarer til disse konkrete rettighetsdataene i dette konkrete lagringsområdet (som f. eks. identifiserer filen som inneholder de aktuelle rettighetsdataene). Det rettighetsforvaltede innholdet 310 kan deretter bli levert til hvem som helst hvor som helst, og bare de entiteter som har rettighet til å konsumere innholdet kan konsumere innholdet, og bare i henhold til de rettigheter de er overdratt.

Figur 4 er et flytdiagram av et eksempel på fremgangsmåte 400 ifølge oppfinnelsen for å publisere rettighetsforvaltet digitalt innhold, der rettighetsmerket er signert av en DRM-server. Det skal imidlertid forstås at denne utførelsesformen kun er et eksempel, og at rettighetsmerket generelt kan være signert av en hvilken som helst klarert entitet. Generelt kan en fremgangsmåte ifølge oppfinnelsen for å publisere digitalt innhold omfatte det å: kryptere det digitale innholdet ved anvendelse av en innholdsnøkkel (CK), generere en rettighetsbeskrivelse assosiert med det digitale innholdet, kryptere innholds-nøkkelen (CK) med en fellesnøkkel for en DRM-server (PU-DRM), hvilket gir (PU-DRM(CK)), og generere en digital signatur basert på en privat nøkkel (PR-DRM) svarende til (PU-DRM) over kombinasjonen av rettighetsbeskrivelsen og (PU-DRM(CK)).

I trinn 402 genererer applikasjonen 302 en innholdsnøkkel (CK) som blir anvendt for å kryptere det digitale innholdet. Fortrinnsvis er innholdsnøkkelen (CK) en symmetrisk nøkkel, selv om generelt en hvilken som helst nøkkel kan anvendes for å kryptere det digitale innholdet. Symmetriske nøkkelalgoritmer, som noen ganger refereres til som "hemmelig nøkkel"-algoritmer, anvender samme nøkkel for å dekryptere en melding som for å kryptere meldingen. Av denne grunn er det foretrukket at (CK) holdes hemmelig. Delingen av (CK) mellom sender og mottaker må gjøres meget forsiktig for å unngå uautorisert oppsnapping av denne (CK). Ettersom (CK) er delt mellom den som krypterer og den som dekrypterer, blir (CK) fortrinnsvis kommunisert før noen krypterte meldinger blir overført.

Flere genereringsalgoritmer for symmetriske nøkler er velkjent på området. I en foretrukket utførelsesform anvendes Data Encryption Standard (DES), selv om en må forstå at en hvilken som helst symmetrisk algoritme vil kunne anvendes. Eksempler på slike symmetriske nøkkelalgoritmer omfatter, uten begrensning, Triple-DES, International Data Encryption Algorithm (IDEA), Cast, Cast-128, RC4, RC5 og SkipJack.

I trinn 404 krypterer applikasjonen 302 det digitale innholdet med den symmetriske innholdsnøkkelen (CK) for å danne kryptert digitalt innhold 304, som kan skrives med notasjonen (CK(content)). Forfatteren, ved anvendelse av applikasjonen 302, kan også generere rettighetsdata assosiert med det digitale innholdet. Rettighetsdataene kan omfatte en liste av entiteter som har rettighet til å konsumere innholdet og de spesifikke rettigheter som hver av entitetene innehar med hensyn til innholdet, sammen med eventuelle betingelser som kan være lagt på disse rettighetene. Slike rettigheter kan for eksempel omfatte det å vise innholdet, skrive ut innholdet, osv. Applikasjonen 302 tilveiebringer rettighetsdataene til API 306. Et eksempel på rettighetsdata i XML / XrML format er vedlagt i tillegg 1.

I trinn 406 genererer API 306 en andre krypteringsnøkkel (DES1), som anvendes for å kryptere innholdsnøkkelen (CK). Fortrinnsvis er (DES1) også en symmetrisk nøkkel. I trinn 408 krypterer API 306 (CK) med (DES1), hvilket resulterer i (DES1(CK)). I trinn 410 kaster API 306 (CK), med det resultat at (CK) nå bare kan oppnås ved å dekryptere (DES1 (CK)). For å sikre at (CK(content)) er beskyttet til en sentral DRM-server 320 og at alle "lisensforespørsler" vedrørende innholdet blir gjort sentralt i henhold til rettighetsdataene, kontakter API 306, i trinn 412, den tilveiebragte DRM-serveren 320 og henter dennes fellesnøkkel (PU-DRM). I trinn 414 krypterer API 306 (DES1) med (PU-DRM), hvilket resulterer i (PU-DRM (DES1)). På denne måte kan (CK) beskyttes til (PU-DRM)) for å sikre at DRM-serveren 320 er eneste entitet som vil være i stand til å oppnå tilgang til (CK), som er nødvendig for å dekryptere (CK(content)). I trinn 416 krypterer API 306 rettighetsdataene ( dvs. listen over autoriserte entiteter og de respektive rettigheter og betingelser assosiert med hver autoriserte entitet på listen) med (DES1), hvilket resulterer i (DESI(rightsdata)).

I en alternativ utførelsesform kan (CK) bli anvendt direkte for å kryptere rettighetsdataene, hvilket resulterer i (CK(rightsdata)), og med det foregå anvendelsen av (DES1) fullstendig. Anvendelse av (DES1) for å kryptere rettighetsdataene gjør imidlertid at denne (DES1) kan tilpasses en hvilken som helst spesifikk algoritme som kan være tilgjengelig for DRM-serveren, mens (CK) vil kunne være spesifisert av en entitet uavhengig av DRM-serveren og muligens ikke være like tilgjengelig for denne.

I trinn 418 kan innholdsbeskyttelsesapplikasjonen 302 sende (PU-DRM(DESI)) og (DESI(rightsdata)) til DRM-serveren 320 som et rettighetsmerke for signatur. Alternativt kan klienten selv signere rettighetsdataene. Dersom rettighetsdataene blir sendt til serveren for signering, aksesserer da, i trinn 420, DRM-serveren 320 rettighetsdataene og verifiserer at den kan håndheve rettighetene og betingelsene i det innsendte rettighetsmerket. For å verifisere at den kan håndheve rettighetsdataene, anvender DRM-serveren 320 (PR-DRM) på (PU-DRM(DESI)), hvilket resulterer i (DES1), og anvender deretter (DES1) på (DESI(rightsdata)), hvilket resulterer i rettighetsdataene i klartekst. Serveren 320 kan da utføre hvilke som helst regelsjekker for å verifisere at brukerne, rettighetene og betingelsene spesifisert i rettighetsdataene er innenfor det regelsettet som håndheves av serveren 320. Serveren 320 signerer det opprinnelig innsendte rettighetsmerket omfattende (PU-DRM(DESI)) og (DESI(rightsdata)), hvilket resulterer i det signerte rettighetsmerket (SRL) 308, idet signaturen er basert på den private nøkkelen til DRM-serveren 320 (PR-DRM), og returnerer SRL 308 tilbake til API 306 som da presenterer den returnerte SRL 308 for klientapplikasjonen 302.

SRL 308 er et digitalt signert dokument, hvilket gjør det sikkert mot integritets-krenkelser. I tillegg er SRL 308 uavhengig av den faktiske nøkkeltypen og algoritmen anvendt for å kryptere innholdet, men opprettholder den sterke 1-1 relasjonen til innholdet den beskytter. Nå med henvisning til figur 4A, i en utførelsesform av foreliggende oppfinnelse, kan SRL 308 omfatte informasjon vedrørende det innholdet som er grunn-laget for SRL 308, muligens omfattende en identifikator for innholdet; informasjon ved-rørende DRM-serveren som signerer SRL 308, omfattende (PU-DRM(DESI)) og henvisningsinformasjon så som en URL for å lokalisere DRM-serveren i et nettverk samt tilbakekallsinformasjon i tilfelle URL-adressen feiler; informasjon som beskriver SRL 308 selv; (DESI(rightsdata)): (DES1(CK)); og S (PR-DRM), blant annet. Et eksempel på SRL 308 skrevet i XML / XrML er vedlagt i Tillegg 2.

Ved å sikre at en pålitelig entitet signerer rettighetsdataene for å skape et signert rettighetsmerke 308, sikrer DRM-serveren at den vil utstede lisenser for innholdet i overensstemmelse med de betingelsene som er angitt av publisereren, som beskrevet i rettighetsdataene i rettighetsmerket 308. Som en forstår er en bruker nødt til å oppnå en lisens for å rendre innholdet, spesielt ettersom lisensen inneholder innholdsnøkkelen (CK). Når en bruker ønsker å oppnå en lisens for det krypterte innholdet, kan brukeren presentere en lisensforespørsel omfattende SRL 308 for innholdet og et sertifikat som verifiserer brukerens akkreditiver for DRM-serveren 320 eller en annen lisensutstedende entitet. Den lisensutstedende entiteten kan deretter dekryptere (PU-DRM(DESI)) og (DESI(rightsdata)) for å produsere rettighetsdataene, liste alle de rettigheter som er overdratt av forfatteren (hvis noen) for den lisensforespørrende entiteten og generere en lisens med kun disse spesifikke rettighetene.

Fortrinnsvis, når applikasjonen 302 mottar SRL 308, sammenkjeder applikasjonen 302 det signerte rettighetsmerket 308 med den motsvarende (CK(content)) 304 for å generere rettighetsforvaltet digitalt innhold. Alternativt kan rettighetsdataene lagres på et kjent sted, med en referanse til dette stedet tilveiebragt med det krypterte digitale innholdet. En rendringsapplikasjon som er DRM-bevisst kan således utforske det signerte rettighetsmerket 308 via det innholdet som rendringsapplikasjonen forsøker å rendre. Denne utforskingen trigger rendringsapplikasjonen til å initiere en lisensforespørsel til DRM-lisensserveren 320. Publiseringsapplikasjonen 302 kan for eksempel lagre en URL til DRM-lisensserveren 320, eller DRM-lisensserveren 320 kan innlemme sin egen URL i form av metadata i rettighetsmerket før den signerer dette digitalt, slik at den DRM-klient API-funksjonen 306 som blir kalt av rendringsapplikasjonen kan identifisere den korrekte DRM-lisensserveren 320. Fortrinnsvis legges det inn en unik identifikator, for eksempel

en globalt unik identifikator (GUID), i rettighetsmerket før det blir signert.

I en foretrukket utførelsesform av oppfinnelsen kan SOAP (simple object access protocol) bli anvendt for kommunikasjon mellom innholdsbeskyttelse-applikasjonen 302 eller rendringsapplikasjonen og DRM-serveren 320.1 tillegg kan det være tilveiebragt API-biblioteker, så som API 306, slik at applikasjoner så som applikasjonen 302 ikke trenger å implementere klientsiden av DRM-protokollen, men i stedet bare kan kalle lokale API-funksjoner. Fortrinnsvis blir XrML, et XML-språk, anvendt for å beskrive rettighetsbeskrivelser, lisenser og rettighetsmerker for digitalt innhold, selv om det må forstås at et hvilket som helst egnet format kan anvendes for rettighetsbeskrivelsen og andre data.

Oppnåelse av en lisens for det publiserte innholdet

Figur 5 er et funksjonelt blokkdiagram av en foretrukket utførelsesform av et system og en fremgangsmåte ifølge oppfinnelsen for å lisensiere rettighetsforvaltet digitalt innhold. "Lisensiering", som denne termen blir anvendt her, refererer til en prosess som en applikasjon eller tjeneste følger for å forespørre og motta en lisens som vil tillate en entitet som er angitt i lisensen å konsumere innholdet i overensstemmelse med de betingelsene som er spesifisert i lisensen. Inndata til lisensieringsprosessen kan omfatte det signerte rettighetsmerket (SRL) 308 som er assosiert med det innholdet for hvilket det etterspørres en lisens, samtfellesnøkkel-sertifikatet/sertifikatene til den eller de entitetene for hvilke lisensen blir etterspurt. Merk at den entiteten som ber om en lisens ikke nødvendigvis er den entiteten for hvilken lisensen etterspørres. En lisens omfatter typisk rettighetsbeskrivelsen fra SRL 308, en kryptert nøkkel som kan dekryptere det krypterte innholdet samt en digital signatur over rettighetsbeskrivelsen og den krypterte nøkkelen. Den digitale signaturen sikrer at de angitte entiteter og rettigheter er legitime.

Én måte for applikasjonen 302 å konsumere det rettighetsforvaltede innholdet 310 er at klient-API 306 videresender det signerte rettighetsmerket 308 for det rettighetsforvaltede innholdet 310 til DRM-serveren 320 via kommunikasjonsnettverket 330. Loka-sjonen til DRM-serveren 320 kan for eksempel finnes i henvisningsinformasjonen i SRL 308.1 en slik utførelsesform kan DRM-lisensserveren 320, via en prosess som er beskrevet i detalj nedenfor, anvende rettighetsbeskrivelsen i rettighetsmerket for å bestemme hvorvidt den kan utstede en lisens og, i så fall, for å avlede rettighetsbeskrivelsen som skal inkluderes med lisensen. Som beskrevet ovenfor inneholder rettighetsmerket 308 innholdsnøkkelen (CK) kryptert med fellesnøkkelen til DRM-serveren 320 (PU-DRM) ( dvs. (PU-DRM(CK))). I prosessen med å utstede en lisens dekrypterer DRM-serveren 320 på en sikker måte denne verdien for å oppnå (CK). Den anvender deretter fellesnøkkelen (PU-ENTITY) i det fellesnøkkel-sertifikatet som er sendt inn i lisensforespørselen til å rekryptere (CK) ( dvs. (PU-ENTITY(CK))). Den akkurat krypterte (PU-ENTITY(CK)) er hva serveren 320 plasserer i lisensen. Lisensen kan således bli returnert til kalleren uten risiko for å eksponere (CK), ettersom kun innehaveren av den assosierte private nøkkelen (PR-ENTITY) kan oppnå (CK) fra (PU-ENTITY(CK)).

Klient-API 306 anvender deretter (CK) for å dekryptere det krypterte innholdet for å generere dekryptert digitalt innhold 312. Klientapplikasjonen 302 kan da anvende det dekrypterte digitale innholdet 312 i henhold til de rettigheter som er overdratt i lisensen.

Alternativt kan en klient, for eksempel den publiserende klienten, utstede sin egen lisens for å konsumere innholdet. I en slik utførelsesform kan det bli kjørt en sikret prosess på klient-datamaskinen som tilveiebringer klienten med den eller de nøklene som er nødvendige for å dekryptere det digitale innholdet under legale omstendigheter.

Figurene 6A og 6B viser et flytdiagram av en foretrukket utførelsesform av en fremgangsmåte 600 ifølge oppfinnelsen for lisensiering av rettighetsforvaltet digitalt innhold. Ifølge oppfinnelsen kan en forespørrende entitet sende inn en lisensforespørsel på vegne av én eller flere potensielle lisensmottakere. Den forespørrende entiteten kan, men trenger ikke være én av de potensielle lisensmottakerne. En potensiell lisensmottaker kan være en person, en gruppe, en anordning eller enhver annen slik entitet som kan konsumere innholdet på en hvilken som helst måte. Fremgangsmåten 600 vil nå bli beskrevet i forbindelse med en utførelsesform der en DRM-server prosesser lisens-forespørselen, selv om det skal være underforstått at prosesseringen av lisensfore-spørselen også vil kunne bli utført på, og lisenser bli utstedt direkte av, klienten.

I trinn 602 mottar en lisensutstedende entitet, for eksempel en DRM-server, en lisensforespørsel. En lisensforespørsel omfatter fortrinnsvis enten et fellesnøkkel-sertifikat eller en identitet for hver av én eller flere entiteter for hvilke det bes om lisens. SOAP-protokollen for en foretrukket utførelsesform av en lisensforespørsel er:

I trinn 604 autentiseres den forespørrende entiteten { dvs. den entiteten som fremsetter lisensforespørselen). I henhold til en utførelsesform av oppfinnelsen kan den lisensutstedende entiteten være innrettet for å anvende protokoll { f. eks. challenge-response)-autentisering for å bestemme identiteten til den forespørrende entiteten, eller den kan være innrettet for ikke å kreve autentisering av den forespørrende entiteten (også kjent som å "tillate anonym autentisering"). Når autentisering er påkrevet kan en hvilken som helst type autentiseringsskjema bli anvendt { f. eks. challenge-response skjemaet nevnt ovenfor, et bruker-id-og-passord skjema så som MICROSOFT.NET, PASSPORT, WINDOWS Authorization, x509, osv.). Fortrinnsvis er anonym autentisering tillatt, samtidig som det er støtte for et hvilket som helst protokollautentiseringsskjema som støttes av integrerte informasjonssystemer. Resultatet av autentiseringstrinnet vil være en identitet, for eksempel en "anonym" identitet (for anonym autentisering) eller identiteten til en personlig konto. Dersom lisensforespørselen av en eller annen grunn ikke kan bli autentisert, blir det returnert en feil, og ingen lisens blir gitt.

I trinn 606 autoriseres den autentiserte entiteten - dvs. at det blir bestemt hvorvidt entiteten autentisert i trinn 608 har tillatelse til å be om en lisens (enten til seg selv eller på vegne av en annen entitet). Fortrinnsvis lagrer den lisensutstedende entiteten en liste over entiteter som tillates (eller ikke tillates) å be om en lisens. I en foretrukket utførelses-form er en identitet på denne listen av identiteter identiteten til den entiteten som frem setter forespørselen, heller enn identiteten til den entiteten for hvilken det bes om lisens, selv om begge er mulige. For eksempel kan en personlig konto-identitet ikke ha lov til å fremsette en lisensforespørsel direkte, men en pålitelig serverprosess kan fremsette en lisensforespørsel på vegne av en slik entitet.

Ifølge oppfinnelsen kan lisensforespørselen omfatte enten et fellesnøkkel-sertifikat eller en identitet for hver potensielle lisensmottaker. Dersom det spørres etter lisens for kun én lisensmottaker, er kun ett sertifikat eller én identitet angitt. Dersom det spørres etter lisens for flere lisensmottakere, kan et sertifikat eller en identitet være angitt for hver potensielle lisensmottaker.

Fortrinnsvis har den lisensutstedende entiteten et fellesnøkkel-sertifikat for hver gyldige lisensmottaker. Det kan imidlertid forekomme at en applikasjon 302 ønsker å generere en lisens for en gitt bruker for hvilken applikasjonen 302 ikke har tilgang til fellesnøkkel-sertifikatet. I et slikt tilfelle kan applikasjonen 302 spesifisere brukerens identitet i lisensforespørselen, og som følge av dette kan den lisensutstedende entiteten kalle opp en registrert sertifikat-innpluggingsmodul som sjekker med en katalogtjeneste og returnerer den aktuelle brukerens fellesnøkkel-sertifikat.

Dersom, i trinn 608, den utstedende entiteten detekterer at fellesnøkkel-sertifikatet ikke er inkludert i lisensforespørselen, anvender da den utstedende entiteten den spesifi-serte identiteten og sjekker med en katalogtjeneste eller i en database etter det aktuelle fellesnøkkel-sertifikatet. Dersom, i trinn 610, den utstedende entiteten fastslår at sertifikatet finnes i katalogen, hentes da sertifikatet i trinn 612.1 en foretrukket utførelses-form blir en sertifikat-innpluggingskomponent anvendt for å oppnå fellesnøkkel-sertifikater fra en katalogtjeneste via en katalogaksessprotokoll. Dersom et sertifikat ikke finnes for en gitt potensiell lisensmottaker, verken i forespørselen eller i katalogen, genererer ikke lisensserveren noen lisens for denne potensielle lisensmottakeren, og i trinn 614 blir en feil returnert til den forespørrende entiteten.

Antatt at den lisensutstedende entiteten har et fellesnøkkel-sertifikat for minst én potensiell lisensmottaker, validerer da, i trinn 616, den utstedende entiteten påliteligheten til lisenssertifikatene. Den utstedende entiteten er fortrinnsvis tilveiebragt med et sett av pålitelige sertifikatutstedersertifikater, og den bestemmer hvorvidt utstederen av lisenssertifikatet finnes på listen av pålitelige utstedere. Dersom, i trinn 616, den utstedende entiteten fastslår at utstederen av lisenssertifikatet ikke finnes på listen av pålitelige utstedere, avvises da forespørselen for denne lisensmottakeren, og det genereres en feil i trinn 614. På denne måte vil ingen potensiell lisensmottaker hvis sertifikat ikke er utstedt av en pålitelig utsteder motta en lisens.

I tillegg validerer den utstedende entiteten fortrinnsvis den digitale signaturen til alle entiteter i sertifikatkjeden, gående fra de pålitelige utstedersertifikatene til de individuelle lisensmottakernes fellesnøkkel-sertifikater. Prosessen med å validere de digitale signatu-rene i en kjede er en velkjent algoritme. Dersom fellesnøkkel-sertifikatet for en gitt potensiell lisensmottaker ikke er gyldig, eller et sertifikat i kjeden ikke er gyldig, blir ikke den potensielle lisensmottakeren klarert, og det utstedes derfor ikke noen lisens til denne potensielle lisensmottakeren. Ellers, i trinn 618, kan det utstedes en lisens. Prosessen gjentas fra trinn 620 inntil alle entiteter for hvilke det er bedt om en lisens er prosessert.

Som vist i figur 6B fortsetter den lisensutstedende entiteten med å validere det signerte rettighetsmerket 308 som er mottatt i lisensforespørselen. I en foretrukket utførelsesform kan den utstedende entiteten anvende en rettighetsmerke-innpluggingskomponent og en bakenforliggende database for å lagre på serveren en master-kopi av hvert rettighetsmerke som er signert av den utstedende entiteten. Rettighetsmerkene identifiseres av den GUID-en som ble tillagt dem ved publiseringen. Under lisensieringen (i trinn 622) parser den utstedende entiteten det rettighetsmerket som ble sendt inn med lisensforespørselen og henter ut GUID-en. Den sender deretter denne GUID-en til rettighetsmerke-innpluggingskomponenten, som retter en forespørsel til databasen for å hente ut en kopi av master-rettighetsmerket. Master-rettighetsmerket vil kunne være nyere enn den kopien av rettighetsmerket som ble sendt inn med lisensforespørselen, og det vil være dette rettighetsmerket som blir anvendt i forespørselen i trinnene nedenfor. Dersom intet rettighetsmerke blir funnet i databasen basert på GUID-en, sjekker den utstedende entiteten sitt regelsett, i trinn 624, for å bestemme hvorvidt den likevel tillates å utstede en lisens basert på rettighetsmerket i forespørselen. Dersom regelsettet ikke tillater dette, vil lisensforespørselen bli avvist i trinn 626, og en feil vil bli returnert til API 306 i trinn 628.

I trinn 630 validerer den lisensutstedende entiteten rettighetsmerket 308. Den digitale signaturen av rettighetsmerket blir validert og, dersom den lisensutstedende entiteten ikke er utstederen av rettighetsmerket (den entiteten som signerte den), avgjør da den lisensutstedende entiteten hvorvidt utstederen av rettighetsmerket er en annen pålitelig entitet ( f. eks. en entitet med hvilken den lisensutstedende entiteten tillates å dele nøkkelmateriale). Dersom rettighetsmerket ikke er gyldig eller den ikke er utstedt av en pålitelig entitet, avvises da lisensforespørselen i trinn 626, og en feil vil bli returnert til API 306 i trinn 628.

Etter at alle valideringer er utført konverterer den lisensutstedende entiteten rettighetsmerket 308 til en lisens for hver av de godkjente lisensmottakerne. I trinn 632 genererer den lisensutstedende entiteten en respektiv rettighetsbeskrivelse for den lisensen som skal utstedes til hver lisensmottaker. For hver lisensmottaker evaluerer den utstedende entiteten den identiteten som er angitt i fellesnøkkel-sertifikatet til denne lisensmottakeren mot de identitetene som er angitt i rettighetsbeskrivelsen i rettighetsmerket. Rettighetsbeskrivelsen tilordner til hver rettighet eller hvert sett av rettigheter et sett av identiteter som kan anvende denne rettigheten eller dette settet av rettigheter i en lisens. For hver rettighet eller hvert sett av rettigheter med hvilke denne lisensmottakerens identitet er assosiert, blir denne rettigheten eller dette settet av rettigheter kopiert inn i en ny datastruktur for lisensen. Den resulterende datastrukturen er rettighetsbeskrivelsen i lisensen for den spesifikke lisensmottakeren. Som del av denne prosessen evaluerer den lisensutstedende entiteten eventuelle betingelser som vil kunne være assosiert med hvilke som helst av rettighetene eller settene av rettigheter i rettighetsbeskrivelsen i rettighetsmerket. For eksempel kan en rettighet ha en tidsbetingelse assosiert med seg som hindrer den lisensutstedende entiteten i å utstede en lisens etter et spesifisert tidspunkt. I dette tilfellet vil den utstedende entiteten måtte sjekke den nå-værende tiden, og dersom det tidspunktet som er spesifisert i betingelsen har vært, vil ikke den utstedende entiteten kunne utstede denne rettigheten til lisensmottakeren selv om denne lisensmottakerens identitet er assosiert med denne rettigheten.

I trinn 636 tar den utstedende entiteten (PU-DRM(DESI)) og (DES1(CK))fra rettighetsmerket 308 og anvender (PR-DRM) for å oppnå (CK). Den utstedende entiteten rekrypterer deretter (CK) ved anvendelse av (PU-ENTITY) lisensmottakerens felles-nøkkel-sertifikat, hvilket resulterer i (PU-ENTITY(CK)). I trinn 638 sammenkjeder den utstedende entiteten den genererte rettighetsbeskrivelsen med (PU-ENTITY(CK)), og signerer digitalt den resulterende datastrukturen ved anvendelse av (PR-DRM). Denne signerte datastrukturen er lisensen for denne konkrete lisensmottakeren.

Når, i trinn 640, den utstedende entiteten fastslår at det ikke er flere lisenser å generere forden aktuelle forespørselen, vil den ha generert null eller flere lisenser. De genererte lisensene returneres til den forespørrende entiteten i trinn 642, sammen med sertifikatkjeden assosiert med disse lisensene ( f. eks. serverens eget fellesnøkkel-sertifikat så vel som det sertifikatet som utstedte dennes sertifikat, og så videre).

SOAP-protokollen for en foretrukket utførelsesform av en lisensrespons er som følger:

I en foretrukket utførelsesform av et system ifølge oppfinnelsen kan det anvendes flere lisensgivernøkler. I en slik utførelsesform kan den innholdsnøkkelen (CK) som blir sendt kryptert via rettighetsmerket 308 og inn i lisensen være hvilke som helst vilkårlige data. Én spesielt nyttig variasjon er å anvende flere separate, krypterte innholdsnøkler (CK), henholdsvis assosiert med forskjellige rettigheter eller forskjellige aktører i rettighetsbeskrivelsen. For eksempel vil de digitale versjonene av sanger på et album alle kunne være kryptert med forskjellige nøkler (CK). Disse nøklene (CK) ville være inkludert i samme rettighetsmerke, men én aktør kan ha rettighet til å spille én av sangene { f. eks. kan han eller hun bare ha rettighet til å oppnå den ene nøkkelen i sin lisens), mens en andre aktør kan ha rettighet til å spille alle sangene (hun eller han vil da ha rettighet til å oppnå alle nøklene i sin lisens).

Et system ifølge oppfinnelsen gir fortrinnsvis publiserende applikasjoner / brukere mulighet til å angi grupper eller klasser av lisensmottakere i et rettighetsmerke 308.1 en slik utførelsesform vil den lisensutstedende entiteten evaluere alle grupper / klasser som er angitt i rettighetsmerket for å bestemme hvorvidt den aktuelle lisensmottakerens identitet er medlem av disse gruppene / klassene. Dersom medlemskap i en angitt gruppe / klasse blir funnet, kan den utstedende entiteten legge til de rettighetene eller det settet av rettigheter som er assosiert med gruppen / klassen i den rettighetsbeskrivelse-datastrukturen som blir anvendt for lisensen.

I en foretrukket utførelsesform av oppfinnelsen støtter publiserings- og lisensierings-protokollgrensesnittene i DRM-serveren autentisering og autorisering av den kallende applikasjonen eller brukeren, og administrasjonskonsollen for DRM-serveren gir en administrator mulighet til å generere en aksesskontrolliste for både lisensierings- og publiseringsgrensesnittet. Dette gjør at kjøperen av serveren kan anvende regelsett under hvilke brukere/applikasjoner enten gis tillatelse til å publisere, lisensiere eller begge deler.

Modifisering eller re- publisering av det signerte rettighetsmerket 308

I en utførelsesform av foreliggende oppfinnelse kan SRL 308 bli "re-publisert" dersom brukeren av innholdet er gitt tilstrekkelig tillatelse til å gjøre dette. Med andre ord kan brukeren, om han eller hun har tillatelse, endre rettighetsdata i SRL 308. Merk at en slik

tillatelse til å endre rettighetsdataene bør gis med måte og skjønnsomt, spesielt ettersom en bruker med tillatelse til å endre rettighetsdataene kan innvilge seg selv utstrakte rettigheter med hensyn til det assosierte innholdet. En kan tenke seg at en slik bruker også vil kunne gi seg selv rettighet til å eksponere innholdet og formidle dette til alle og enhver.

Her blir tillatelse til å endre angitt ved å inkludere i rettighetsdataene i SRL 308 en angivelse om at en spesifikk bruker eller klasse av brukere faktisk kan endre eller "re-publisere" rettighetsdataene og rettighetsmerket 308. Når DRM-serveren 320 mottar en SRL 308 med en slik tillatelse i forbindelse med en forespørsel om en lisens, inkluderer DRM-serveren 320 i den etterspurte lisensen for brukeren den symmetriske nøkkelen (DES1) kryptert i henhold til brukerens fellesnøkkel (dvs. PU-ENTITY), hvilket resulterer i

(PU-ENTITY(DESI)).

For å editere rettighetsdataene i SRL 308, og nå med henvisning til figur 7, innhenter således brukeren (PU-ENTITY(DESI)) fra lisensen (trinn 701), anvender (PR-ENTITY) på denne for å oppnå (DES1) (trinn 703), innhenter (DESI(rightsdata)) fra SRL 308 (trinn 705) og anvender (DES1) på denne for å oppnå rettighetsdataene (trinn 707). Deretter endrer brukeren rettighetsdataene som ønsket (trinn 709), og sender inn de endrede rettighetsdataene til DRM-serveren 320 på måten beskrevet i forbindelse med figur 4 for å oppnå et signert rettighetsmerke 308 (trinn 711). Selvfølgelig er her det signerte rettighetsmerket 308 faktisk en re-publisert SRL 308, og følgelig, når SRL 308 mottas (trinn 713), stripper brukeren vekk den opprinnelige SRL 308 som er sammenkjedet med det assosierte innholdet (trinn 715) og sammenkjeder deretter den re-publiserte SRL 308 med dette innholdet (trinn 717).

Som en forstår gir således re-publisering av en SRL 308 en bruker mulighet til å oppdatere rettighetsdataene i SRL 308, omfattende rettigheter, betingelser og brukere, uten å måtte endre det assosierte innholdet. Spesielt krever ikke re-publisering rekryptering av det assosierte innholdet med en ny (CK). Re-publisering krever heller ikke at det genereres en ny SRL fra bunn av, spesielt ettersom den opprinnelige SRL 308 har mange elementer deri som kan kopieres til den nye SRL 308.

Selv- publisering av det signerte rettighetsmerket 308

I en utførelsesform av foreliggende oppfinnelse kan SRL 308 være signert av den forespørrende brukeren selv. Følgelig trenger ikke brukeren å kontakte DRM-serveren 320 for å oppnå en SRL 308 for et assosiert innhold. På grunn av dette kan selv-publisering også betegnes offline-publisering. I en slik utførelsesform kan en bruker måtte kontakte en DRM-server 320 for å be om en lisens basert på en slik selv-publisert SRL 308. En må også forstå at en publiserende entitet vil kunne tillates å utstede sine egne lisenser.

Spesielt, og nå med henvisning til figur 8, blir i utførelsesformen en bruker først gitt mulighet til å selv-publisere ved mottak fra en DRM-server 320 av et DRM-sertifikat 810 omfattende en fellesnøkkel (PU-CERT) og en motsvarende privat nøkkel (PR-CERT) kryptert i henhold til brukerens fellesnøkkel (PU-ENTITY), hvilket resulterer i (PU-ENTITY(PR-CERT)). Sertifikatet må være signert av den private nøkkelen til DRM-serveren 320 (PR-DRM), slik at denne DRM-serveren 320 kan verifisere denne, som vil bli beskrevet mer detaljert nedenfor. Som en forstår autoriserer DRM-sertifikatet 810 brukeren for selv-publisering. Som en også kan forstå er nøkkelparet (PU-CERT, PR-CERT) forskjellig fra (PU-ENTITY, PR-ENTITY), og blir anvendt spesifikt for selv-publisering. Merk at nøkkelparet (PU-CERT, PR-CERT) kan utelates, i hvilket tilfelle DRM-sertifikatet 810 bare omfatter brukerens fellesnøkkel (PU-ENTITY) og er signert av den private nøkkelen til DRM-serveren 320 (PR-DRM), slik at denne DRM-serveren 320 kan verifisere den.

Selv-publisering skiller seg fra publisering som vist i figur 4 i det at brukeren essen-sielt tar DRM-server 320 sin plass med hensyn til trinn som utføres av denne. Spesielt signerer brukeren det innsendte rettighetsmerket som omfatter (PU-DRM(DESI)) og

(DESI(rightsdata)) med (PR-CERT) som oppnådd fra DRM-sertifikatet 810 (dvs. S (PR-CERT)), hvilket resulterer i det signerte rettighetsmerket (SRL) 308. Som en forstår oppnår brukeren (PR-CERT) fra DRM-sertifikatet 810 ved å oppnå (PU-ENTITY(PR-CERT)) fra dette DRM-sertifikatet 810 og anvende (PR-ENTITY) på denne. Merk imidlertid at brukeren ikke kan verifisere at DRM-serveren 320 kan håndheve rettighetene i det innsendte rettighetsmerket, spesielt ettersom brukeren ikke besitter (PR-DRM) for å anvende på (PU-DRM(DESI)). Følgelig bør DRM-serveren 320 selv utføre verifikasjonen når det bes om en lisens basert på det selv-publiserte SRL 308.

Når brukeren selv-publiserer SRL 308, sammenkjeder brukeren denne selv-publiserte SRL 308 og DRM-sertifikatet 810 som ble anvendt for å generere dette med innholdet, og dette innholdet sammen med SRL 308 og DRM-sertifikatet 810 blir distribuert til en annen bruker. Deretter etterspør og oppnår den andre brukeren en lisens for innholdet fra DRM-serveren 320 på hovedsaklig samme måte som vist i figurene 6A og 6B. Her sender imidlertid den lisens-etterspørrende brukeren inn til DRM-serveren 320 både den selv-publiserte SRL 308 og DRM-sertifikatet 810 som sammenkjedet med innholdet. DRM-serveren 320 verifiserer da S (PR-DRM) i DRM-sertifikatet 810 basert på den mot svarende (PU-DRM), og oppnår (PU-CERT) fra DRM-sertifikatet 810. DRM-serveren 320 verifiserer deretter S (PR-CERT) i SRL 308 basert på den oppnådde (PU-CERT) og fortsetter som tidligere. Merk imidlertid at ettersom brukeren ikke verifiserte at DRM-serveren 320 kan håndheve rettighetene i SRL 308, og som ble angitt ovenfor, DRM-serveren 320 selv må utføre verifiseringen på dette tidspunktet.

Rettighetsmal

Som angitt ovenfor er en bruker gitt frihet til å generere nesten hvilke som helst variasjoner av eller typer rettighetsdata i et rettighetsmerke ved å definere brukere eller klasser av brukere, definere rettigheter for hver definerte bruker eller klasse av brukere og deretter definere eventuelle anvendelsesbetingelser. Det kan imidlertid være, hvilket er viktig, tungvint og repetitivt å gang på gang definere rettighetsdata for flere rettighetsmerker, spesielt når de samme brukere eller klasser av brukere, rettigheter og betingelser blir definert gang på gang for forskjellig innhold. En slik situasjon kan for eksempel forekomme i et bedrifts- eller kontormiljø, der en bruker gjentagelsesvis publiserer forskjellige innhold som skal deles med en gitt definert gruppe av brukere. I et slikt tilfelle, og i en utførelsesform av foreliggende oppfinnelse, blir det da generert en rettighetsmal som brukeren kan anvende gang etter gang i forbindelse med generering av rettighetsmerker, idet rettighetsmalen allerede omfatter deri et predefinert sett av brukere eller klasser av brukere, predefinerte rettigheter for hver definerte bruker eller klasse av brukere, samt predefinerte anvendelsesbetingelser.

I en utførelsesform av foreliggende oppfinnelse, og nå med henvisning til figur 9, omfatter en rettighetsmal 900 i det vesentlige samme rettighetsdata som vil bli funnet i et rettighetsmerke. Siden (DES1) ikke er kjent før innholdet er publisert, kan imidlertid ikke rettighetsdataene krypteres i henhold til denne (DES1), som er tilfelle i et rettighetsmerke. I en utførelsesform av foreliggende oppfinnelse blir derfor rettighetsmalen 900 med de ukrypterte rettighetsdataene sendt inn under kryptering av rettighetsdataene med (DES1) i trinn 416 i figur 4 for å generere (DESI(rightsdata)). Naturligvis blir rettighetsdataene innhentet fra den innsendte rettighetsmalen 900 før de blir kryptert på denne måten.

Det kan, men trenger ikke være tilfelle at DRM-serveren 320 og dennes felles-nøkkel (PU-DRM) er kjent når rettighetsmalen blir generert. Videre, selv om den er kjent, kan det, men trenger ikke, være tilfelle at det finnes flere DRM-servere 320 som hver har sin egen (PU-DRM). Ikke desto mindre, i tilfellet der DRM-serveren 320 og dennes felles-nøkkel (PU-DRM) er kjent når rettighetsmalen blir konstruert, og i tilfellet der kun én DRM-server 320 blir anvendt eller bare én DRM-server 320 skal anvendes i forbindelse med rettighetsmalen 900, kan denne rettighetsmalen også omfatte deri informasjon ved-rørende den DRM-serveren som skal signere et rettighetsmerke som blir generert fra rettighetsmalen 900, omfattende dennes fellesnøkkel (PU-DRM). Selv om denne (PU-DRM) opptrer i SRL 308 idet den krypterer (DES1) og danner (PU-DRM(DESI)), må det igjen forstås at (DES1) ikke er kjent før innholdet er publisert, og derfor kan ikke (PU-DRM) i rettighetsmalen 900 kryptere denne (DES1), hvilket er tilfelle for et rettighetsmerke. I en utførelsesform av foreliggende oppfinnelse blir derfor rettighetsmalen 900 med den ukrypterte (PU-DRM) sendt inn under kryptering av (DES1) med (PU-DRM) i trinn 414 i figur 4 for å generere (PU-DRM(DESI)). Naturligvis blir (PU-DRM) innhentet fra den innsendte rettighetsmalen 900 før den anvendes.

Videre kan i det ovennevnte tilfellet annen informasjon vedrørende DRM-serveren som kan være inkludert i rettighetsmalen også omfatte henvisningsinformasjon så som en URL for å lokalisere DRM-serveren i et nettverk, og tilbakekallsinformasjon i tilfelle URL-en feiler. I alle tilfeller kan rettighetsmalen blant annet også omfatte informasjon som beskriver rettighetsmalen 900 selv. Merk at rettighetsmalen 900 også kan ha plass til informasjon som er relevant for det innholdet som skal publiseres, så som informasjon som opptrer i et rettighetsmerke som er relevant for innholdet og/eller krypteringsnøklene (CK) og (DES1), selv om denne plassen ikke er nødvendig dersom en instans av rettighetsmalen ikke faktisk blir transformert til et rettighetsmerke.

Selv om rettighetsmalen 900 som hittil beskrevet primært er for brukerens be-kvemmelighet, må det også forstås at en bruker i enkelte tilfeller ikke bør ha ubegrenset frihet til å definere rettighetsdata i et rettighetsmerke, og en rettighetsmal 900 kan anvendes for å begrense rammen til eller typen av rettighetsmerker som kan bli generert. For eksempel, og spesielt i tilfellet med et bedrifts- eller kontormiljø, kan det være predefinert som en regel at en spesifikk bruker bare skal publisere innhold til en spesifikk klasse av brukere, eller at brukeren ikke skal publisere innhold til en spesifikk klasse av brukere. I alle tilfelle, og i en utførelsesform av foreliggende oppfinnelse, er en slik regel innlemmet som predefinerte rettighetsdata i én eller flere rettighetsmaler 900, og brukeren kan være restriktert til å anvende slike rettighetsmaler for å generere rettighetsmerker ved publise ring av innhold. Merk at en rettighetsmal eller en gruppe rettighetsmaler som er gjort tilgjengelig for en bruker for å spesifisere publiseringsregler for brukeren kan spesifisere en hvilken som helst type publiseringsregel uten å fjerne seg fra idéen bak og rammen til foreliggende oppfinnelse.

For å spesifisere en rettighetsmal 900 for en restriktert bruker eller liknende, og nå med henvisning til figur 10, konstruerer en administrator eller tilsvarende denne rettighetsmalen 900 ved å definere de predefinerte rettighetsdataene (trinn 1001) og definere hvilke som helst andre data som kan være nødvendige og hensiktsmessige, så som informasjon som er relevant for en konkret DRM-server 320 (trinn 1003). Merk at, for å effektuere rettighetsmalen for anvendelse av den restrikterte brukeren eller liknende, rettighetsmalen 900 må gjøres offisiell. Det vil si at rettighetsmalen 900 må kunne bli gjenkjent som en rettighetsmal som den restrikterte brukeren eller liknende kan anvende. Følgelig, i en utførelsesform av foreliggende oppfinnelse, blir rettighetsmalen som konstruert av administratoren eller tilsvarende sendt til DRM-serveren 320 for signering, idet slik signering gjør rettighetsmalen offisiell (trinn 1005).

Merk at den signerende DRM-serveren 320 er den DRM-serveren 320 hvis informasjon finnes i rettighetsmalen 900, dersom slik informasjon faktisk i finnes i rettighetsmalen 900. Merk også at DRM-serveren 320 kan signere rettighetsmalen 900 bare etter å ha utført alle nødvendige sjekker, eller kan signere uten noen sjekker i det hele tatt. Merk til slutt at mal-signaturen S (PR-DRM-T) (der -T angir at signaturen er for ORT 900) fra DRM-serveren bør være basert i hvert fall på de predefinerte rettighetsdataene i rettighetsmalen 900, men den kan også være basert på annen informasjon uten å fjerne seg fra idéen bak og rammen til foreliggende oppfinnelse. Som beskrevet nedenfor vil signaturen S (PR-DRM-T) være innlemmet i et rettighetsmerke og vil bli verifisert i forbindelse med dette, og følgelig må også det som signaturen er basert innlemmes i rettighetsmerket i en uendret form.

Når DRM-serveren 320 signerer rettighetsmalen 900 og returnerer denne til administratoren eller tilsvarende, mottar administratoren den signerte og nå offisielle rettighetsmalen 900 med S (PR-DRM-T) (trinn 1007) og videresender den offisielle rettighetsmalen (ORT) 900 til én eller flere brukere for anvendelse av disse (trinn 1009). Følgelig, for at en bruker skal kunne publisere innhold basert på en ORT 900, henter brukeren ORT 900 (trinn 1011) og genererer et rettighetsmerke basert på ORT 900 (trinn 1013) ved å tilveiebringe all nødvendig informasjon, så som informasjon vedrørende innholdet, passende nøkkelinformasjon, rettighetsdataene fra ORT 900 kryptert med (DES1) for å oppnå (DESI(rightsdata)), og hvilken som helst annen informasjon fra ORT 900. Merk at brukeren også inkluderer med rettighetsmerket signaturen S (PR-DRM-T) fra ORT 900.

Deretter, og som tidligere, sender brukeren inn rettighetsmerket til DRM-serveren 320 for signering (trinn 1015). Her vil imidlertid ikke DRM-serveren 320 signere det innsendte rettighetsmerket dersom ikke S (PR-DRM-T) deri verifiserer. Det vil si at DRM-serveren 320 påtvinger at brukeren må basere det innsendte rettighetsmerket på en ORT 900 ved å nekte å signere det innsendte rettighetsmerket hvis ikke dette innsendte rettighetsmerket omfatter en signatur S (PR-DRM-T) fra en ORT 900. Spesielt innhenter DRM-serveren 320 denne S (PR-DRM-T) og den informasjonen som denne signaturen er basert på fra det innsendte rettighetsmerket, og verifiserer deretter denne signaturen basert på (PU-DRM). Merk at rettighetsdataene i det innsendte rettighetsmerket er kryptert med (DES1) (dvs. (DESI(rightsdata)). Følgelig må DRM-serveren 320 først oppnå (DES1) og dekryptere (DESI(rightsdata)) med denne, som beskrevet ovenfor i forbindelse med figur 7, for å være i stand til å verifisere signaturen basert på rettighetsdataene i det innsendte rettighetsmerket.

Når den er verifisert, signerer DRM-serveren 320 det innsendte rettighetsmerket

med S (PR-DRM-L) for å generere en SRL 308, som tidligere (idet -L angir at signaturen er for SRL 308). Her kan S (PR-DRM-L) erstatte S (PR-DRM-T), eller kan være i tillegg til denne S (PR-DRM-T). Dersom i tillegg, kan S (PR-DRM-L) være basert delvis på S (PR-DRM-T). Merk at (PR-DRM) kan anvendes for å generere både S (PR-DRM-T) og S (PR-DRM-L), eller at forskjellige (PR-DRM) kan anvendes for hver av S (PR-DRM-T) og S (PR-DRM-L). Når DRM-serveren 320 signerer rettighetsmerket og returnerer SRL 308 til brukeren, mottar brukeren SRL 308 med S (PR-DRM-L) (trinn 1017) og fortsetter med å sammenkjede denne med innholdet som blir publisert, som tidligere.

Dersom signaturen S (PR-DRM-T) for ORT 900 er basert i hvert fall delvis på de predefinerte rettighetsdataene i ORT 900, kan da ikke disse rettighetsdataene som de forekommer i SRL 308 (i DESI(rightsdata)) modifiseres eller varieres. Ellers vil ikke S (PR-DRM-T) verifisere. Allikevel, i en utførelsesform av oppfinnelsen, kan rettighetsdataene i ORT 900 variere innenfor foreskrevne regler som også er inkludert i ORT 900. For eksempel kan reglene spesifisere ett av to sett av rettighetsdata som skal inkluderes i en SRL 308, eller kan tillate valg fra et sett av alternativer. Som en forstår kan reglene være hvilke som helst regler beskrevet med en hvilken som helst passende syntaks uten å avgå fra idéen bak og rammen til foreliggende oppfinnelse. Her blir reglene interpretert av en passende regel-interpreterer for brukeren når rettighetsmerket blir generert. Selv om rettighetsdataene kan variere, kan ikke reglene variere på samme måte, og følgelig er mal-signaturen S (PR-DRM-T) for ORT 900 basert i hvert fall delvis på reglene og ikke på rettighetsdataene selv. Som følge av dette må reglene som er omfattet i ORT 900 også være omfattet i SRL 308.

I en utførelsesform av foreliggende oppfinnelse er de predefinerte rettighetsdataene i ORT 900 delvis fikserte og invariante og delvis variable og regeldrevne, som angitt ovenfor. I dette tilfellet er mal-signaturen S (PR-DRM-T) for ORT 900 basert i hvert fall delvis på den fikserte andelen av reglene og på reglene for den variable andelen av rettighetsdataene.

Som en forstår kan en ORT 900 som innehas av en bruker være foreldet eller utdatert. Det vil si at ORT 900 gjennom rettighetsdataene deri vil kunne reflektere regler som er utdaterte, irrelevante eller ganske enkelt ikke gjelder lenger. For eksempel er det mulig at én eller flere brukere eller klasser av brukere som er spesifisert i rettighetsdataene i ORT 900 ikke lenger eksisterer i regelmiljøet, eller at en spesifikk bruker eller klasse av brukere som er spesifisert i rettighetsdataene i ORT 900 ikke lenger har samme rettigheter innenfor regelmiljøet. I et slikt tilfelle kan det være at administratoren har utstedt en oppdatert ORT 900, men at brukeren fortsatt anvender en eldre, utdatert versjon av ORT 900.

I en slik situasjon, og i en utførelsesform av foreliggende oppfinnelse, tar derfor DRM-serveren 320, når den signerer en innsendt rettighetsmal 900 for å generere en ORT 900, vare på en kopi av ORT 900, idet hver ORT 900 har en unik identifikator og hvert rettighetsmerke som er generert basert på en ORT 900 omfatter identifikatoren for denne ORT 900 deri. Følgelig, når den mottar et innsendt rettighetsmerke så som i forbindelse med figur 10, finner DRM-serveren 320 identifikatoren for ORT 900 i rettighetsmerket, henter ut den mest oppdaterte kopien av denne ORT 900 basert på den funnede identifikatoren, fjerner rettighetsdataene fra det innsendte rettighetsmerket, legger inn rettighetsdataene fra den oppnådde ORT 900, og signerer deretter rettighetsmerket basert i hvert fall delvis på de innlagte rettighetsdataene. Selvfølgelig utfører DRM-serveren også alle nødvendige krypterings- og dekrypteringstrinn som er påkrevde og påhvilende fremgangsmåten som beskrevet, inklusive dekryptering og rekryptering av (DESI(rightsdata)). Merk at dersom DRM-serveren er innrettet for å erstatte rettighetsdataene i et innsendt rettighetsmerke, dette rettighetsmerket og den ORT 900 fra hvilken dette rettighetsmerket er generert ikke nødvendigvis trenger å omfatte rettighetsdataene deri. I stedet trenger rettighetsdataene bare å være lagret i DRM-serveren 320. Det å inkludere rettighetsdataene med rettighetsmerket og den ORT 900 fra hvilken dette rettighetsmerket er generert vil imidlertid kunne være til nytte for brukeren, og kan derfor være hensiktsmessig i enkelte tilfeller.

Konklusjon

Den programmeringen som er nødvendig for å effektuere prosessene som utføres i forbindelse med foreliggende oppfinnelse er relativt enkel, og skulle være åpenbar for den relevante programmerer. Følgelig er ikke denne programmeringen vedlagt denne søknaden. En hvilken som helst spesifikk programmering kan derfor anvendes for å virkeliggjøre foreliggende oppfinnelse uten at en fjerner seg fra dennes idé og ramme.

Det er således beskrevet systemer og fremgangsmåter for å utstede brukerlisenser for digitalt innhold og tjenester ved hjelp av et signert rettighetsmerke. Fagmannen vil forstå at en rekke endringer og modifikasjoner kan gjøres av de foretrukne utførelses-formene av oppfinnelsen, og at slike endringer og modifikasjoner kan foretas innenfor oppfinnelsens ramme og idé. Intensjonen er derfor at de etterfølgende patentkrav skal dekke alle slike ekvivalente variasjoner som faller innenfor oppfinnelsens virkelige idé og ramme.

Claims

1. Fremgangsmåte for å tilveiebringe et signert rettighetsmerke (SRL) i et digitalt rettighetsforvaltnings- (DRM-) system omfattende minst én klientanordning, en lisensserver og flere brukerentiteter, hvor fremgangsmåten omfatter følgende trinn: å tilveiebringe, ved hjelp av lisensserveren, en offisiell rettighetsmal (ORT) omfattende: i) predefinerte rettighetsdata innbefattende deri et predefinert sett av brukere eller klasser av brukere, predefinerte rettigheter for hver definert bruker eller klasse av brukere og predefinerte brukerbetingelser, og ii) en digital signatur S (PR-DRM-T) fra lisensserveren basert på en privat nøkkel (PR-DRM) til lisensserveren og basert i hvert fall delvis på rettighetsdataene, idet rettighetsdataene definerer rettigheter for å rendre digitalt innhold for hver av i det minste en del av flertallet av brukerentiteter; å kryptere, ved hjelp av en klientanordning, digitalt innhold i henhold til en innholdsnøkkel (CK) for å oppnå eller resultere i CK(content); å generere, ved hjelp av klientanordningen, en symmetrisk nøkkel (DES1); å kryptere, ved hjelp av klientanordningen, CK i henhold til DES1 for å oppnå eller resultere i DES1(CK); å kryptere, ved hjelp av klientanordningen, DES1 i henhold til en fellesnøkkel for lisensserveren (PU-DRM) for å oppnå eller resultere i PU-DRM(DESI), hvorpå lisensserveren kan aksessere CK med PR-DRM; å innhente, ved hjelp av klientanordningen, en offisiell rettighetsmal; å innhente, ved hjelp av klientanordningen, rettighetsdataene og den digitale signaturen fra rettighetsmalen; å kryptere, ved hjelp av klientanordningen, rettighetsdataene i henhold til DES1 for å oppnå eller resultere i DES1 (rightsdata); å fremlegge eller sende inn, ved hjelp av klientanordningen, de krypterte rettighetsdataene og den krypterte innholdsnøkkelen (CK) og den krypterte symmetriske nøkkel og den digitale signaturen som et rettighetsmerke til lisensserveren; å bestemme, ved hjelp av lisensserveren, hvorvidt rettighetsmerket er valid eller gyldig ved å verifisere den digitale signaturen S (PR-DRM-T) i rettighetsmerket og å utføre en første sjekk ved å verifisere at rettighetsdataene i rettighetsmerket er rettet etter en politikk eller regel påtvunget av lisensserveren, og, hvis valid eller gyldig, å frembringe en digital signatur basert på den private nøkkelen (PR-DRM) og basert i hvert fall delvis på de beskyttede rettighetsdataene, for å resultere i et signert rettighetsmerke (SRL), og å returnere nevnte SRL til klientanordningen; å motta, ved lisensserveren, nevnte SRL og en forespørsel om en lisens som svarer til innholdet; og å bestemme, ved hjelp av lisensserveren, hvorvidt å utstede lisensen ved å verifisere signaturen til nevnte SRL basert på PU-DRM og basert i hvert fall delvis på de beskyttede rettighetsdataene og å utføre en andre sjekk ved å verifisere at rettighetsdataene i nevnte SRL er rettet etter politikken eller regelen påtvunget av lisensserveren, hvor de beskyttede rettighetsdataene i nevnte SRL aksesseres og undersøkes av lisensserveren for å avgjøre eller bestemme hvorvidt brukeren eller klassen av brukere har rettighet til lisensen, og hvis gyldig eller valid å utstede lisensen, idet lisensen omfatter CK i en beskyttet form.

2. Fremgangsmåte ifølge krav 1, videre omfattende trinnene med å motta den returnerte SRL og å sammenkjede den mottatte SRL med CK(content) for å danne en innholdspakke.

3. Fremgangsmåte ifølge krav 2, videre omfattende trinnet med å distribuere innholdspakken til én eller flere brukerentiteter, hvorved en brukerentitet som ønsker å rendre innholdet innhenter nevnte SRL fra innholdspakken og sender inn eller legger frem nevnte mottatte SRL til lisensserveren som del av forespørselen om lisensen.

4. Fremgangsmåte ifølge et av krav 1-3, videre omfattende trinnet med å kaste CK etter å ha kryptert CK i henhold til DES1 for å oppnå eller resultere i DES1(CK), hvorved CK kun kan oppnås ved å dekryptere DES1(CK).

5. Fremgangsmåte ifølge et av krav 1-4, omfattende trinnet med å kryptere innholdet i henhold til en symmetrisk innholdsnøkkel (CK) for å oppnå eller resultere i CK(content).

6. Fremgangsmåte ifølge et av krav 1-5, omfattende trinnet med å innhente fra rettighetsmalen rettighetsdata omfattende hver brukerentitet som har rett til å rendre innholdet og for hver brukerentitet hver rettighet som brukerentiteten innehar med hensyn til rendring av innholdet, idet hver brukerentitet omfatter én av: en bruker og en klasse av brukere.

7. Fremgangsmåte ifølge krav 6, omfattende trinnet med å innhente fra rettighetsmalen rettighetsdata omfattende for hver av brukerentitetene i hvert fall noen av rettighetene som brukerentiteten innehar med hensyn til rendring av innholdet, en betingelse for å anvende denne rettigheten.

8. Fremgangsmåte ifølge et av krav 1-7, omfattende trinnet med å sende inn eller legge frem de krypterte rettighetsdataene, den krypterte innholdsnøkkelen (CK)) og informasjon vedrørende innholdet omfattende en identifikator for dette som rettighetsmerket til lisensserveren for signering.

9. Fremgangsmåte ifølge et av krav 1-8, hvor lisensserveren legger til i rettighetsmerket informasjon vedrørende lisensserveren omfattende adresseinformasjon for å lokalisere lisensserveren og returnerer nevnte SRL omfattende informasjonen ved-rørende serveren, og hvor fremgangsmåten omfatter trinnet med å motta den returnerte SRL omfattende informasjonen om serveren.

10. Fremgangsmåte ifølge et av krav 1-9, videre omfattende trinnet med å innhente PU-DRM fra rettighetsmalen.

11. Fremgangsmåte ifølge et av krav 1-10, videre omfattende trinnet med å innhente fra rettighetsmalen informasjon vedrørende lisensserveren omfattende adresseinformasjon for å lokalisere lisensserveren og med å returnere nevnte SRL omfattende informasjonen vedrørende serveren, og omfattende trinnet med å sende inn eller legge frem de krypterte rettighetsdataene, den krypterte innholdsnøkkelen (CK)) og informasjonen vedrørende lisensserveren som rettighetsmerket til lisensserveren for signering.

12. Fremgangsmåte ifølge krav 1, hvor rettighetsdataene i nevnte SRL kan modifiseres i forhold til rettighetsdataene i nevnte ORT i henhold til ikke-modifiserbare obligatoriske regler inkludert i nevnte ORT, og hvor nevnte ORT omfatter en digital signatur fra lisensserveren basert på PR-DRM og basert i hvert fall delvis på reglene S (PR-DRM-T), og hvor fremgangsmåten videre omfatter trinnene med å: innhente rettighetsmalen og innhente rettighetsdataene og reglene fra rettighetsmalen; modifisere de innhentede rettighetsdataene; beskytte reglene i henhold til PU-DRM; sende inn eller fremlegge S (PR-DRM-T), de beskyttede reglene, den krypterte innholdsnøkkelen (CK)) og de modifiserte rettighetsdataene som et rettighetsmerke til lisensserveren for signering, idet lisensserveren verifiserer S (PR-DRM-T) og, dersom verifisert, validerer rettighetsmerket og, dersom dette er gyldig eller valid, genererer eller danner en digital signatur basert på en privat nøkkel (PR-DRM) som svarer til PU-DRM og basert i hvert fall delvis på de beskyttede rettighetsdataene, hvilket gir eller resulterer i et signert rettighetsmerke (SRL), og returnerer nevnte SRL.

13. Fremgangsmåte ifølge krav 1, hvor klientanordningen mottar den returnerte SRL, sammenkjeder nevnte mottatte SRL med CK(content) for å danne en innholdspakke og distribuerer innholdspakken til den ene eller de flere brukerentitetene, hvorved en brukerentiet som ønsker å rendre innholdet, innhenter nevnte SRL fra innholdspakken og sender inn eller legger frem nevnte innhentede SRL til lisensserveren som del av en forespørsel om lisensen som svarer til innholdet, hvorpå lisensserveren verifiserer S (PR-DRM-L) basert på PU-DRM og basert i hvert fall delvis på de krypterte rettighetsdataene, aksesserer de krypterte rettighetsdataene i nevnte SRL og undersøker disse for å avgjøre eller bestemme hvorvidt brukerentiteten har rett til lisensen, og i så fall utsteder lisensen til brukerentiteten, idet lisensen omfatter CK i en beskyttet form som kan aksesseres av brukerentiteten.

14. Fremgangsmåte ifølge krav 13, videre omfattende trinnet med å verifisere S (PR-DRM-T), og dersom S (PR-DRM-T) verifiseres og rettighetsmerket er gyldig eller valid å generere eller danne S (PR-DRM-L).

15. Fremgangsmåte ifølge krav 14, hvor verifiseringen av S (PR-DRM-T) omfatter følgende trinn: å anvende PR-DRM på PU-DRM(DES1) for å oppnå eller resultere i DES1; å anvende DES1 på DESI(rightsdata) for å oppnå eller resultere i rettighetsdataene; og å anvende PU-DRM på S (PR-DRM-T) for å verifisere disse basert på de resulterende rettighetsdataene.

16. Fremgangsmåte ifølge et av krav 1-15, hvor lisensserveren innehar en oppdatert kopi av nevnte ORT, og fremgangsmåten omfatter, dersom S (PR-DRM-T) verifiseres og rettighetsmerket er gyldig eller valid, trinnene med å: innhente den oppdaterte kopien av nevnte ORT; innhente rettighetsdataene fra nevnte innhentede ORT; beskytte rettighetsdataene fra nevnte innhentede ORT i henhold til PU-DRM; fjerne fra det mottatte rettighetsmerket de beskyttede rettighetsdataene deri; legge inn i det mottatte rettighetsmerket de beskyttede rettighetsdataene fra nevnte innhentede ORT; generere eller danne en digital signatur basert på PR-DRM og basert i hvert fall delvis på de innlagte beskyttede rettighetsdataene S (PR-DRM-L); vedlegge S (PR-DRM-L) til det mottatte rettighetsmerket for å oppnå eller resultere i det signerte rettighetsmerket (SRL); og returnere nevnte SRL. Eksempel på rettighetsdata Eksempel på rettighetsmerke (SRL) 308