NO339560B1 - Fremgangsmåter for sikre mediabaner, systemer, samt arkitekturer - Google Patents

Description

Foreliggende oppfinnelse vedrører fremgangsmåter og systemer for prosessering av gjengivbare digitale data, så som videodata, lyd/videodata og liknende. Spesielt vedrører oppfinnelsen fremgangsmåter og systemer for å beskytte digitale data.

WO 01/52020 A1 vedrører offentliggjøring eller frigjøring av dekryptert digitalt innhold til en autentisert bane.

Det å beskytte eierskapet til digitalt innhold, så som multimedia-innhold og liknende, og bruksrettighetene for autoriserte brukere av slikt innhold, har over de senere år blitt meget viktig. Viktigheten av det å beskytte slikt innhold vil nødvendig-vis fortsette å vokse etter hvert som innholdet blir enklere å distribuere, spesielt i datanettverksmiljøer så som Internett.

Det er mange scenarier som kan dra fordeler av og vokse frem fra teknikker for å beskytte innhold. Foreksempel kan leverandører av film-innhold på en enklere måte selge innhold direkte til individer når leverandørene er sikre på at deres innhold vil være beskyttet. I tillegg kan brukere på en enklere og mer hensiktsmessig måte motta innhold fra abonnement-type tjenester (så som kabel TV leverandører, pay-per-view digitale satellitter og liknende). Videre kan brukere lagre og spille av innhold ved et senere tidspunkt eller lage kopier til seg selv, mens det fortsatt sikres at innholdseierens rettigheter fortsatt opprettholdes. I tillegg kan brukere skape sitt eget innhold og vite at de kan begrense hvem som kan se det. For eksempel vil en bruker kunne legge ut private hjemmevideoer på et web-område og kun tillate andre familiemedlemmer å se det i en begrenset tidsperiode.

Når innhold sendes til en anordning og spilles for en bruker, er det typisk nød-vendig med en veldefinert arkitektur (med både programvare- og maskinvare-komponenter) for å koordinere avspillingen og for å sikre at digitale rettigheter er beskyttet og blir overholdt. Ofte overføres beskyttet innhold til en brukers anordning (f.eks. en beregningsanordning, en set-top boks og liknende) fra en innholdskilde så som en video-webtjener eller også fra en lokal diskstasjon. Innholdet kan typisk være innkodet eller komprimert og kryptert hos innholdskilden. Senere dekrypterer brukerens anordning innholdet, dekomprimerer det og viser frem eller på annen måte gjengir innholdet for brukeren på, for eksempel, en monitor og/eller høyttalere.

Innhold blir typisk beskyttet ved anvendelse av DRM (Digital-Rights-Manage-ment)-teknikker som fortløpende utvides og utvikles. DRM-teknikker anvender typisk programvare som muliggjør sikker distribusjon og, kanskje enda viktigere, hindrer illegal distribusjon av betalt innhold over et nettverk så som Internett. Nåværende DRM-utvikling har fokusert primært på å sikre lyd-innhold. Etter hvert som nettverkenes båndbredde øker, vil imidlertid det å distribuere video direkte til sluttbrukere bli teknisk effektivt og mulig. Verdifullt digitalt innhold blir også mer og mer tilgjengelig via andre kilder så som digitalt TV, digital kabel eller via digitale medier.

I fremtiden vil det måtte finnes arkitekturer som gjør det mulig for en bruker å oppnå digitalt innhold og som hindrer omgåelse og uautorisert aksess fra både brukere og av fiendtlige entiteter. Samtidig må arkitekturene være fleksible nok til å tillate legitim aksess til enhver klarert komponent, må tillate nye applikasjoner, programvarekomponenter og maskinvareanordninger å bli anvendt med beskyttet innhold, arbeide med flere forskjellige typer medier samt tilveiebringe en mekanisme for å autentisere og spille av innhold på fjernlokaliserte maskinvareanordninger så som håndholdte PDA-enheter, spille til fjernlokaliserte høyttalere, og liknende.

Arkitekturer må også være fleksible og tilstrekkelig abstrahert slik at kun de nederste lagene i infrastrukturen trenger å være klarerte, og med det tillate ikke-klarerte applikasjoner å spille av beskyttet innhold uten kunnskap om at det er beskyttet.

Følgelig tilveiebringes denne oppfinnelsen av hensyn assosiert med det å tilveiebringe forbedrede fremgangsmåter og systemer for å prosessere gjengivbare digitale data på en måte som tilveiebringer en ønsket grad av fleksibel sikkerhet.

Hovedtrekkene ved den foreliggende oppfinnelse fremgår av de selvstendige patentkrav. Ytterligere trekk ved oppfinnelsen er angitt i de uselvstendige krav. Fremgangsmåter, systemer og arkitekturer for prosessering av gjengivbare digitale data er beskrevet. De forskjellige utførelsesformene kan beskytte mot uautorisert tilgang til eller duplisering av ubeskyttet innhold (dvs. dekryptert innhold) straks innholdet har nådd en rendringsanordning så som en brukers datamaskin. Et fleksibelt rammeverk omfatter en arkitektur som gjør det mulig for generelle mediakilder å tilveiebringe praktisk talt en hvilken som helst type multimediainnhold til en hvilken som helst passende innrettet rendringsanordning. Innhold kan beskyttes og gjengis lokalt og/eller over nettverk, så som Internett.

Arkitekturen ifølge oppfinnelsen kan gjøre det mulig for tredjeparter å skrive komponenter og for komponentene på en sikker og fleksibel måte å bli innlemmet i en prosesseringskjede. Komponentene kan bli verifisert av én eller flere autentifika torer som blir opprettet og deretter anvendt for å gå gjennom kjeden av komponenter for å verifisere at komponentene er pålitelige. De forskjellige utførelsesformene kan således tilveiebringe en standard plattform som kan utvides til å beskytte innhold på tvers av et bredt spekter av rendringsmiljøer, innholdstyper og DRM-teknikker. Figur 1 er et høynivå blokkdiagram av et system i hvilket forskjellige prinsipper ifølge oppfinnelsen kan bli anvendt. Figur 2 er et blokkdiagram av et eksempel på datamiljø i hvilket prinsipper i den beskrevne utførelsesformen kan bli implementert. Figur 3 er et blokkdiagram som illustrerer et eksempel på system som kan anvendes for å implementere én eller flere av utførelsesformene. Figur 3a er et flytdiagram som illustrerer trinn i en fremgangsmåte ifølge én utførelsesform. Figur 4 er et blokkdiagram som illustrerer et eksempel på system som kan anvendes for å implementere én eller flere av utførelsesformene. Figur 5 er et blokkdiagram som illustrerer aspekter ved en autentiseringsmodell ifølge én utførelsesform. Figur 6 er et blokkdiagram som illustrerer et eksempel på system som kan anvendes for å implementere én eller flere av utførelsesformene i forbindelse med et nettverksmiljø. Figur 7 er et blokkdiagram som illustrerer et eksempel på system som kan anvendes for å implementere én eller flere av utførelsesformene i forbindelse med et nettverksmiljø.

Fremgangsmåtene, systemene og arkitekturene beskrevet nedenfor er rettet mot det å tilveiebringe en beskyttet mediabane fra en kilde for beskyttet innhold (f.eks. en DRM-tjener, DVD-tjener (vanligvis en DVD-diskstasjon), HDTV-tjener (vanligvis en TV-stasjon som kringkaster til et avstemningskort i en PC) eller en hvilken som helst gitt type innholdstjener) til og gjennom en anordning (inklusive an-ordningens programvare og maskinvare) som kan gjengi eller på annen måte spille av det beskyttede innholdet for en bruker.

Figur 1 viser et eksempel. Der omfatter et system 100 et antall forskjellige typer kilder for eller leverandører av beskyttet innhold, så som en DVD-tjener 102, en innholdstjener 104 (for eksempel en som kan tilveiebringe lyd-innhold, lyd/videoinnhold og liknende), en HDTV-tjener 106 samt en lokal harddisk 116, for å nevne noen. Innholdsleverandørene er innrettet for å tilveiebringe sine innhold via forskjellige medier som kan omfatte nettverk så som nettverk 108, 110, 112 og 118, busser (så som PCI- og AGP-busser) og liknende. Innholdet blir typisk tilveiebrakt til en eller annen type anordning som kan presentere innholdet for en bruker. Eksempler på anordninger omfatter, uten begrensning, en personlig datamaskin 114, en håndholdt PC 120, et fjernsyn 122 med, for eksempel, en set-top boks 124, og liknende.

I beskrivelsen nedenfor er mål-maskinvaren for slikt innhold i én utførelses-form en lokal PC som inneholder et beskyttet videokort, og i andre utførelsesformer en fjernlokalisert, håndholdt anordning så som en håndholdt datamaskin. Det må innses og forstås at disse eksemplene kun er ment for å illustrere noen få, eksempelvise utførelsesformer der de oppfunnede prinsippene beskrevet her kan bli anvendt. Følgelig kan andre typer anordninger anvendes innenfor idéen bak og rammen til det krevede temaet.

Fremgangsmåtene, systemene og arkitekturene beskrevet nedenfor kan være rettet mot håndtering av forskjellige typer innholdsformater, mange av hvilke kan ha spesifikke DRM-(digital-rights-management)-egenskaper som kan omfatte, i mange tilfeller, sin egen rettighetsforvaltning og kryptering. Dette kan i betydelig grad øke den fleksibiliteten og robustheten med hvilken innhold kan bli beskyttet. Følgelig kan det å ha en fleksibel arkitektur unngå en situasjon der alt innhold nødvendigvis må være bundet til én spesifikk type DRM-format. I én eller flere av utførelsesformene som er beskrevet nedenfor er således ett fordelaktig særtrekk ved arkitekturen det at tredjeparter kan skrive og tilveiebringe oversettelsesmoduler som kan bli importert til arkitekturen og deretter bli anvendt for å avbilde til et felles rettighetsforvaltnings- og krypteringssystem som kan sikre at arkitekturiske komponenter er pålitelige og verifiserte.

I tillegg kan utførelsesformene beskrevet nedenfor omfatte én eller flere av følgende særtrekk og/eller fordeler. En autentikatormekanisme er tilveiebrakt og kan bli generalisert til en rekursiv algoritme som følger strømmen av data. I enkelte utførelsesformer blir en initiell autentikator tilveiebrakt og begynner å autentisere kjeden av komponenter som skal håndtere beskyttede data. Ytterligere autentikatorer kan bli opprettet langs kjeden, og kan etablere en sikker kanal gjennom hvilken de kan kommunisere. Autentikatorene trenger ikke initielt å ha kunnskap om strukturen til dataformatet for å utføre sine autentiseringfunksjoner. Forskjellige utførelsesformer kan anvende annulleringslister som kan hindre anvendelse av kjente komponenter som har blitt kompromittert. Videre, i noen utførelsesformer, er direkte autentisering av maskinvare og kryptering for maskinvareanordninger mulig. Det kan konstrueres forskjellige utførelsesformer for å jobbe med ikke-klarerte applikasjoner. I dette tilfellet kan data være beskyttet fra den ikke-klarerte applikasjonen, men kan likevel bli prosessert i komponentkjeden av klarerte og verifiserte komponenter. Autoriserte applikasjoner, så som de som er klarerte, kan gis tilgang til dataene. Dette er nyttig for å gjøre det mulig for applikasjoner å manipulere data så som å visualisere eller modifisere dataene.

Forskjellige utførelsesformer kan bli implementert i forbindelse med fjernlokaliserte anordninger som kan gjengi data over forskjellige busser, nettverk og liknende, med full støtte for autentisering og kryptering. Dette kan gjøre det mulig for en vert å utføre mesteparten av preprosesseringen og grensesnittstyringen, slik at den fjernlokaliserte anordningen (f.eks. en PDA) bare trenger å vise dataene. I tillegg kan forskjellige utførelsesformer prosessere beskyttet innhold fra en rekke forskjellige kilder. Nærmere bestemt kan beskyttet innhold bli produsert av både lokale anordninger (f.eks. en DVD-stasjon, videokameraer, TV-avstemningsenheter, digital kabel) og fjernlokaliserte kilder (så som en web- eller videotjener). Videre kan dataprosesseringskjeder gjenbrukes i andre dataprosesseringskjeder. For eksempel kan nesten alle komponentene som blir anvendt for å spille av sikret lyd gjenbrukes for å beskytte lydsporet i et videoklipp.

Disse og andre fordeler vil være åpenbare i lys av den etterfølgende beskrivelsen.

Utførelsesformene kan prosessere enhver strøm av data, og er ikke spesifikt bundet til kun video- eller lyd-data. Utførelsesformene kan således anvendes for å beskytte andre dataformater.

Eksempel på datasystem

Figur 2 illustrerer et eksempel på et egnet datasystemmiljø 200 i hvilket systemet og de relaterte fremgangsmåtene beskrevet nedenfor kan bli anvendt.

Det må forstås at datamiljøet 200 er kun ett eksempel på et egnet datamiljø, og er ikke ment for å legge begrensninger på omfanget av mediaprosesseringssys-temets bruksområde eller funksjonalitet. Heller ikke skal datamiljøet 200 forstås å ha noen som helst avhengighet av eller krav vedrørende noen komponenter eller kombinasjoner av komponenter som er illustrert i det eksempelvise datamiljøet 200.

De forskjellige beskrevne utførelsesformene kan være operative med en rekke forskjellige andre generelle eller spesialiserte datamiljøer eller -konstruksjoner. Eksempler på velkjente datamaskinsystemer, -miljøer og/eller -konstruksjoner som kan være egnet for anvendelse med mediaprosesseringssystemet omfatter, men er ikke begrenset til, personlige datamaskiner, tjener-datamaskiner, tynne klienter, tykke klienter, håndholdte anordninger eller laptop-anordninger, flerprosessorsystemer, mikroprosessorbaserte systemer, set-top bokser, programmerbar for-brukerelektronikk, personlige datamaskiner i nettverk, minidatamaskiner, stormas-kiner, distribuerte datamiljøer som omfatter hvilke som helst av de ovennevnte systemer eller anordninger, og liknende.

I visse implementeringer kan systemet og de relaterte fremgangsmåtene beskrives i den generelle sammenhengen datamaskin-eksekverbare instruksjoner, så som programmoduler, som eksekveres av en datamaskin. Programmoduler omfatter generelt rutiner, programmer, objekter, komponenter, datastrukturer, etc. som utfører konkrete oppgaver eller implementerer spesifikke abstrakte datatyper. Utførelsesformene kan også anpasses for distribuerte beregningsmiljøer der oppgaver utføres av fjernprosesseringsanordninger som er forbundet via et kommunika-sjonsnettverk. I et distribuert beregningsmiljø kan progamvaremoduler være lokalisert i både lokale og fjerntliggende datalagringsmedier, inklusive minnelagrings-anordninger.

I det illustrerte utførelseseksempelet i figur 2 er datasystemet 200 vist omfattende én eller flere prosessorer eller prosesseringsenheter 202, et systemminne 204 og en buss 206 som forbinder forskjellige systemkomponenter inklusive systemminnet 204 med prosessoren 202.

Bussen 206 er ment å representere én eller flere blant flere typer tilgjengelige busstrukturer, inklusive en minnebuss eller minnekontroller, en periferienhet-buss, en akselerert grafikkport og en prosessor eller lokal buss som anvender en hvilken som helst blant en rekke mulige 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-Associate)-buss, og en PCI (Peripheral-Component-lnterconnect)-buss, også kjent som en Mezzanine-buss.

Datamaskinen 200 omfatter typisk flere datamaskinlesbare medier. Slike medier kan være et hvilket som helst tilgjengelig medium som er lokalt og/eller fjern-aksesserbart for datamaskinen 200, og den omfatter både volatile og ikke-volatile medier, flyttbare og ikke-flyttbare medier.

I figur 2 omfatter systemminnet 204 datamaskinlesbare medier i form av volatilt minne, så som et direkteaksessminne (RAM) 210, og/eller ikke-volatilt minne, så som et leseminne (ROM) 208. Et BIOS (basic input/output system) 212, som inneholder de grunnleggende rutinene som bidrar til å overføre informasjon mellom elementer i datamaskinen 200, for eksempel under oppstart, er lagret i ROM 208. RAM 210 inneholder typisk data og/eller programmoduler som er umiddelbart tilgjengelige for og/eller som opereres på av prosesseringsenheten(e) 202.

Datamaskinen 200 kan videre omfatte andre flyttbare/ikke-flyttbare, volatile/ikke-volatile datamaskin-lagringsmedier. Kun som et eksempel illustrerer figur 2 en harddiskstasjon 228 for å lese fra og skrive til et ikke-flyttbart, ikke-volatilt magnetisk medium (ikke vist, og typisk kalt en "harddisk"), en magnetdiskstasjon 230 for å lese fra og skrive til en flyttbar, ikke-volatil magnetdisk 232 (for eksempel en "diskett") og en optisk-disk stasjon 234 for å lese fra eller skrive til en flyttbar, ikke-volatil optisk disk 236 så som et CD-ROM, DVD-ROM eller et annet optisk medium. Harddiskstasjonen 228, magnetdiskstasjonen 230 og optisk-disk stasjonen 234 er hver koplet til bussen 206 via ett eller flere grensesnitt 226.

Stasjonene og deres assosierte datamaskinlesbare medier tilveiebringer ikke-volatil lagring av datamaskinlesbare instruksjoner, datastrukturer, programmoduler og andre data for datamaskinen 200. Selv om det eksemplifiserte miljøet som er beskrevet her omfatter en harddisk228, en flyttbar magnetdisk 232 og en flyttbar optisk disk 236, vil fagmannen forstå at andre typer datamaskinlesbare medier som kan lagre data som kan aksesseres av en datamaskin, så som magnetkassetter, flash-minnekort, digitale videodisker, RAM, ROM og liknende, også kan anvendes i det eksemplifiserte operasjonsmiljøet.

Et antall programmoduler kan være lagret i harddisken 228, magnetdisken 232, den optiske disken 236 , ROM 208 eller RAM 210, omfattende, som ikke-be-grensende eksempler., et operativsystem 214, ett eller flere applikasjonsprogrammer 216 (f.eks. et multimedia-applikasjonsprogram 224), andre programmoduler 218 og programdata 220. En bruker kan sende inn kommandoer og informasjon til datamaskinen 200 via inndataanordninger så som tastatur 238 og pekeranordning 240 (så som en "mus"). Andre inndataanordninger kan omfatte én eller flere lyd/video-innmatingsanordninger 253, en mikrofon, styrespak, spillkontroll, parabolan-tenne, serieport, skanner eller liknende (ikke vist). Disse og andre inndataanordninger er koplet til prosesseringsenheten(e) 202 via inndatagrensesnitt 242 som er koplet til bussen 206, men kan være tilkoplet via andre grensesnitts- og busstrukturer, så som en parallellport, en spillutgang eller en universell seriell buss

(USB).

En monitor 256 eller en annen type skjermanordning er også koplet til bussen 206 via et grensesnitt, så som et skjermkort eller skjerm/grafikk-kort 244. I tillegg til monitoren omfatter personlige datamaskiner typisk andre periferi-utmatings-anordninger (ikke vist), så som høyttalere og skrivere, som kan være tilkoplet via et periferienhet-utmatingsgrensesnitt 246.

Datamaskinen 200 kan operere i et nettverksmiljø ved anvendelse av logiske forbindelser til én eller flere fjerndatamaskiner, så som en fjerndatamaskin 250. Fjerndatamaskinen 250 kan omfatte mange av eller alle de elementene og mekanismene som er beskrevet her i forbindelse med en datamaskin.

Som vist i figur 2 er datasystemet 200 koplet for kommunikasjon med fjernlokaliserte anordninger (f.eks. fjerndatamaskinen 250) via et lokalt nettverk (LAN) 251 og et generelt fjernaksessnett (WAN) 252. Slike nettverksmiljøer er vanlige i kontorer, bedriftsomspennende datanettverk, intranett og Internett.

Når den anvendes i et LAN-miljø, er datamaskinen 200 koplet til LAN 251 via et egnet nettverksgrensesnitt eller nettverkskort 248. Når den anvendes i et WAN-miljø, omfatter datamaskinen 200 typisk et modem 254 eller andre anordninger for å etablere kommunikasjon over WAN 252. Modemet 254, som kan være internt eller eksternt, kan være koplet til systembussen 206 via brukerinnmatingsgrensesnittet 242 eller en annen dertil egnet mekanisme.

I et nettverksmiljø kan programmoduler som er vist i forbindelse med den personlige datamaskinen 200, eller deler av disse, være lagret i en fjernlokalisert minnelagringsanordning. Som et eksempel, og uten begrensning, illustrerer figur 2 fjernlokaliserte applikasjonsprogrammer 216 som lokalisert i en minneanordning i fjerndatamaskinen 250. En vil forstå at de viste og beskrevne nettverksforbindelsene kun er eksempler, og at det kan anvendes andre mekanismer for å etablere en kommunikasjonslink mellom datamaskinene.

Utførelseseksempler

Figur 3 illustrerer et eksempel på kjede av komponenter som er nyttig for å forstå forskjellige av de oppfunnede prinsipper som er beskrevet her. Et overordnet mål med systemet i figur 3 er å kunne motta krypterte data eller kryptert innhold og DRM-data fra én eller flere kilder, avbilde dataene til et felles system, og deretter kunne ha en lisens som spesifiserer at dataene eller innholdet krever en beskyttet mediabane. Deretter må systemet være i stand til å verifisere at de av systemets komponenter som utgjør databanen er pålitelige. Ett aspekt ved de beskrevne utførelsesformene er at arkitekturen kan forenkle det å håndtere flere forskjellige typer komponenter, og kan anvendes i forbindelse med mange forskjellige typer komponenter. Det vil si at arkitekturen ikke trenger å være uoppløselig bundet til spesifikke komponenter for effektivt å være i stand til å prosessere og gjengi beskyttet innhold.

Beskrivelsen som følger gir et tildels høynivå, funksjonelt overblikk over et system som omfatter forskjellige oppfunnede prinsipper ifølge én utførelsesform. Mer detaljerte aspekter ved et systemeksempel er beskrevet i seksjonen med tittelen "Implementasjonseksempel - utførelsesform med lokal anordning" nedenfor.

Det illustrerte systemet kan effektivt deles inn i seks komponenter for det formål å forstå forskjellige oppfunnede prinsipper, som hver blir diskutert mer i detalj nedenfor: ■ En innholdskilde-komponent og dens forbindelse til en lisenstjener (f.eks. innholdskilde 300); ■ En klientkomponent og assosierte komponenter for å dekryptere dataene og prosessere innholdsspesifikasjoner som inneholder DRM-innhold (f.eks. klient 304); ■ En de-multiplekser, dekodere samt data re-kryptografer (f.eks. demultiplekser 306, dekoder 308 og kryptograf 310); ■ En applikasjon for å prosessere og mikse datastrømmer (f.eks. applikasjon 312); ■ Én eller flere rendringsenheter som setter opp maskinvarekryptering og fordele fremvisningen av dataene (f.eks. rendringsenhet 314); og

Maskinvare for å dekryptere og gjengi dataene (f.eks. rendrings-maskinvare 316).

I tillegg til de ovenfor listede elementene, gjør det illustrerte systemet også bruk av flere forskjellige autentikatorer som blir opprettet under en verifikasjonsprosess for effektivt å bekrefte at komponenter som utgjør systemet er pålitelige. Dette kan gjøres ved å verifisere digitale signaturer som er innlemmet i komponentene. I dette eksempelet er det tre autentikatorer - en primær autentikator 318, og to sekundære autentikatorer 320, 322. Merk at autentikatorene 318 og 320 er brukermodus-autentikatorer, og anvendes følgelig for å verifisere brukermodus-komponenter. Autentikatoren 322, på den annen side, er en kjernemodus-autentikator, og anvendes for å verifisere kjernemodus-komponenter.

Videre kan systemet anvende et oversetterprogram så som et oversetterprogram 302. Oversetterprogrammet 302 kan anvendes for å oversette innhold og lisens-data fra ett DRM-format til ett som systemet forstår. Nærmere bestemt er én av fordelene ved systemet som skal beskrives det at systemet kan konfigureres for å jobbe med forskjellige, såkalte "fremmede" DRM-formater som systemet internt ikke forstår. Spesifikt kan oversetterkomponenter for eksempel bli skrevet av tredjeparter som gjør det mulig å anvende forskjellige DRM-formater med en felles arkitektur. På denne måten kan systemet tilveiebringes med en grad av fleksibilitet som spenner over et bredt spekter av kjente eller senere utviklede DRM-formater.

Innholdskilde

I dette konkrete eksempelet er innholdskilde-komponenter, så som innholdskilden 300, ansvarlige for å lese eventuelle kjente DRM-kilder (dvs. kilder som det forstår) eller oversette fremmede DRM-formater til et DRM-format det forstår. Sistnevnte oppgave kan utføres ved hjelp av oversetterprogrammet 302 som kan, men ikke trenger, utgjøre en del av innholdskilden. Oversetterprogrammet 302 kan anvendes for å mel lom kryptere innholdet og lisensen til et forståelig DRM-format.

Lokale anordninger som tilveiebringer DRM-innhold (så som en DTV-mottaker) kan oversette krypteringssystemet og lisensbegrensningene til et forståelig DRM-format. En driver assosiert med slike anordninger kan utstedes en signatur for at den skal kunne generere DRM-innholdet. Dens lisens kan da spesifisere en avhengighet av en fjernlokalisert lisenstjener, slik at annulleringslister kan bli oppdatert. Annulleringslister kan typisk være tilveiebrakt for å gjøre det mulig for systemet å fastslå hvilke komponenter som har blitt kompromittert. For eksempel kan en lisens kreve en ukentlig annulleringsliste som kan bufres lokalt.

Klient og autentikatorer

Klient 304 mottar typisk kryptert innhold og en lisens som kan være inkludert som del av en spesifikasjon som klienten mottar. Spesifikasjonen kan typisk beskrive de komponentene av en rendrings-prosessrekke som er nødvendige for å gjengi innholdet. Lisensen kan også omfatte ytterligere informasjon så som det nivå av sikkerhet som innholdet krever. Dette er diskutert mer i detalj nedenfor.

Spesifikasjonen kan også angi typen autentikatorer som må anvendes for å verifisere komponenter i rendrings-prosessrekken. Alternativt kan spesifikasjonen kreve visse typer autentikatorer, og kan da avhenge av de andre komponentene i prosessrekken, så som rendrerne, for å opprette motsvarende autentikatorer, så som en lyd og video kjerne-autentikator.

Etter å ha satt opp en nettverksforbindelse eller lagringskilde, kan innholdskilden instruere klienten 304 om å binde seg i henhold til lisensen. Innholdskilden kan også sette opp hvilken som helst kilde-relatert informasjon for anvendelse av klienten eller andre komponenter for å lette bindingsprosessen. Når lisensen er bundet, kan klienten opprette én eller flere autentikatorer (f.eks. video- og lyd-autentikator) så som autentikator 318. Klienten kan sende lisenskrav til autentikatoren straks den er instansiert.

Autentikatoren(e) kan deretter "gå" gjennom komponentene i prosessrekken for å verifisere signaturer for komponenter som håndterer ukrypterte data. For eksempel, i det illustrerte systemet, kan klienten 304 bli autentisert av en sikker tjener, hvorpå klienten kan opprette autentikatoren 318. Når den er generert, kan autentikatoren 318 verifisere at de-multiplekseren 306, dekoderen 308 og kryptereren alle er pålitelige.

I tillegg, i dette eksempelet, når data sendes over en buss, eller mellom ikke-autentiserte komponenter (for eksempel ved anvendelse av krypterte forbindelser), eller til kjernen, kan det bli opprettet en sekundær autentikator for å verifisere resten av datastrøm-prosessrekken. I dette eksempelet kan således rendreren 314 opprette en andre autentikator 320 som da verifiserer at rendreren er pålitelig. Autentikatorene 318, 320 kan da sette opp en autentisert, kryptert kanal 319 mellom seg.

Den autentiserte, krypterte kanalen 319 kan anvendes for en rekke forskjellige formål. Foreksempel kan kanalen muliggjøre kommunikasjon mellom vedsiden-liggende autentikatorer. Dette kan for eksempel gjøre det mulig for de sekundære autentikatorene å rapportere tilbake verifikasjonsinformasjon og validering eller andre forespørsler til den opprinnelige autentikatoren. I tillegg bør autentikatorene ha mulighet for å sjekke annulleringslister som beskriver komponenter som har blitt kompromittert og således ikke lenger er klarert. Videre kan den autentiserte, krypterte kanalen anvendes for å sette opp krypteringssesjoner for å kryptere video-og lyddata mellom de klarerte komponentene.

I en fjernlokalisert rendringsanordning som har støtte for maskinvare-dekrypter-ing (så som den som er beskrevet mer i detalj nedenfor), kan det opprettes en andre autentikator for å formidle kryptering og autentisering til den fjernlokaliserte anordningen. Kun en liten, muligens ikke klarert, proxy-komponent trenger å bli tilveiebrakt til den fjernlokaliserte anordningen. Den fjernlokaliserte maskinvaren må da fortsatt identifisere seg, slik at den kan annulleres av den primære autentikatoren.

For videoinnhold kan en generisk lyd-video (AV, audio-video) autentikator verifisere brukermodus-komponentene, og rendreren kan opprette media-spesifikke autentikatorer.

Demultiplekser, dekodere og re- krypterere

Demultiplekser 306 mottar typisk ukrypterte data fra klient 304 og splitter dataene til forskjellige strømmer, så som en lyd- og en videostrøm. Demultiplekseren 306 sender deretter typisk strømmene til én eller flere dekodere, så som dekoderen 308, for ytterligere prosessering. En lyd-dekoder (sammen med en krypterer, så som kryptereren 310) kan rekryptere dataene og sende dem til en applikasjon 312 for prosessering. En videodekoder kan rekryptere dataene, slik at de på en sikker måte kan sendes over en PCI/AGP-buss til skjermkortets direkteaksessminne (VRAM). Videodekoderen kan typisk sende delvis komprimerte (og krypterte) data til skjermkortet og kan modifisere tidsstempelet, omarrangere data og parse topptekst. For eksempel, for en DVD-avspilling, kan dekoderen ekstrahere vektor-nivå dataene og residualer og sende dem til video-maskinvare for prosessering. Dekoderen kan også utføre eventuelle modifikasjoner for å simulere revers avspilling eller variabel hastighet effekter.

Applikasjon og miksing

Applikasjonen 312 kan mikse video- og lyd-strømmer i miksebuffere som tilveiebringes av rendreren/rendrerne. Maskinvaren blir da effektivt tilsendt krypterte buffere fra dekoderen sammen med lister med mikseinstruksjoner. Et stort antall bildeprosesseringsoperasjoner og ikke-lineære videoeffekter er mulige, f.eks. ved å anvende pikselskyggere og vilkårlige polygon-avbildninger. Dersom applikasjonen krever aksess til ukrypterte data, kan den opprette en separat, klarert arbeids-prosess. Applikasjonen blir da effektivt en annen autentisert dekoder, og vil måtte dekryptere dataene, prosessere dem og rekryptere dem for utmating til video-maskinvaren eller den neste prosesseringsenheten.

Rendrere og settere

I dette eksempelet kan rendrerne, så som rendreren 314, formidle krypterings-sesjonene fra dekoderen 308 til skjerm- og lyddriveren (dvs. rendrings-maskinvaren 316). Rendrerne er ansvarlige for synkronisering og maskinvarekonfigurering. Rendreren kan omfatte forskjellige API-funksjoner og kode for brukermodus, så vel som de assosierte operativsystem og driver API-funksjoner.

Straks dataene er overført til til skjermkortets VRAM, kan de eventuelt bli dekryptert og blandet med andre videokilder og deretter kopiert til en andel av minnet (betegnet "skrivebordet" eller "den primære overflaten") som avbildes direkte til en skjerm for brukeren. Systemet med sikre mediabaner som er beskrevet ovenfor og nedenfor må sikre at begge de midlertidige miksebuffrene og skrivebordet er beskyttet mot uautorisert aksess.

Én fremgangsmåte for å opprettholde integriteten til data når de er på skrivebordet er å anvende klarert grafikk-maskinvare. Et eksempel på system er beskrevet i de følgende patentsøknader, beskrivelsene i hvilke inntas herved referanse: "Systems and Methods For Securing Video Card Output", som angir som forfattere Glenn Evans og Paul England og som har Attorney Docket nummer ms1-1115us,

innlevert 24. juni 2002; "Methods and Systems Providing Per Pixel Functionality", som angir som forfattere Glenn Evans og Paul England og som har Attorney Docket nummer ms1-1025us, innlevert 24. juni 2002.

Essensielt, i de systemene som er beskrevet i de nevnte patentsøknadene, blir utdata kryptert i forhold til et vindus origo på skjermen. Når et vindu fysisk beveges, blir enten origo flyttet eller så blir dataene kryptert i forhold til det nye origo. Kun skjerm-maskinvarens DAC er i stand til å dekryptere og vise dataene.

Innholdet kan krypteres direkte til skrivebordet av dekoderen eller mellomkryp-teres ved anvendelse av klarert maskinvare av rendreren når det endelige bildet er satt sammen.

I utførelsesformer der rendrere kjører over et nettverk til en "tynn" klient, kan rendrerne deles i en autentisert lokal komponent og en fjernlokalisert komponent. Komprimerte, krypterte data og manipuleringsinstruksjoner kan sendes over nettverket til den fjernlokaliserte rendreren. Miksing av data kan bli utført hos verten dersom det ikke finnes støtte for fjernlokalisert maskinvare.

Maskinvare for rendring

Grafikk-kortet er ansvarlig for å dekryptere innholds-strømmen, manipulere dataene under anvendelse av en grafikkprosessorenhet (GPU) og vise utdataene. De patentsøknadene som ble inntatt ved referanse ovenfor beskriver én pålitelig maskinvarekonstruksjon som kan anvendes for å prosessere beskyttet innhold.

Kort oppsummert beskriver disse søknadene kryptografisk støtte som kan deles inn i en dekrypterings/krypteringsmotor i GPU-enheten og en komponent som forvalter nøklene (henvist til som "kryptoprosessoren"). Grafikk-maskinvaren kan ha støtte for pikselvis kryptering, slik at VRAM-minnet kan opprettholdes i kryptert tilstand. Hver grafikkoperasjon av GPU-enheten kan da dekryptere den pikselen som er av interesse, prosessere denne på en eller annen måte og rekryptere utdataene. Bildene kan være dekket med krypteringsnøkler slik at hver nøkkelregion effektivt vil passe i hurtigbufrene i GPU-enheten. Utdataene fra video-DAC kan tilveiebringe enten digital beskyttelse eller analog beskyttelse. For fjernlokaliserte skjermer kan fremvisnings-maskinvaren være tilveiebrakt med noen form for dekrypteringsstøtte for å dekryptere dataene som blir sendt over nettverket.

Figur 3a er et flytdiagram som beskriver trinn i en fremgangsmåte ifølge én utførelsesform. Trinnene kan implementeres i enhver egnet maskinvare, program vare, fastvare eller kombinasjon av disse. I det illustrerte eksempelet kan trinnene bli implementert i forbindelse med en programvarearkitektur så som den som er beskrevet ovenfor og nedenfor.

Trinn 354 bestemmer hvorvidt oversettelse av DRM-dataene er nødvendig. I så fall kan trinn 356 oversette DRM-innholdet til en form som forstås av det prosesser-ingssystemet som skal gjengi innholdet. Dette trinnet kan gjennomføres med en separat oversettermodul som, i noen tilfeller, kan være levert av tredjeparts programleverandører. Trinn 350 mottar kryptert innhold som skal beskyttes under en rendringsprosess. Innholdet skal beskyttes i henhold til et DRM-skjema. Innholdet kan være mottatt fra en hvilken som helst passende kilde, eksempler på hvilke er gitt ovenfor. Trinn 352 mottar en spesifikasjon som er assosiert med innholdet. Trinnene 350 og 352 kan bli utført av en passende konfigurert klient, så som klienten 304 (figur 3). Spesifikasjonen spesifiserer krav til beskyttede mediabaner som begrenser den prosessen i hvilken innholdet skal gjengis. Slike krav kan og vil typisk komme i form av en lisens. Spesifikasjonen kan, men trenger ikke, bli mottatt sammen med det krypterte innholdet.

Videre verifiserer trinn 358 at den klientkomponenten som mottar det krypterte innholdet er pålitelig. Dette trinnet kan implementeres av en sikker tjener som for eksempel kan verifisere en digital signatur som er assosiert med klienten. Trinn 360 oppretter en primær autentikator. Dette trinnet kan implementeres av klienten. Trinn 362 samordner én eller flere nedstrøms prosesserings-strøm komponenter til den primære autentikatoren. Dette trinnet kan implementeres av klienten og/eller en hvilken som helst av komponentene nedstrøms. I én utførelsesform forespør den primære autentikatoren klienten vedrørende de komponentene den sender data til, og forespør deretter disse komponentene, og så videre. Trinn 364 autentiserer én eller flere nedstrøms-komponenter med den primære autentikatoren. Dette trinnet kan realiseres ved å verifisere digitale signaturer assosiert med de forskjellige komponentene ved, for eksempel, anvendelse av en sikker tjener.

Trinn 366 bestemmer hvorvidt det er behov for sekundære autentikatorer. En sekundær autentikator kan være nødvendig av en hvilken som helst grunn, eksempler på hvilke er gitt nedenfor. Dersom det ikke er behov for sekundære autentikatorer, skaper ikke trinn 368 noen slike. Dersom det på den annen side er behov for en sekundær autentikator, oppretter trinn 370 en sekundær autentikator og etablerer en sikker kanal mellom autentikatorene. Trinn 372 anvender da den sekundære autentikatoren for å autentisere én eller flere nedstrøms komponenter. Frem-gangsmåten kan da gå tilbake til trinn 366 for å bestemme hvorvidt det er behov for ytterlige sekundære autentikatorer.

Implementasjonseksempel - ( utførelsesform med lokal anordning)

Figur 4 viser et eksempel på system som er innrettet for å prosessere beskyttede medier ifølge én utførelsesform. Systemet er tilsvarende, i noen henseende,

som det systemet som er vist og beskrevet i forbindelse med figur 3. I dette konkrete eksempelet er systemet innrettet for å prosessere lyd/video-data i en lokal anordning. Egnede lokale anordninger kan omfatte en lokal PC, en set-top boks eller en hvilken som helst annen anordning som typisk prosesserer lyd/video-data.

Systemet i figur 4 omfatter en videobane og en lydbane. Videobanen omfatter en kjede av komponenter (f.eks. parsings- og transformeringskomponenter), både brukermodus og kjernemodus, som produserer video som plasseres i et skjermkorts VRAM. Rammebufferen vises på skrivebordet og sendes til en utmatingsanordning via DAC. Det er også tilveiebrakt en lydbane for å prosessere lyd-strømmen.

Systemet i figur 4 omfatter en innholdskilde 400 som tilveiebringer beskyttet innhold. Dette innholdet, som angitt ovenfor, kan typisk være ledsaget av eller assosiert med en lisens, ofte inkludert i en spesifikasjon. Lisensen begrenser typisk bruken av innholdet ved å beskrive slike ting som hvem som kan anvende innholdet og hvordan det skal anvendes. Lisensen kan også spesifisere slike ting som annulleringslister som skal anvendes i forbindelse med innholdet, frekvensen for anvendelse av slike annulleringslister og kilden for annulleringslisten, for eksempel en sikker tjener. Spesifikasjonen kan også typisk beskrive nivået av sikkerhet som skal anvendes for det beskyttede innholdet, så som egenskapene til den beskyttede mediabanen som skal settes opp, identifikasjon av komponenter langs denne mediabanen og eventuelle krypterings/dekrypteringskrav. Merk også at det typisk kan anvendes et oversetterprogram for å oversette fremmed DRM-innhold til DRM-innhold som systemet forstår.

Innholdet blir tilveiebrakt av innholdskilden til en klient 404. Som angitt ovenfor, angir den lisensen klienten mottar at dataene krever en beskyttet mediabane-autentikator, så som autentikator 418.1 dette eksempelet krypterer én enkelt klient 404 dataene som mottas fra innholdskilden. Autentikatorer, så som autentikatorene 418, 420 og 422, anvendes for å verifisere den kjeden av komponenter som mottar ukrypterte data. Dette kan gjøres på en rekke forskjellige måter, for eksempel ved å verifisere digitale signaturer assosiert med komponentene og/eller gjennom lister av DLL-adresser. Etter at en prosesseringskjede av komponenter har blitt satt opp, autentiserer en tjener, så som en DRM-tjener, klient 404. Klient 404 oppretter da en primær autentikator 418 som lokaliserer komponenter som prosesserer data, omfattende krypterte data. Komponentene kan lokaliseres av autentikator 418 ved å forespørre individuelle komponenter om hvilke andre komponenter de sender data til. For eksempel kan autentikatoren 418 spørre klienten 404 om hvilke komponenter klienten sender data til. Klienten kan respondere til autentikatoren ved å angi at den sender data til demultiplekseren 406. Dette kan gjøres ved å sende til autentikatoren en peker som peker til demultiplekseren 406. Ettersom demultiplekseren 406 prosesserer ukrypterte data vil den måtte være klarert. Demultiplekseren 406 tar data som er dekryptert av klienten og demultiplekser dataene til en videostream og en lyd-stream. Videostreamen blir prosessert av videodekoderen 408a og dens assosierte nedstrøms komponenter (dvs. kryptereren 410a, videorendreren 414a, video-driveren og GPU-enheten (kollektivt representert som 416a)), mens lyd-streamen blir prosessert av lyd-dekoderen 408b og dens nedstrøms komponenter (dvs. kryptereren 410b, lyd-rendreren 414b, lyd-driveren og lyd-maskinvaren (kollektivt representert som 416b)).

Individuelle komponenter i prosesseringskjeden tilveiebringer adresser, til autentikatorene, til andre komponenter som de sender ukrypterte data til. Autentikatoren går da gjennom listen av komponenter og verifiserer signaturene til komponentene ved, for eksempel, å verifisere signaturene til komponentenes motsvarende DLL-filer. Dette kan gjøres under anvendelse av en sikker tjener. Slik at autentikatoren 418, for eksempel, vil autentisere demultiplekseren 406. Autentikatoren 418 vil da verifisere begge dekoderne 408a, 408b. Etter å ha funnet de komponentene til hvilke dekoderne sender data (dvs. kryptererne 410a, 410b), vil autentikatoren 418 autentisere kryptererne. Applikasjonen 412 kan, men trenger ikke, være en klarert applikasjon. Dersom applikasjonen skal håndtere ukrypterte data, kan autentikatoren 418 verifisere at applikasjonen er klarert. Dersom applikasjonen ikke er klarert, vil den kun håndtere krypterte data.

Til slutt vil dataene bli sendt til rendrerne 414a, 414b. Rendrerne kan opprette sin egen autentikator 420 som da blir verifisert av autentikator 418. En autentisert, kryptert kanal kan bli etablert mellom autentikatorene 418, 420. Straks den er verifisert, kan autentikatoren 420 autentisere rendrerne.

I dette eksempelet blir en kjernemodus-autentikator 422 opprettet av rendreren/rendrerne og blir autentisert av én eller flere av de andre autentikatorene. Autentikatoren 422 bli sikkert forbundet med brukermodus-identikatorene for å verifisere kjerne-komponenter, så som komponentene 416a, 416b.

En nøkkeladministrator 424 er også tilveiebrakt, og kan autentiseres av autentikatoren 422. Nøkkeladministratoren 424 kan være ansvarlig for å administrere krypterings/dekrypteringsnøkler som anvendes av de forskjellige komponentene i prosesseringskjeden for å sende krypterte data. Nøkkeladministratoren kan også administrerer sesjonsnøkler som anvendes under krypteringsprosessen. Spesialiserte krypteringsmetoder kan også bli anvendt og implementert, delvis, av nøkkelad-ministratoren. Et utskiftbart krypteringsbibliotek kan, for eksempel, tilveiebringes for mellomkomponenter. Alle nøkler bør være sesjon-baserte nøkler for å unngå å ha nøkler innbygget i de forskjellige komponentene. En fellesnøkkel-krypteringsalgo-ritme kan bli anvendt for autentisering og for å sette opp sesjonsnøklene mellom dekoderen og en kryptoprosessor i video-maskinvaren. Den krypterte kanalen som anvendes for autentiseringen kan gjenbrukes av de autentiserte komponentene for å sette opp sesjonsnøklene. Dette sikrer at dekrypteringsnøkkelen kun blir sendt til den entiteten som er verifisert av den neste autentikatoren. Dersom en komponent ikke ruter de krypterte dataene og autentikatorens datakanal til samme destinasjon, kan da ikke datastreamen bli dekryptert av entiteten nedstrøms. Algoritmen som anvendes for å sette opp sesjonsnøklene kan være spesifikk for dekoder- og rendringskomponentene. Autentiseringskanalen kan være personifisert for sesjons-nøkkel-genereringstråden for å unngå å korruptere sesjonsnøkkel-oppsettet.

Hver komponent kan, og bør regelmessig, bli re-autentisert, og nøklene bør re-formidles for å bidra til å minimere innsetningsangrep av fremmede komponenter. Et array av sesjonsnøkler kan gjøre det mulig for kilden på en effektiv måte å endre nøkler med gitte mellomrom. Siden det å sette opp nøkler kan være en relativt tidkrevende og beregningstung prosess, kan den utføres asynkront med datastreamen. Det å gå gjennom nøkkelhanker kan bidra til å unngå datanøkkel-synkro-niseringsproblemer. For eksempel kan fire nøkler gi en utsettelse på fire rammer før en ny nøkkelformidling vil måtte være fullført. Dette er diskutert mer i detalj nedenfor i seksjonen med tittelen "Nøkkelformidling og -synkronisering".

Nøkkelformidling og - synkronisering

Nøkkelhanker inneholder typisk flere nøkler. I video-sammenheng, nårvideo-rendreren prosesserer data, køer den typisk opp et antall rammer for fremvisning. Av effektivitetsgrunner kan det å anvende en nøkkelhank med flere nøkler og syn-kronisere, for eksempel, én nøkkel per ramme, redusere problemer assosiert med det å måtte formidle en ny nøkkel for hver ramme. Mer spesifikt kan det å ha en nøk-kelhank redusere nøkkelformidlingstiden som følge av det faktum at formidlingen ikke må skje på en nøkkel-for-nøkkel basis. Ved å anvende en bank med flere nøkler, kan således én nøkkel bli anvendt for hver ramme, og nøklene kan bli sirkulert rundt i rekkefølge. For eksempel kan nøkler 1 til 4 være formidlet, idet nøkkel 1 anvendes for ramme 1, nøkkel 2 anvendes for ramme 2, osv. Istedet for å måtte formidle individuelle nøkler, utføres formidlingen for flere nøkler om gangen, som deretter gjennomløpes.

Som et eksempel, i en beskyttet videobane, kan det etableres et array av ses-jonsnøkler mellom dekoderen og video-maskinvaren ved anvendelse av et autentisert PKI-krypteringssystem. Nøkler kan da bli opprettholdt i et ikke-aksesserbart minne i skjermkortet og i beskyttet minne av dekoderen. Hver nøkkel kan refereres til med sesjonsindeks. I video-maskinvaren kan data være assosiert med en sesjonsindeks eller identifikator som angir hvilken sesjon som ble anvendt for å kryptere dataene. Sesjonsindeksen kan da anvendes av GPU-enheten til å sette opp den kryptografiske motoren i GPU-enheten som da kan prosessere (dvs. dekryptere) de krypterte dataene. Autentikatorkjeden kan periodisk bli reformidlet og autentisert for å bidra til å undertrykke ordbok-baserte angrep og for å forsøke å detektere innsatte uvedkommende komponenter.

Autentikatorer

Som angitt ovenfor, etter at avspillingsmekanismen (dvs. prosesseringskjeden) har blitt satt opp, dekrypterer klientkomponenten dataene og sender dataene til video- og lyd-demultiplekseren. Som del av autentiseringsprosessen oppretter klienten en autentikator som deretter anvendes på demultiplekserne. Autentikatoren retter deretter til de neste video- og lyd-prosesseringskomponentene for autentisering. Rendrerne kan da opprette motsvarende video/lyd-spesifikke kjerne-autentikatorer. Autentikatorene kan autentisere de digitale signaturene som er assosiert med den DLL-filen i hvilken hver adresse er lokalisert.

Autentikatorene kan ikke bare verifisere komponentenes signaturer, men de kan også verifisere at prosesseringskjeden har tilstrekkelig sikkerhet til å tilfredsstille kravene i innholdets lisens. For eksempel kan lisensen spesifisere et nivå av sikkerhet som er påkrevet for prosesseringskjeden. Sikkerhetsnivået kan bli sendt til autentikatoren, som da kan sikre overholdelse av sikkerhetsnivået. Alternativt kan sikkerhetsnivået bli implisitt innkodet ved å kreve et spesifikt nivå for autentikatoren, f.eks. nivå 1 autentikator eller nivå 2 autentikator, som begge kan kalle den primære autentikatoren med sitt nivå.

Eksempler på sikkerhetsnivåer kan omfatte:

• Bit 0 - programvare-tilhakking av komprimerte data (og signert video-driver); • Bit 1 - beskyttelse av komprimerte data med klarert programvare; • Bit 2 - maskinvarebeskyttelse av komprimerte data over busser; • Bit 3 - maskinvarebeskyttelse av komprimerte data i video/lyd-anordningen; • Bit 4 - analog beskyttelse av data som forlater utmatingsanordningen; og • Bit 5 - digital beskyttelse av data som forlater utmatingsanordningen.

Hver komponent kan også være i stand til å legge til begrensninger av lisensen som et første trinn i autentiseringen. Dette kan gjøre det mulig for komponenter (f.eks. dekodere) å kreve at andre komponenter sjekkes for kompabilitet. For eksempel kan en lyd-dekoder bare være lisensiert for å spilles av med applikasjoner som oppfyller visse kriterier.

Et ytterligere systemversjonskrav kan også være nyttig for å spesifisere et nødvendig nivå av driverstøtte. For eksempel kan lisensen inneholde et datapar { minimum beskyttet bane/ drivernivå, minimum maskinvarekrav) som blir sendt til autentikatoren for å sikre overholdelse.

Komponenter

Forskjellige innretninger av autentikatorer kan anvendes for å realisere de ovenfor beskrevne utførelsesformene. For eksempel, i systemet som er vist og beskrevet i figur 4, kan det være to separate, primære autentikatorer - én for videokjeden og én for lydkjeden, eller, som vist i figur 4, én enkelt primær autentikator som kommuniserer med både lyd- og videokjeden. I tillegg kan det være to separate kjernemodus-autentikatorer - én for videokjeden og én for lydkjeden. Dersom dette er tilfelle, kan det da være tilveiebrakt to separate, autentiserte krypterte kanaler - én hver mellom autentikatorene i lydkjeden og videokjeden.

I diskusjonen nedenfor er det beskrevet én spesifikk autentiseringsmodell. Det skal være underforstått at den beskrevne modellen kun illustrerer én mulig autentiseringsmodell. Følgelig kan den andre autentiseringsmodeller tilveiebringes uten å avgå fra idéen bak og rammen til det krevede temaet.

Figur 5 illustrerer et eksempel på autentiseringsmodell der autentikatorer er angitt som "An" og grensesnitt som støttes av forskjellige komponenter i prosesseringskjeden er illustrert som enten "IA" for et autentiserbar-grensesnitt og/eller "IAP" for et autentiseringsproksy-grensesnitt. Et proksy-grensesnitt tjener som et grensesnitt mot en videreformidlingstjeneste til et annet autentiserbar-grensesnitt. Navnene til de forskjellige komponentene er vist ved den aktuelle komponenten. I lyd-kjeden er foreksempel lyd-dekoderen, lyd-innkoderen, applikasjonen, lyd-rendreren og lyd-driver/maskinvare vist. Tilsvarende, i videokjeden, er videodekoderen, videoinnkoderen, applikasjonen, videorendreren og videodriver/maskinvare vist. Merk at enkelte komponenter støtter både et proksy-grensesnitt og et autentiserbar-grensesnitt, f.eks. hver av rendrerne.

Et grensesnitt er bare en logisk del av komponenten og omfatter en samling av kallbare metoder eller funksjoner som kan kalles av andre komponenter. Når en autentikator ønsker å kommunisere med en spesifikk komponent, leter autentikatoren etter det aktuelle grensesnittet for den komponenten og kommuniserer til den ved å kalle grensesnittets definerte metoder.

En autentikator verifiserer komponenter og etablerer krypterte kanaler til andre autentikatorer. Den tilveiebringer også en kryptert kanaltjeneste mellom komponenter som prosesserer ukrypterte data. Kanalen kan anvendes for å formidle arrayer av sesjonsnøkler mellom komponenter for å kryptere hoveddataene. IA-grensesnittet tilveiebringer autentikatoren med en liste over komponenter å verifisere, og en liste over nedstrøms komponenter for å fortsette verifikasjonen. IPP-proksygrensesnittet er et videresendingsgrensesnitt for å formidle autentiseringsinformasjon mellom autentikatorer som er forbundet via ikke-autentiserte komponenter.

I hver autentikator representerer En et kryptering/dekryptering-nøkkelpar for forbindelsens initiator og Dn representerer et kryptering/dekryptering-nøkkelpar for forbindelsens mottaker.

Den første autentikatoren A^kan støtte flere sekundære autentikatorer (f.eks. A2-5) siden den anvendes for å verifisere to separate utdatakjeder (f.eks. video og lyd).

Klienten oppretter den initielle autentikatoren A^ og IA-grensesnittet til den første komponenten (dvs. demultiplekseren) blir spesifisert for autentikatoren. I dette eksempelet returnerer IA-grensesnittet følgende informasjon til autentikatoren: • En liste over IA-grensesnitt for nedstrøms komponenter; • En liste over IAP-proksygrensesnitt for nedstrøms komponenter (som kun ser krypterte data); • En liste over avhengige komponenter for hvilke signaturer skal verifiseres; • Lagring for den neste autentikator-forbindelsesindeksen (samme autentikator kan gjenbrukes for flere streamer); og

• Nøkkelsesjonsnummer for autentiseringskjeden.

Autentikatoren (A^ anvender klienten for å verifisere IA-grensesnittets adresse, deretter dets avhengige komponenter, og rekurserer ned hver av dets nedstrøms IA-grensesnitt. Deretter setter autentikatoren opp en kryptert, autentisert kanal til den neste autentikatoren gjennom hvert av de listede IAP-grensesnittene.

lAP-grensesnittet tilveiebringer to metoder for å kommunisere til den neste autentikatoren:

• ReadData(buffer, length)

• WriteData(buffer, length)

Rendreren vil typisk støtte IAP- og IA-grensesnittene. Når rendrerens IAP-grensesnitt blir referert, vil den opprette den neste autentikatoren og videreformidle IAP-kallene til denne. Autentikatorene vil da etablere en autentisert, kryptert kommunikasjonskanal. Autentikatoren blir tilsendt IA-grensesnittet til rendreren, slik at den kan begynne en ny autentiseringskjede som starter ved rendreren.

Autentikatorene kan også tilveiebringe metoder for å gjøre det mulig for de komponentene med IA-grensesnitt å sende informasjon over autentikatorkanalen. Hos autentikatoren kan dette omfatte:

• EncryptAndSend(link ID, [in] data) - send data til neste komponent.

I det IA-grensesnittet som ble sendt til autentikatoren kan følgende tilbakekall eksistere: • DecryptAndReceive([out] data) - anvendt for å signalisere og sende data til den mottakende komponenten; • Linkldentifier([out] link ID) - sendt til det IA-grensesnittet for å sende.

Metodene for å sende og motta kan anvendes av komponentene for å sette opp sesjonsnøkler for å kryptere hoveddataene.

For å forenkle klienten, kan autentikatoren også tilveiebringe følgende enkle krypteringsstøtte: CreateSession(HANDLE [out], CLSID drmEncryptorlD) - oppretter en kryp terer og etablerer en sesjonsnøkkel; . EncryptData(HANDLE [in], BYTE<*>pin, BYTE<*>pOut);

DecryptData(HANDLE [in], BYTE<*>pin, BYTE<*>pOut).

Autentikatoren vil da persistere krypteringsobjektet for komponenten.

Utførelsesform for nettverk - tilfelle I

Én av fordelene ved arkitekturen beskrevet ovenfor er at den kan benyttes i forbindelse med, og anvendes i konteksten for et nettverk, så som Internett. Som et eksempel, se figur 6, som viser et system som er tilsvarende, i mange aspekter, det systemet som er vist og beskrevet i forbindelse med figur 4. Samme referanse-

nummer som utførelsesformen i figur 4 er benyttet der det er naturlig (bortsett fra at referansenumrene i figur 6 er på formen "6XX" mens referansenumrene i figur 4 er på formen "4XX").

I dette eksempelet er det tilveiebrakt en fjernlokalisert anordning 624 som omfatter programvare og maskinvare (kollektivt angitt som 617) som kan anvendes for å gjengi innhold på den fjernlokaliserte anordningen. Eksempler på fjernlokaliserte anordninger kan omfatte håndholdte PC-er, PDA-er, USB-høyttalere, IEEE 1394 høyttalere og liknende. Komponenter så som klient 604, nøkkelforvalter 624, demultiplekser 606, dekodere 608a, 608b, krypterere 610a, 610b, applikasjon 612 rendrere 614a, 614b, og én eller flere autentikatorer, så som den primære autentikatoren 618 og den sekundære autentikatoren 620, kan befinne seg på én side av en nettverksforbindelse så som hos en vertsmaskin. Anordning 624 kan da kommunisere med vertsmaskinen via en nettverksforbindelse, slik at den kan gjengi beskyttet innhold fra en klarert kilde for en bruker.

I dette eksempelet omfatter den fjernlokaliserte anordningen 624 en autentikator 622 som kan være satt opp og konfigurert på en måte som er veldig lik den måten kjernemodus-autentikatoren ble satt opp og konfigurert ovenfor.

Det vil si at, i dette eksempelet, det er en logisk forbindelse mellom autentikatorene på begge sider av nettverket (f.eks. autentikatorene 620 og 622). Denne logiske forbindelsen blir autentisert og kryptert av alle de samme grunnene som nevnt ovenfor. Ansvaret til nettverk-rendreren/rendrerne er å kommunisere over nettverket og finne ut hvilke komponenter som befinner seg i den fjernlokaliserte anordningen 624. Rendreren(e) oppretter da autentikatoren på den fjernlokaliserte anordningen 624, og etablerer en kommunikasjonskanal mellom de to autentikatorene 620, 622. Kanalen kan anvendes for å sette opp nøkler mellom kryptereren 610a og rendrings-maskinvaren (617).

Når de forskjellige komponentene i prosesseringsskjeden på hver side av nettverket har blitt autentisert, kan det beskyttede innholdet leveres til den fjernlokaliserte anordningen 624 for gjengivelse.

Utførelsesform for nettverk - tilfelle II

Figur 7 viser et system som er litt forskjellig fra systemet vist og beskrevet i figur 6. Her omfatter en fjernlokalisert anordning 724 en utelukkende maskinvare implementert rendringskomponent 717. En programvareimplementert proksy 715 er tilveiebrakt og kan hjelpe autentiseringsprosessen, men trenger ikke nødvendigvis å være klarert. Autentiseringen kan skje i maskinvaren selv ved, for eksempel, å tilveiebringe PKI-autentiseringsstøtte i maskinvaren.

I dette eksempelet kan nettverk-rendreren(e) avbilde autentiseringsprotokollen på den venstre siden av nettverket til maskinvare-autentiseringsprotokollen i anordningen 724. Dette kan gjøre bruk av en autentiserings-oversettingsmodul som befinner seg i programvare-proksyen 715. I dette tilfellet vil da programvare-proksyen 715 måtte være klarert og verifisert. Alternativt kan maskinvaren være kompatibel med autentiseringsprotokollen på den venstre siden av nettverket, eller maskinvaren kan inneholde en oversettelsesmodul for å utføre avbildningsoperasjonen selv, og med det eliminere behovet for å stole på eller verifisere programvaren i anordningen.

Denne typen innretning er fordelaktig fra det standpunkt at den tillater tredjeparter å skrive sine egne oversettermoduler som kan anvendes i deres egne fjernlokaliserte anordninger. Disse modulene kan da utføre oversettelsen av autentiseringsprotokollen og, som et resultat av dette, er ikke låst til noen gitt autentiseringsmodell. Tredjeparter kan også sette opp brukermodus-autentikatorer på den venstre siden av nettverket dersom, for eksempel, deres videorendrer trenger å prosessere ukrypterte data.

I tillegg er arkitekturen ovenfor også fordelaktig i det at annulleringslister kan sendes over de forskjellige komponentene, f.eks. kan en tjener sende annulleringslisten til klienten, som deretter kan sende listen ned prosesseringskjeden til den fjernlokaliserte anordningen. Følgelig vil komponenter som er annullert ikke lenger være i stand til å prosessere de beskyttede dataene. For eksempel vil en lisens som ledsager beskyttet innhold kunne spesifisere at innholdet krever en mediabane-autentikator, og, i tillegg, at anordningen periodisk må aksessere en tjener for å oppnå en annulleringsliste. Brukeren kan da, med sin fjernlokaliserte anordning, spille av innhold over en tidsperiode, hvorpå deres anordning vil måtte aksessere tjeneren for å oppnå annulleringslisten slik at anordningen kan oppdatere sin liste over hvilke komponenter som har blitt annullert.

Andre utvidelser og fordeler

Utførelsesformene i figurene 6 og 7 kan bli utvidet til at nettverk-rendreren(e) implementeres som en kringkaster. For eksempel kan en kringkastingstjeneste eller - tjener sette opp og dele krypteringsnøkler med et antall forskjellige maskinvareanordninger. Kringkasteren kan da kringkaste beskyttet innhold til disse anord-ningene og være sikker på at innholdet vil forbli beskyttet.

En annen fordel ved arkitekturen er at data kan sendes frem og tilbake mellom bruker- og kjernemodus så mange ganger som nødvendig. Dette kan være fordelaktig for slike ting som ekko-kansellering i lyd-data. Nærmere bestemt kan en lyd-rendrer gå inn i kjernen og opprette en annen prosesseringskjede som går tilbake ut til en brukermodus-komponent og deretter tilbake inn i kjernen.

Konklusjon

Fremgangsmåtene og systemene beskrevet ovenfor kan tilveiebringe forbedrede fremgangsmåter og systemer for å prosessere gjengivbare digitale data. Noen av fordelene ved de ovenfor beskrevne utførelsesformene omfatter, uten begrensning, at ikke-klarerte brukermodus-komponenter (dekodere, videomanipulato-rer) og kjernemodus-komponenter kan hindres i uautorisert aksess av beskyttede data. I tillegg kan autoriserte komponenter beskyttes mot å bli anvendt for å oppnå uautorisert tilgang til beskyttet innhold. Forskjellige tredjeparts komponenter kan bli anvendt i prosesseringskjeden, og det kan tilveiebringes mekanismer for å sikre at slike komponenter er klarerte før de aksesserer beskyttet innhold. Innhold fra flere forskjellige kilder, så vel som flere forskjellige typer innhold og DRM-teknikker, kan på en enkel måte bli innlemmet i systemet ved hjelp av en oversettingsprosess eller oversettermoduler. Forskjellige utførelsesformer gjør det også mulig å anvende beskyttet innhold på tvers av grenser, så som anordnings- og nettverksgrenser, med en autentiseringsprosess som kan oversettes over grensene. Videre kan det anvendes annulleringsmekanismer (dvs. annulleringslister) for å hindre kompromitterte komponenter i å aksessere beskyttet innhold. Arkitekturen kan også gjøre det mulig å etablere sikre kommunikasjonskanaler mellom dekoderne og rendringsanordningene (dvs. skjerm-maskinvare). Arkitekturen krever ikke forhåndskunnskap om komponent-topologien, og kan anvendes for komplekse struk-turer siden den følger strømmen av data.

Selv om oppfinnelsen har blitt beskrevet i språk spesifikt for strukturelle særtrekk og/eller metodetrinn, skal det være underforstått at oppfinnelsen som defineres i de etterfølgende patentkravene ikke nødvendigvis er begrenset til de spesifikke særtrekkene eller trinnene som er beskrevet. I stedet er de spesifikke særtrekkene og trinnene beskrevet som foretrukne måter for å realisere den krevede oppfinnelsen.

Claims (24)

1. Fremgangsmåte omfattende trinn med å: etablere én eller flere baner av komponenter som skal prosessere og gjengi digitalt innhold eller digitale data; motta kryptert innhold eller krypterte data som skal prosesseres av den ene eller de flere banene, idet det krypterte innholdet eller de krypterte dataene er underkastet en lisens som definerer, i hvert fall delvis, hvordan de krypterte dataene skal prosesseres; opprette flere autentikatorer (318, 320, 322; 418, 420, 422; 618, 620, 622) for å autentisere komponenter langs den ene eller de flere banene; tilveiebringe en sikker kommunikasjonskanal (319) mellom autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622); forespørre, med autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622), individuelle komponenter i den ene eller de flere banene for å fastslå hvilke komponenter de forespurte komponentene sender data til; forsøke å autentisere eller autentisere, med autentikatorene (318, 320, 322;

418, 420, 422; 618, 620, 622), de forespurte komponentene og de komponentene som de forespurte komponentene sender data til; etablere krypterings/dekrypteringsnøkler med flere komponenter i den ene eller de flere banene for anvendelse av komponentene til å kryptere og dekyptere data.

2. Fremgangsmåte ifølge krav 1, videre omfattende trinn med å bestemme hvorvidt eventuelle DRM-data, assosiert med innholdet eller dataene, må oversettes til en form som kan forstås av en autentikator sitt DRM-system, og, i så fall, å effektuere oversettelse av de digitale rettighetsforvaltningsdataene ved anvendelse av en separat oversettermodul som er innrettet for å oversette DRM-dataene.

3. Fremgangsmåte ifølge krav 1 eller 2, der minst én autentikator opprettes på tvers av en anordningsgrense på en fjernlokalisert maskin.

4. Fremgangsmåte ifølge ethvert av krav 1-3, der lisensen spesifiserer én eller flere annulleringslister som kan anvendes for å fastslå hvorvidt individuelle komponenter har blitt kompromittert.

5. Fremgangsmåte ifølge ethvert av krav 1-3, der lisensen spesifiserer et nivå av sikkerhet som skal anvendes for å beskytte det digitale innholdet eller de krypterte dataene.

6. Fremgangsmåte ifølge ethvert av krav 1-3, der trinnet med å etablere krypte-rings/dekrypteringsnøklene omfatter det å anvende den sikre kommunikasjonskanalen (319) mellom autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622) for å etablere krypterings/dekrypteringsnøklene.

7. Fremgangsmåte ifølge ethvert av krav 1-3, der trinnet med å etablere krypterings/dekrypteringsnøklene omfatter det å etablere sesjonsbaserte nøkler.

8. Fremgangsmåte ifølge ethvert av krav 1-3, videre omfattende trinn med å re-autentisere komponentene periodisk under anvendelse av autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622).

9. Fremgangsmåte ifølge ethvert av krav 1-3, der trinnet med å opprette de flere autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622) omfatter det å opprette minst én brukermodus-autentikator for å autentisere brukermodus-komponenter og minst én kjernemodus-autentikator for å autentisere kjernemodus-komponenter.

10. Fremgangsmåte ifølge krav 1, videre omfattende trinn med å oversette, om nødvendig, DRM-data som er assosiert med de krypterte dataene eller det krypterte innholdet, og å anvende de oversatte DRM-dataene for å beskytte de krypterte dataene eller det krypterte innholdet under rendringsprosessen.

11. Ett eller flere datamaskinlesbare medier som inneholder datamaskinlesbare instruksjoner som, når de eksekveres av én eller flere prosessorer, får den ene eller de flere prosessorene til å: etablere én eller flere baner av komponenter som skal prosessere og gjengi digitalt innhold; motta kryptert innhold som skal prosesseres av den ene eller de flere banene, idet det krypterte innholdet er underkastet en lisens som definerer, i hvert fall delvis, hvordan de krypterte dataene skal prosesseres; opprette flere autentikatorer (318, 320, 322; 418, 420, 422; 618, 620, 622) for å autentisere komponenter langs den ene eller de flere banene; tilveiebringe en sikker kommunikasjonskanal (319) mellom autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622); forespørre, med autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622), individuelle komponenter i den ene eller de flere banene for å fastslå hvilke komponenter de forespurte komponentene sender data til; autentisere, med autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622), de forespurte komponentene og de komponentene som de forespurte komponentene sender data til; og etablere krypterings/dekrypteringsnøkler med flere komponenter i den ene eller de flere banene for anvendelse av komponentene til å kryptere og dekyptere data.

12. Ett eller flere datamaskinlesbare medier ifølge krav 11, der instruksjonene får den ene eller de flere prosessorene til å etablere krypterings/dekrypteringsnøklene under anvendelse av den sikre kommunikasjonskanalen (319) mellom autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622).

13. Ett eller flere datamaskinlesbare medier ifølge krav 11, der instruksjonene får den ene eller de flere prosessorene til å etablere de sesjonsbaserte krypterings/de-krypteringsnøklene under anvendelse av den sikre kommunikasjonskanalen (319) mellom autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622).

14. Beregningsanordning omfattende: minne; én eller flere prosessorer; instruksjoner i minnet som, når de eksekveres av den ene eller de flere prosessorene, får den ene eller de flere prosessorene til å: etablere én eller flere baner av komponenter som skal prosessere og gjengi digitalt innhold; motta kryptert innhold som skal prosesseres av den ene eller de flere banene, idet det krypterte innholdet er underkastet en lisens som definerer, i hvert fall delvis, hvordan de krypterte dataene skal prosesseres; opprette flere autentikatorer (318, 320, 322; 418, 420, 422; 618, 620, 622) for å autentisere komponenter langs den ene eller de flere banene, idet minst én av autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622) omfatter en brukermodus-autentikator for å autentisere brukermodus-komponenter og minst én annen av autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622) omfatteren kjernemodus-autentikator for å autentisere kjernemodus-komponenter; tilveiebringe en sikker kommunikasjonskanal (319) mellom autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622); spørre, med autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622), individuelle komponenter i den ene eller de flere banene for å fastslå hvilke komponenter de forespurte komponentene sender data til; autentisere, med autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622), forespurte komponenter og, om mulig, de komponentene som de forespurte komponentene sender data til; og etablere krypterings/dekrypteringsnøkler med flere komponenter i den ene eller de flere banene for anvendelse av komponentene til å kryptere og dekyptere data.

15. Beregningsanordning ifølge krav 14, der lisensen spesifiserer én eller flere annulleringslister som kan anvendes for å fastslå hvorvidt individuelle komponenter har blitt kompromittert.

16. Beregningsanordning ifølge krav 14, der det blir sendt identifikasjonsinforma-sjon opp kjeden av krypterte kanaler som er assosiert med autentikatorene (318, 320, 322; 418, 420, 422; 618, 620, 622) for å muliggjøre komponentverifikasjon, uten å kreve at det blir sendt annulleringslister ned kjeden.

17. Beregningsanordning ifølge krav 14, der lisensen spesifiserer et nivå av sikkerhet som skal anvendes for å beskytte de krypterte dataene.

18. Beregningsanordning ifølge krav 14, der instruksjonene forårsaker at den ene eller de flere prosessorene etablerer sesjonsbaserte nøkler.

19. Systemomfattende: én eller flere komponenter som er innrettet for anvendelse i en prosesseringskjede av komponenter som prosesserer beskyttet innhold som skal gjengis for en bruker; individuelle komponenter som støtter ett eller flere av et autentiserbar-grensesnitt og et autentiseringsproksy-grensesnitt, idet autentiserbar-grensesnittet kan kalles av en autentikator og returnerer til autentikatoren minst én av: en liste over autentiserings-grensesnitt for nedstrøms komponenter, en liste over autentiseringsproksy-grensesnitt for nedstrøms komponenter, og en liste over avhengige komponenter for hvilke å verifisere signaturer, idet autentiseringsproksy-grensesnittet tilveiebringer metoder for å lese og skrive data fra og til autentikatorer (318, 320, 322; 418, 420, 422; 618, 620, 622).

20. System ifølge krav 19, der autentiserbar-grensesnittet returnerer nøkkel-sesjonsnumre for kjeden av autentikatorer (318, 320, 322; 418, 420, 422; 618, 620, 622).

21. System ifølge krav 19, der minst én komponent omfatter en rendrer.

22. System ifølge krav 19, der minst én komponent omfatter en rendrer som

23. System ifølge krav 19, der minst én komponent omfatter én av: en demultiplekser, en dekoder, en videodekoder, en lyd-dekoder, en krypterer, en lyd-krypterer, en video-krypterer og en nettverksrendrer.

24. System ifølge krav 19, videre omfattende: flere beregningsanordninger, der minst én beregningsanordning omfatter en vertsmaskin, og minst én beregningsanordning omfatter en fjernlokalisert beregningsanordning, der de individuelle beregningsanordningene omfatter: nevnte ene eller flere komponenter; og nevnte individuelle komponenter.