NO331575B1 - Systemarkitektur og beslektede fremgangsmater for dynamisk tilfoyelse av programkomponenter, for a utvide systemprosessers funksjonalitet - Google Patents

Abstract

Det er her beskrevet systemer og fremgangsmåter for automatisk installering og anvendelse av mediaprosesseringsfiltre fora utvide mediafunksjonaliteten til systemprosesser. En systemtjeneste blir forespurt av tilvalgsfllteret om å bh installert i systemet. Filteradministreringstjenesten prosesserer forespørselen og installerer filtrene slik at de senere kan bh anropt av andre systemprosesser så som anordningsdrivere, applikasjoner og akkvisisjonsprogramvare. Systemprosessene anvender filteradministreringstjenesten for å liste filtre som er tilgjengelige i systemet og velge ett eller flere av filtrene for å utvide sin mediafunksjonalitet. Filtrene er objekter som til enhver tid kan anvendes av flere prosesser. Filteradministreringstjenesten kan også validere påliteligheten til et filter før installering av filteret i systemet. I tillegg kan filteradministreringstjenesten anvendes for å sørge for at valgte filtre blir anropt fra en prosess som er atskilt fra den prosessen som ber om å anvende filteret. De installerte filtrene kan bh søkt gjennom og listet i henhold til sine assosierte kategorier.

Description

Det tekniske området vedrører generelt datasystemarkitektur, og mer spesifikt operativsystemarkitektur for automatisk tilføying av programkomponenter til systemprosesser.

Med den hurtige fremveksten av digitale mediaanordninger så som DAT (digital audio tape), DVD (digital video discs), digitale videokameraer og digitale fotoapparater, krever brukere av datamaskiner et økt utvalg av maskinvare- og programvarefunksjonalitet for å prosessere og anvende digitale mediafiler. Et stort antall uavhengige maskinvareleverandører (IHV-er, Independent Hardware Vendors) og uavhengige programvareleverandører (ISV-er, Independent Software Vendors) har entret markedet for å imøtekomme denne etterspørselen etter økt mediafunksjonalitet. Nærværet av dette store antallet ISV-er og HSV-er i markedet skaper mange utfordringer for utviklere av operativsystemer og applikasjoner med mediafunksjonalitet. For eksempel har ISV-ene og HSV-ene dannet en rekke uoverensstemmende formater for kodeker og andre filtre. I dag har operativsystemer og applikasjoner begrenset funksjonalitet for å arbeide med mange formater som ikke er i utstrakt bruk.

Filtre er programkomponenter som blir anvendt med mediafiler (f.eks. lyd, video eller stillbilder) for å tjene som kodeker (kodere eller dekodere) for å legge til effekter (f.eks. fargekorrigering, justering av lyshet, etc.) eller for å analysere en fils innhold (f.eks. for å ekstrahere metadata så som antallet mennesker i en gitt bildefil). I dag har flere kodek-standarder (f.eks. JPEG, TIFF) utbredt anvendelse ved desktop publishing for formatering av bildefiler. De fleste operativsystemer, applikasjoner og akkvisisjonsprogrammer støtter slike utbredte standarder. For eksempel jobber akkvisisjonsprogrammet med navnet Scanner and Camera Wizard i Microsoft<®>Windows<®>Me og Microsoft<®>Windows<®>XP fra Microsoft<®>Corporation med skannere og digitale kameraanordninger og omfatter funksjonalitet for å dekode og prosessere TIFF-filer produsert av driverne for skannere og digitale kameraer.

Enkelte produsenter av maskinvare så som digitale kameraer og skannere kan imidlertid foretrekke å anvende kodeker som er spesialkonstruert for å jobbe med deres egne maskinvarekomponenter. For eksempel foretrekker Nikon<®>Corporation å anvende en spesialisert versjon av TIFF-formatet kjent som TIFF/EP for koding og dekoding av digitale bilder. Formatet TIFF/EP har imidlertid ikke utbredt anvendelse eller støtte i operativsystemer eller bildeprosesseringsapplikasjoner. For eksempel støtter ikke operativsystemet Windows<®>XP fra Microsoft<®>Corporation TIFF/EP-formatet for bilder. En bruker av en PC som kjører Windows<®>XP vil således ikke være i stand til å dekode og se en TIFF/EP-bildefil oppnådd fra et Nikon<®>kamera uten å installere en separat visningsapplikasjon. Videre kan enkelte bildeprosesseringsapplikasjoner så som Image Viewer fra Microsoft<®>Corporation ikke utvides til å støtte standarden TIFF/EP fordi de er innrettet for å anvende en standard TIFF-dekoder når en TIFF-type fil blir present-ert for applikasjonen. I dag vil en bruker kunne måtte legge til en TIFF/EP kodek-komponent i sitt Windows XP<®>system og anvende en applikasjon som er spesialkonstruert for å jobbe med TIFF/EP-bilder for å se og manipulere av TIFF/EP-bilder. Det er derfor et økende behov for å gjøre operativsystemer mer fleksible med hensyn til å tillate IHV-er og ISV-er å utvide funksjonaliteten til eksisterende systemprosesser så som anordningsdrivere, akkvisisjonsprogrammer og andre applikasjoner ved å tilveiebringe sine egne proprietære filtre som tilvalgsmoduler til systemprosessene. Det at IHV-er eller ISV-er gis mulighet til å utvide funksjonaliteten til de eksisterende applikasjonene eller akkivisisjonsprogramvare vil også eliminere behovet for å frembringe egentilpassede applikasjoner for å jobbe med spesialiserte filtre, og istedet la ISV-ene og IHV-ene konsentrere seg om å tilveiebringe de beste filtrene som tilvalgsmoduler.

Programvareutviklere er vanligvis forsiktige med å tillate filtre som er utviklet av utenforstående entiteter å bli anvendt som tilvalgsmoduler fordi eventuelle feil i tilvalgsfiltrene potensielt vil kunne påvirke virkemåten til deres egne programkomponenter. Det er således et behov for systemer og fremgangsmåter som på tilfredsstillende måte trygger sikkerheten til systemet eller applikasjonene som anvender tilvalgsfiltrene.

Filterkomponenter installert i et system kom typisk enten sammen med en applikasjon eller er installert for å jobbe spesifikt med visse utvalgte applikasjoner. Vanligvis er mange av de andre applikasjonene i systemet ikke i stand til å aksessere det installerte filterets funksjonalitet. Det er således behov for en åpen og fleksibel systemarkitektur som tillater alle prosesser i et system å utforske og anvende tilvalgsfiltre, slik at et tilvalgsfilter også kan bli anvendt av uspesifiserte applikasjoner og anordningsdrivere.

I tillegg, med den økende etterspørselen etter økt mediafunksjonalitet, blir en rekke filtre med flere mediafunksjonaliteter installert og anvendt i systemer. Det er således behov for en systemarkitektur som er effektiv i det å søke etter og lage en liste over tilvalgsfiltre som er installert og tilgjengelige i et system, slik at en applikasjon eller en bruker (via applikasjonen) kan velge passende tilvalgsmoduler som og når nødvendig.

Videre kan flere filtre som er installert i et system hvert frembringe flere typer mediafunksjonalitet, og noen av filtrene kan ha overlappende funksjonalitet. I enkelte tilfeller kan ett eller flere filtre være spesielt egnet for n viss type mediaprosessering. En bruker eller en systemprosess vil kunne ha behov for å utforske funksjonaliteten til filtre før valg av et passende filter. Én måte å oppnå dette vil være å laste inn filteret i minnet og deretter bestemme dets funksjonalitet. Dette kan imidlertid binde opp systemressurser og gjøre prosessen for tilføyelse av filteret trettende og langsom. Det er således videre et behov for systemer og fremgangsmåter for å kategorisere filtre etter deres funksjonalitet og for å søke, utforske og liste filtrene ved deres kategorisering uten å laste inn filteret i minnet.

US 6,370,686 B1 angår en fremgangsmåte for kategorisering og installering av valgte programvarekomponenter. En spørring sendes for en komponent til installereren og installereren installerer komponenten hvis komponenten ikke allerede har blitt installert. Håndtering av mediafiltre er ikke nevnt. Videre er det å motta en forespørsel om å installere en programvarekomponent (mediafilter) fra programvarekomponenten i seg selv, ikke nevnt eller foreslått.

Som beskrevet her tilveiebringes systemarkitektur og fremgangsmåter for automatisk installering og kalling av mediaprosesseringsfiltre for å utvide media-relatert funksjonalitet for systemprosesser så som media-applikasjoner, akkvisisjonsprogrammer og anordningsdrivere.

I et første aspekt tilveiebringer oppfinnelsen en fremgangsmåte for å administrere mediafiltre, der fremgangsmåten implementeres i en datamaskin som kjører et operativsystem med en system-nivå tjeneste for installering og listing av mediafiltre, idet fremgangsmåten omfatter trinn der: system-nivå tjenesten mottar en forespørsel fra det ene eller de flere mediafiltrene om å installere de ett eller flere mediafiltre; system-nivå tjenesten installerer det ene eller de flere mediafiltrene; system-nivå tjenesten mottar en forespørsel om å liste ett eller flere av de installerte mediafiltrene; og system-nivå tjenesten lister ett eller flere av de installerte mediafiltrene.

I et andre aspekt tilveiebringer oppfinnelsen i et datamaskinsystem som har et operativsystem med en systemtjeneste for administrering av mediafiltre, der tjenesten for administrering av filtre omfatter: kode for å motta forespørseler fra mediafiltre om å bli installert; kode for å installere mediafiltre; kode for å motta forespørseler fra systemprosesser om listing av installerte filtre; og kode for å utforske og liste de installerte filtrene.

Systemarkitekturen kan være åpen og fleksibel slik at tilvalgsfiltre tilveiebrakt av én entitet kan anvendes for å utvide funksjonaliteten til en eksisterende prosess tilveiebrakt av en annen entitet. Systemet gjør det mulig for et tilvalgsfilter å anvende en filteradministreringstjeneste referert til som en tilvalgsmodulstyrer-systemtjeneste for å be om å bli installert i et system. Filteret tilveiebringer selv tilvalgsmodul-styreren med informasjon vedrørende sin funksjonalitet, og tilvalgsmodul-styreren anvender informasjonen for på en identifiserbar måte å installere tilvalgsfilteret i systemet slik at det kan bli anropt opp av en hvilken som helst av systemprosessene.

En tilvalgsmodul-styrer kan respondere til forespørseler fra systemprosesser om å liste tilvalgsfiltre som er tilgjengelig i et system. Prosessene kan da velge fra de listede tilvalgsfiltrene for å utvide sin mediaprosesseringsfunksjonalitet. Filtrene kan være kategorisert etter deres funksjonalitet og særtrekk og de kan bli listet i henhold til en slik kategorisering. I én utførelsesform er tilvalgsmodul-styreren en tjeneste som kan anvendes av hvilke som helst av prosessene som er installert i systemet for å utvide deres mediaprosesseringsfunksjonalitet.

I nok et annet aspekt er tilvalgsfiltre som ber om å bli installert tilveiebrakt med sikkerhetsmekanismer så som digitale signaturer, og tilvalgsmodul-styreren validerer den digitale signaturen før den installerer filteret i systemet. Videre kan prosesser som kaller tilvalgsfiltrene selv be tilvalgsmodul-styreren om kun å liste filtre med valgte digitale signaturer. I tillegg kan tilvalgsmodul-styreren anmodes om å anvende utvalgte tilvalgsfiltre i en prosess som er atskilt fra den prosessen som ber om listing av tilvalgsfiltre, slik at eventuelle feil eller sammenbrudd i tilvalgsfiltrene ikke vil kunne påvirke operasjonen til den prosessen som ber om listingen.

Tilvalgsmodul-styreren kan liste flere filtre fra flere kategorier, og prosessene kan anvende de flere filtrene forbundet i en kjede for å prosessere mediadataene sekvensielt.

Ytterligere særtrekk og fordeler ved systemene og fremgangsmåtene beskrevet her vil åpenbares av den følgende detaljerte beskrivelsen, som henviser til de vedlagte figurene. Figur 1 er et blokkdiagram som illustrerer en statisk metode for å utvide mediafunksjonalitet for systemprosesser ved installering og anvendelse av tilvalgsfiltre. Figur 2 er et blokkdiagram som illustrerer et dynamisk metode for å utvide mediafunksjonalitet for systemprosesser ved automatisk installering og anvendelse av tilvalgsfiltre. Figur 3 er et flytdiagram av en metode for dynamisk og automatisk installering og anvendelse av tilvalgsfiltre for å utvide mediafunksjonalitet for systemprosesser. Figur 4 er et blokkdiagram som illustrerer en systemarkitektur som omfatter en tilvalgsmodul-administreringstjeneste for dynamisk og automatisk installering og anvendelse av tilvalgsfiltre for å utvide mediafunksjonalitet for systemprosesser av forskjellige typer. Figur 5 er en programmatisk representasjon av et grensesnitt mot tilvalgsmodul-styreren, med metoder for å installere, utforske og liste tilvalgsfiltre i et system. Figur 6 er et flytdiagram som beskriver en metode for automatisk installering av tilvalgsfiltre i et system for senere oppkalling fra systemprosesser. Figur 7 er et flytdiagram som beskriver en metode for tilvalgsmodul-administreringstjenesten å prosessere en forespørsel om listing av tilvalgsfiltre i et system. Figur 8 er et flytdiagram som beskriver en metode for tilvalgsmodul-administreringstjenesten å prosessere en forespørsel om listing av tilvalgsfiltre i et system i henhold til inngitte kriterier. Figur 9 er et flytdiagram som beskriver en metode for en systemprosess å velge ett eller flere filtre som er listet av et tilvalgsfilter og anvende det valgte filteret for å utvide sin egen mediaprosesseringsfunksjonalitet. Figur 10 er et flytdiagram som beskriver en metode for et tilvalgsfilter å respondere til et kall fra en systemprosess når den blir valgt av prosessen for å utvide dens mediaprosesseringsfunksjonalitet. Figur 11 viser et brukergrensesnitt tilveiebrakt av tilvalgsfilteret for mottak av én eller flere av sine prosesseringsparametre fra en bruker. Figur 12 er et blokkdiagram som illustrerer en metode for å trygge sikkerheten til en prosess som kaller et tilvalgsfilter ved å separere et ikke-klarert filter fra den prosessen som kaller filterobjektet. Figur 13 er et blokkdiagram som illustrerer en metode for å tillate et klarert filterobjekt å bli anropt innenfra en systemprosess. Figur 14 er et blokkdiagram som illustrerer tilvalgsfiltre sammensluttet i en kjede for sekvensielt å prosessere mediadata. Figur 15 er et blokkdiagram som illustrerer tilvalgsfiltre som mottar utvalgte deler av mediadata og prosesserer de mottatte delene og mater ut de prosesserte delene mens de fortsetter å motta flere deler av mediadataene. Figur 16 er et blokkdiagram som illustrerer flere tilvalgsfiltre med flere typer funksjonalitet som sekvensielt prosesserer deler av en mediafil.

Oversikt

Filtre er programkomponenter som anvendes ved prosessering av medier (f.eks. lyd, video og stillbilder). Filtre kan være kodeker (kodere eller dekodere), analysefiltre eller forsterkerfiltre. Eksempler på kodeker omfatter MPEG for video, JPEG eller TIFF for digitale stillbilder og WAV eller AVI for lydfiler. Kodeker blir primært anvendt for å komprimere mediafiler for effektiv overføring over et nettverk. Forsterkerfiltre, som også refereres til som effekter, blir primært anvendt for å legge til forsterkningseffekter i en mediafil ved å endre bit i et bilde for å bedre dataene eller for å endre dataene (f.eks. økning av lysstyrken i en bildefil eller reduksjon av støy i en lydfil). Analysefiltre ekstraherer data fra bildefilene (f.eks. metadata så som fargen til en bakgrunn i en bildefil). Mange filtre blir levert som standard sammen med operativsystem-programvare (f.eks. Microsoft<®>Windows<®>XP) eller med mediaprosesserings-applikasjoner (f.eks. Adobe<®>Photoshop<®>). Det finnes imidlertid et stort antall filtre som tjener spesialformål som ikke er støttet av en gitt operativsystem-plattform eller gitte applikasjonsprogrammer. Blant annet tilveiebringer systemarkitekturen og fremgangsmåtene beskrevet nedenfor en åpen og fleksibel arkitektur for å legge til filtre som tilvalgsmoduler for å utvide funksjonaliteten til eksisterende systemprosesser.

Figur 1 illustrerer en statisk metode for å utvide funksjonaliteten til et system ved å tilveiebringe tilvalgsmoduler for å utføre spesialoppgaver. I et slikt system kan prosessen 110 (f.eks. anordningsdrivere, applikasjoner eller akkvisisjonsprogrammer) måtte være bevisst tilgjengelige tilvalgsfiltre 125 som er registrert i systemregisteret 120. Prosessen 110 kan da velge et spesifikt tilvalgsfilter-

objekt 125 og anvende en editor 130 (f.eks. Filter Graph Editor fra Microsoft<®>Corporation) for å legge til filteret 125 med andre komponenter så som et innbyg-get filter 140 for å prosessere mediafilen og sende den til en rendringsdestinasjon ved 150 (f.eks. en skjermenhet, høyttalere eller en fil). En slik metode vil være avhengig av at applikasjonen selv er bevisst de eksisterende tilvalgsfiltrene 125 eller at det er tilveiebrakt omfattende kode i applikasjonen selv for å spørre registeret 120 for å sjekke tilgjengeligheten av det eksisterende filteret 125. Dette tynger i betydelig grad arbeidet til applikasjonsutviklere, ettersom det krever at de legger til ekstra linjer med kode for å utføre spørringen og behandlingen av data vedrørende tilvalgsfiltre.

Eksempel på totalt system og fremgangsmåte for dynamisk installering og kalling av tilvalgsfiltre

Figur 2 illustrerer et mer dynamisk og fleksibelt system 200 for å utvide funksjonaliteten til systemprosesser 210 med tilvalgsfiltre 245.1 dette systemet er en systemtjeneste som her refereres til som tilvalgsmodul-styreren 220 tilveiebrakt i form av et komponentobjekt (f.eks. et COM-objekt på en Microsoft<®>Windows<®>plattform) som er tilgjengelig for hele systemet og tjener som et knutepunkt mellom prosesser 210 og tilvalgsfiltrene 245.1 én ende kan således tilvalgsfiltre 245 anvende tilvalgsmodul-styreren 220 for å installere seg i systemet ved 240 og gjøre seg tilgjengelige for prosesser 210.1 den andre enden kan tilvalgsmodul-styreren 220 anvendes av prosesser 210 for å utforske, liste og tilveiebringe grensesnitt mot tilvalgsfiltre, så som filteret 245. Prosessen 210 kan anvende en editor 250 for tilføye tilvalgsfilteret 245 til et innebygget filter 260 for å prosessere en mediafil og sende den til en rendringsdestinasjon 270. Tilveiebringelse av en separat systemtjeneste for å administrere installeringen og leveringen av tilvalgsfiltrene vil ikke avlaste prosessene 210 fra håndteringen av slike kodingstunge oppgaver, men gjør også en slik tjeneste potensielt tilgjengelig for alle prosesser i systemet som kan generere kall til tilvalgsmodul-styreren 220.

Videre tilveiebringer det generelle systemet 200 sammen med tilvalgsmodul-styreren 220 en pålitelig sikkerhetsmodell som sikrer at alle feilut-satte, ikke-klarerte eller ikke-validerte filtre ikke vil kunne ødelegge systemet eller forårsake feil i prosessene 210 som kan anvende tilvalgsfiltrene 245. For eksempel kan tilvalgsmodul-styreren 220 bli anvendt for å validere tilvalgsfiltrene 245 før installering eller registrering i systemet ved 225. Videre kan tilvalgsmodul-styreren 220 bli anvendt for å separere prosessen 210 fra tilvalgsfiltrene 245 ved 215, slik at feil i tilvalgsfiltrene 245 ikke overføres til prosessen 210. Disse og andre aspekter ved systemet 200 vil bli beskrevet mer i detalj nedenfor.

Den illustrerte generelle systemarkitekturen 200 og tilvalgsmodul-styreren 220 kan anvendes for å implementere en metode for dynamisk installering og kalling av tilvalgsfiltre for å utvide funksjonaliteten til systemprosesser 210. Figur 3 illustrerer én slik prosess. Ved 310 kan tilvalgsmodul-styreren anvendes for å installere tilvalgsfilteret i systemet for å bli anropt av én eller flere prosesser assosiert med systemet. Senere, ved 320, kan tilvalgsmodul-styreren 220 anvendes for dynamisk å kalle opp tilvalgsfiltre som skal anvendes av systemprosesser. For eksempel kan tilvalgsmodul-styreren 220 bli anvendt for å generere en forespørsel og tilveiebringe en applikasjon med en liste av filtre som oppfyller visse kriterier. Applikasjonen kan da velge et filter fra listen av filtre, som kan tilveiebringes til applikasjonen for å utføre en spesialoppgave.

Eksempel på systemarkitektur med en systemtjeneste tilgjengelig for prosesser i et system for å installere og anrope tilvalgsmoduler

Figur 4 illustrerer en systemarkitektur med en systemtjeneste for å installere og anrope tilvalgsfiltre. Mer spesielt illustrerer figur 4 en systemarkitektur med en systemtjeneste som er tilgjengelig for alle prosesser i et system for å utforske og anvende tilvalgsfiltre. Prosesser kan omfatte anordningsdrivere 430 (f.eks. en driver for en gitt skannermodell), akkvisisjonsprogrammer 420 som kan bli anvendt for å prosessere data fra anordningen før lagring på en harddisk 470, akkvisisjon-brukergrensesnitt 425 og generelle applikasjoner 410. Tilvalgsmodul-styreren 440 er en systemomspennende tjeneste og kan aksesseres av alle disse prosessene (f.eks. 430,420, 410 og 425). Tilvalgsfiltrene kan også være tilveiebrakt av IHV-ene, ISV-ene eller av tredjepart-leverandører. Et klarert filter tilveiebrakt av en tredjepart-leverandør kan således anvendes for å utvide en driver tilveiebrakt av en IHV eller en applikasjon tilveiebrakt av en ISV. Denne fleksibiliteten vil gjøre det mulig for en bruker å kustomisere sin datamaskin for å øke mediafunksjonaliteten i sitt system.

Funksjonaliteten til anordningsdriverne 430 kan utvides ved å anvende tilvalgsmodul-styreren 440 for å liste tilvalgsfiltrene 455 som er tilgjengelige i systemet og for å velge ett eller flere av de listede filtrene for anvendelse i forbindelse med en konkret oppgave. Tilvalgsfiltrene på driversiden 470 vil kunne anvendes for å prosessere mediadataene uten at brukeren har kjennskap til tilvalgsmodulene. Dersom for eksempel en skanner-produsent vet at gitte modeller skanner farget papir med mørke skygger, kan han tilveiebringe et driver-side 470 tilvalgsfilter 455 for automatisk å korrigere for slike defekter uten at brukeren er klar over dette eller trenger å foreta seg noe.

Videre utfører typiske anordningsdrivere 430 oppgaver i forbindelse med overføring av mediadata fra en anordning (ikke vist) til applikasjonene eller operativsystemet, og prosesserer også de dataene som blir overført. Komponenter av driveren 430 som vedkommer det å overføre dataene mellom en anordning og systemet er typisk de samme for forskjellige modeller av anordningene. Det kan imidlertid bli anvendt forskjellige effekter eller forsterkerfiltre i drivere for forskjellige modeller av anordninger. De komponentene av driveren 430 som er relatert til prosessering av mediadata kan være implementert som tilvalgsfiltre 455, og ved anvendelse av tilvalgsmodul-styreren 440 kan de kalles av driverne kun hvis og når det er behov for dem. Den fleksible systemarkitekturen 400 gjør det således mulig for IHV-er eller utviklere av drivere å tilveiebringe en standarddriver uten spesialfiltre som deles mellom flere modeller av anordninger og tilveiebringer de modellavhengige komponentene i form av tilvalgsmoduler for å utvide standarddriveren. Videre kan også eventuelle oppgraderinger eller andre forbedringer bli tilveiebrakt som tilvalgsmoduler i stedet for at en er nødt til å tilveiebringe en helt ny versjon av anordningsdriveren. Dette resulterer i betydelige kostnadsbesparelser i forbindelse med oppretthold av driverne.

Videre kan IHV-ene anvende tilvalgsmodul-styreren 440 for å erstatte funksjonaliteten til tilsvarende, men innbyggede eller standard filtre i systemet. For eksempel oppfatter skanner-akkvisisjonsprogramvaren i plattformen Microsoft<®>Windows<®>XP dokumentmater-rullene i en skanner som en del av det skannede bildet. For tiden må brukeren manuelt korrigere for dette ved å velge et område som ikke omfatter de skannede rullene. IHV-en kan imidlertid anvende tilvalgsmodul-styreren for å tilveiebringe et tilvalgsfilter som erstatter det innbyggede filteret og automatisk fjerner rullene fra det skannede bildet.

Akkvisisjons-programvaren 420 (f.eks. Scanner and Camera Wizard fra Microsoft<®>Corporation) blir typisk anvendt for å prosessere mediadata etter hvert som de overføres fra anordningen til systemet eller omvendt. Akkvisisjons-programvaren 420 kan anvende tilvalgsmodul-styreren 440 for å utvide sin egen funksjonalitet mye på samme måte som beskrevet ovenfor i forbindelse med driverne 430. For tiden er IHV-ene nødt til å tilveiebringe sin egen akkvisisjons-programvare for å jobbe med et spesialisert filter som ikke vanligvis støttes av standard akkvisisjons-programvare som er inkorporert i operativsystemet. Med systemarkitekturen 400 kan imidlertid akkvisisjons-programvaren som er inkorporert i operativsystemet (f.eks. Scanner and Camera Wizard fra Microsoft<®>Corporation) utvides ved å anvende spesialfiltrene som tilvalgsmoduler. IHV-ene kan således utvide funksjonaliteten til den eksisterende akkvisisjons-programvaren heller enn å erstatte den.

Tilsvarende kan applikasjoner også anvende tilvalgsmodul-styreren 440 for å utforske, liste, velge og anvende de tilvalgsfiltrene 465 som er tilgjengelige i et system ved 460 for å utvide sin funksjonalitet. Tilvalgsmodul-styreren 440, når den er implementert som en systemtjeneste, kan således utvide funksjonaliteten til forskjellige prosesser (f.eks. 410, 420 og 430) på forskjellige nivåer (f.eks. 470, 475 og 480) i prosesseringen av mediadataene.

Oppdelingen av typisk prosessering av mediadata i et system er vist i figur 4 i nivåer (f.eks. 470, 475 og 480) bare for å illustrere det konseptet at tilvalgsmodul-styreren 440 er en systemtjeneste som kan anvendes for å utvide forskjellige typer programvaremoduler. Tilsvarende er oppdelingen av tilvalgsfiltrene 455 og 465 i applikasjons-tilvalgsmoduler 450 og akkvisisjons-tilvalgsmoduler 460 også bare illustrerende, og er ikke essensiell for systemets ønskede funksjon.

Eksempel på systemtjeneste for å installere og kalle tilvalgsmoduler Med henvisning til figurene 5, 6, 7 og 8 vil funksjonaliteten til tilvalgsmodul-styreren 440 nå bli beskrevet mer i detalj. Tilvalgsmodul-styreren 440 kan være implementert som et objekt (f.eks. et COM-objekt) som kan instansieres av systemprosesser, så som en anordningsdriver 420 eller en applikasjon 410. Generelt er tilvalgsmodul-styreren 440 ansvarlig for installering og listing av tilvalgsfiltre 455 og 465 som er tilgjengelige i et system. Figur 5 illustrerer et eksempel på implementering av en tilvalgsmodul-styrer 440, og viser forskjellige metoder som en prosess kan anvende for å utvide sin funksjonalitet samt metoder som utviklere av filtre kan anvende for å installere sine filtre i systemet.

Tilvalgsfiltre så som 455 og 465 kan være kategorisert etter sin funksjonalitet, og tilvalgsmodul-styreren kan søke etter filtre basert på denne kategoriseringen. Det følgende er en mulig liste av standard kategorier av filtre basert på deres funksjonalitet: Kunst, Kunsteffekter, Skarphetsreduksjon, Skarphetsreduksjonseffekter, Farge, Fargeeffekter, Skarphet, Skarphetseffekter, Støy og Støyeffekter. Systemet kan ha mange filtre registrert under slike standard kategorier, mer enn ett filter kan tilhøre en hvilken som helst gitt kategori og ett enkelt filter kan tilhøre mer enn én kategori. Noen ganger eksisterer det imidlertid filtre som ikke sorterer under noen av de standard kategoriene. I et slikt tilfelle kan metoden 510 anvendes for å legge til en privat kategori ved å tilveiebringe en unik identifikator (f.eks. en GUID (Globalt Unik IDentifikator)) kalt en kategori-identifikator, et navn og en beskrivelse av filterets funksjonalitet. Straks filteret er kategorisert og registrert, kan metoden 520 anvendes for å liste alle kategorier i systemet som har minst ett filter tilgjengelig. Det er også mulig å modifisere metoden 520 til å liste alle kategorier som er kjente i systemet eller kun å liste de system-definerte kategoriene. Videre tilveiebringer tilvalgsmodul-styreren 440 også metoder for å slette en kategori. For eksempel sletter metoden 530 en kategori basert på en innsendt unik identifikator assosiert med kategorien. Det å slette en kategori ved anvendelse av metoden 530 vil kunne slette ikke bare kategorien, men også alle filtrene som er assosiert med den slettede kategorien. Tilvalgsmodul-styreren 440 omfatter således funksjonalitet for å administrere tilføyelsen, listingen og slettingen av filtre basert på kategoriene de tilhører, hvilket kan være raskere og mer effektivt enn å gjøre det samme på et filternivå.

Et ytterligere nivå av detalj tilveiebrakt av søk etter og listing av individuelle filtre i stedet for kategorier er også mulig ved anvendelse av tilvalgsmodul-styreren 440. Metoden 540 kan anvendes av en systemprosess for å liste alle filtrene som tilhører en gitt kategori. Kallet til metoden 540 vil kunne måtte spesifisere kategorien ved dens unike identifikator (ID). Videre kan utviklere av filtre anvende metoden 550 for å installere et nytt filter ved å tilveiebringe en kategori-identifikator, en filter-identifikator, et navn samt en beskrivelse av filterets funksjonalitet. Videre kan metoden 560 anvendes for å avinstallere et filter, idet kallet til metoden 560 spesifiserer en filter-identifikator. I tillegg kan metoden 570 anvendes av en systemprosess for å oppnå informasjon vedrørende et gitt filter og avgjøre hvorvidt den skal anvende filteret for å utvide sin egen funksjonalitet.

For å trygge sikkerheten i et system vil prosesser som kaller metoder for å avinstallere eller slette en kategori (530) eller et filter (560) kunne måtte fremvise for tilvalgsmodul-styreren 440 et passende sikkerhetssymbol. Utviklerene av filtre

(f.eks. driver-spesifiserte filtre som er konstruert for å jobbe mot gitte anordninger)

kan også anvende tilvalgsmodul-styreren 440 for å begrense anvendelsen av en gitt privat kategori eller et gitt filter til en gitt anordning eller applikasjon, og således hindre anvendelse derav for andre applikasjoner eller andre anordninger.

Eksempel på prosess for å installere et tilvalgsfilter for dynamisk anrop av en systemprosess

Beskrivelsen i forbindelse med figur 5 over beskrev kort en metode 550 for installering av filtre i et system. Figur 6 illustrerer prosessen med å installere et filter mer i detalj. Ved 610 mottar systemet en tilvalgsmodul som skal installeres i et system. Tilvalgsfilteret kan være et programvare-objekt, som kan være tilveiebrakt sammen med beslektede anordningsdrivere, med installering av nye applikasjoner, etc. Det er også mulig å postere et tilvalgsfilter på en server i et nettverk, slik at brukerne kan aksessere serveren og laste ned tilvalgsfiltrene etter eget ønske. Uansett metoden for å oppnå et tilvalgsfilter, bør utviklerne av filtrene selv være fortrolige med grensesnittet mot tilvalgsmodul-styreren (f.eks. figur 5) for å anvende metodene beskrevet ovenfor til å installere sine filtre i systemet. Ved

620 anvender således tilvalgsfilteret grensesnittet mot tilvalgsmodul-styreren for å adressere et kall fra tilvalgsmodul-styreren om å begynne installeringen av et filter. Filteret tilveiebringer tilvalgsmodul-styreren med sin kategori-identifikator, sin filter-identifikator sitt navn samt en beskrivelse. Da, ved 630, verifiserer tilvalgsmodul-styreren at det filteret som skal legges til er et klarert filter. Filteret som skal legges til er tilveiebrakt med en digital signatur som tilvalgsmodul-styreren gjenkjenner som pålitelig. Ved 640, dersom signaturen ikke er akseptabel, avviser da tilvalgsmodul-styreren ved 650 det filteret som forsøkes lagt til. Ved 640, dersom signaturen er akseptabel, er imidlertid filteret som skal legges til verifisert som pålitelig. Da, ved 660, anvender tilvalgsmodul-styreren parameterene som er tilveiebrakt av tilvalgsfiltrene og installerer dem i systemet. Dersom tilvalgsfiltrene som blir lagt til ikke tilhører en standard filterkategori eller en kategori som systemet allerede kjenner til, vil den som kaller tilvalgsmodul-styreren kunne måtte legge til en kategori (510) i registeret før den installerer noen av sine tilhørende filtre.

Eksempel på prosess for søk etter og

listing av tilvalgsfiltre i et system

Straks filtrene er installert, som beskrevet ovenfor med henvisning til figur 6, kan de bli listet og tilveiebrakt til systemprosesser for å utvide deres funksjonalitet.

Figurene 7 og 8 beskriver en slik generell prosess. Ved 710 mottar tilvalgsmodul-styreren en forespørsel fra en systemprosess om å frembringe en liste over tilvalgsfiltre som er tilgjengelige i systemet og som oppfyller visse kriterier tilveiebrakt av den kallende prosessen. Når tilvalgsmodul-styreren mottar forespørselen om en liste, responderer den da, ved 720, til forespørselen ved å frembringe en liste av tilvalgsfiltre, som leveres til den kallende prosessen.

Kriteriene for å velge filtre som skal listes kan være så enkle som listen av filtre som hører til én eller flere filterkategorier (f.eks. 540). Kriteriene kan også være mer kompliserte, for eksempel å etterspørre listing av filtre som har digitale signaturer knyttet til en gitt klarert entitet. Figur 8 illustrerer en prosess for å liste tilvalgsfiltre som er tilgjengelige i et system basert på et eksempel på sett av kriterier. Ved 810 mottar tilvalgsmodul-styreren en forespørsel fra en prosess om å liste tilvalgsfiltre. Ved 820 identifiserer tilvalgsmodul-styreren alle filtre som hører til de kategorier som er spesifisert i forespørselen fra prosessen. Senere, ved 830, verifiserer tilvalgsmodul-styreren at de valgte filtrene har én eller flere av de digitale signaturene som er spesifisert av den spørrende prosessen. For eksempel kan applikasjoner fra Microsoft<®>Corporation kun ønske å anvende tilvalgsfiltre som har digitale signaturer som Microsoft<®>har validert og godkjent. Videre, ved 840, verifiserer tilvalgsmodul-styreren at de valgte filtrene ikke er eldre enn en gitt utløpsdato som er assosiert med filteret. Dette kan være nyttig dersom filteret har blitt lastet med en prøvelisens av en bruker som enda ikke har kjøpt en gyldig lisens for filteret. Ved 850 blir således kun de filtrene som oppfyller alle kriteriene som er spesifisert av en prosess (f.eks. kategori-identifikator, akseptable digitale signaturer, utløpsdato, etc.) listet. Mer komplekse kriterier vil også kunne avhenge av navnet til eller beskrivelsen av de installerte filtrene. Jo mer komplekse kriterier for filtrene, desto mindre effektiv vil imidlertid listingsprosessen bli. Ett eller flere av kriteriene kan også være satt av én eller flere av tilvalgsmodul-styreren, tilvalgsfilteret og operativsystemet.

Eksempel på prosess for å velge og anvende tilvalgsfiltre

som er tilgjengelige i et system

Når tilvalgsmodul-styreren har frembrakt en liste over filtre i respons til en forespørsel fra en prosess, kan prosessen anvende tilvalgsfilteret for å utvide sin funksjonalitet. Som vist i figur 9, mottar eller aksesserer ved 910 den prosessen som ber om listing av tilvalgsfiltre den frembrakte listen eller tabellen over tilvalgsfiltre. Da, ved 920, velger den prosessen som ber om listingen ett eller flere av de tilgjengelige tilvalgsfiltrene. Deretter, ved 930, mottar den prosessen som ber om listingen en grensesnitt-peker til det valgte filterobjektet. Da, ved 940, anvender prosessen et grensesnitt mot tilvalgsfilteret for å kalle filteret og dets tilhørende metoder for å prosessere valgte mediadata. Det kan også være fordelaktig at prosessen spør eller instruerer tilvalgsmodul-styreren om å kalle filteret, i stedet for at prosessen kaller filteret direkte. Dette vil gjøre at den prosessen som ber om å anvende tilvalgsfiltrene kan bli separert fra filterprosessen, og således være mindre sårbar for feil i filteret.

Listen av filtere kan bli vist for en bruker via et brukergrensesnitt mot en applikasjon eller et akkvisisjonsprogram, slik at brukeren kan velge et filter fra listen. Det er imidlertid ikke alltid nødvendig eller ønsket å tilveiebringe en slik liste for brukeren. I så fall kan applikasjonene eller andre systemprosesser automatisk velge fra listen over tilvalgsfiltre.

Når prosessen kaller et valgt tilvalgsfilter for å prosessere mediadataene, kan prosessen eller tilvalgsmodul-styreren (som kan være mellommann) over-bringe kontrollen over prosesseringen til filteret selv. Som vist i figur 10, ved 1010, kan tilvalgsfilteret tilveiebringe et brukergrensesnitt for at en bruker skal kunne legge inn parametere for prosessering av mediadata. Figur 11 illustrerer ett slikt eksempel på brukergrensesnitt for å legge inn brukerdefinerte parametere for et spreder-effektfilter. Alternativt krever ikke filterets funksjonalitet inndata fra en bruker, eller ikke noen prosessparametere i det hele tatt (f.eks. krever enkelte analysefiltre kun innmating av mediadata, og kan returnere ett eller flere sett av metadata som utdata). Ved 1020 anvender tilvalgsfilteret de spesifiserte parametrene for å prosessere mediadataene. Da, ved 1030, returnerer tilvalgsfilteret de prosesserte dataene til den prosessen som anroper tilvalgsfilteret eller et annet filter for fortsettelse av prosesseringen av mediadataene. De prosesserte dataene kan deretter bli levert til en rendringsdestinasjon så som en visningsskjerm eller en høyttaler.

Eksempel på sikkerhetsmodell for et system

for å installere og anrope tilvalgsfiltre Systemarkitekturen i figur 4, som gjør det mulig for systemprosesser å utvide sin funksjonalitet ved anvendelse av tilvalgsfiltre, er åpen og fleksibel. Dette er fordelaktig i det at en slik åpen og fleksibel arkitektur gjør det mulig for en

bruker å legge til spesialiserte mediaprosesseringskomponenter i sin datamaskin. Dette gjør imidlertid også et system sårbart for eventuelle feil og bugs i et tilvalgsfilter tilveiebrakt av en ISV, en I HV eller en tredjepart. Utviklere av operativsystem-programvare eller applikasjoner har alltid vært forsiktige med å tillate brukeren å utvide deres prosesser ved anvendelse av komponenter tilveiebrakt av utenforstående parter på grunn av denne økte sikkerhetsrisikoen. Som beskrevet ovenfor kan imidlertid noe av denne frykten adresseres ved å kreve at tilvalgsfiltre blir til-

veiebrakt sammen med digitale signaturer som kan godtgjøre at de opprettholder sikkerheten. For eksempel kan tilvalgsmodul-styreren være innrettet for å kreve at alle tilvalgsfiltre tilveiebringer én eller flere godkjente digitale signaturer (se f.eks. 630). Videre, også etter at et tilvalgsfilter er godkjent for installering i et system, kan prosesser som ber om tilvalgsfiltre spesifisere ytterligere sikkerhetskriterier for tilvalgsmodul-styreren slik at kun de filtrene som oppfyller disse kriteriene blir listet for valg (se f.eks. 830).

I tillegg illustrerer figurene 12 og 13 nok en annen sikkerhetsmekanisme for å skjerme prosesser mot eventuelle feil eller bugs i tilvalgsfiltre som anvendes for å utvide deres funksjonalitet. Som vist i figur 12 kan prosessen 1210 forespørre tilvalgsmodul-styreren 1220 om å frembringe en liste over tilgjengelige tilvalgsfiltre 1230. Prosessen kan også anmode tilvalgsmodul-styreren 1220 om å identifisere de digitale signaturene assosiert med hvert av tilvalgsfiltrene. De filtrene som ikke er i stand til å frembringe én eller flere spesifiserte, godkjente digitale signaturer kan bli plassert i en "sandkasse" 1240, slik at de valgte filtrene 1250, 1251 og 1253 kan anvendes utenfor prosessen 1210. Prosessen 1210 kan således være isolert fra de valgte filtrene 1250, 1251 og 1253, slik at eventuelle feil eller bugs i filtrene ikke vil kunne forårsake at prosessen 1210 bryter sammen under opera-sjon. Prosessen 1210 vil imidlertid likevel kunne motta utdata fra filtrene 1250, 1251 og 1253.

Sandkasse-metoden som vist i figur 12 kan resultere i en merkbar reduksjon av hastigheten ved prosessering av mediafiler. Under visse omstendigheter kan det derfor være fordelaktig at filteret blir anvendt innenfor prosessen 1210 selv. Figur 13 illustrerer et valgt tilvalgsobjekt 1320 som blir kalt og anvendt innenfor en prosess 1320. Selv om dette typisk resulterer i en hurtigere prosessering, presenterer det også en risiko for at prosessen 1310 vil kunne bryte sammen som følge av feil i tilvalgsfilteret 1320. Tilvalgsmodul-styreren 1340 kan derfor bli anvendt for å verifisere de digitale signaturene til tilvalgsfiltre, slik at kun filtre som fremviser godkjente signaturer 1320 kan anropt og anvendt innenfor prosessen 1310.1 motsatt fall kan tilvalgsfiltrene bli kjørt utenfor prosessen 1310 som vist i figur 12. Dersom for eksempel en applikasjon mottar verifikasjon av et filters pålite-lighet fra tilvalgsmodul-styreren 1340, kan applikasjonsprosessen 1310 laste inn filteret som skal kalles via sitt eget brukergrensesnitt. En slik innretning vil gjøre det mulig for utviklere av filtre å avertere sine egne merker også når de blir anvendt i en annen entitets programvare.

Eksempler på særtrekk ved tilvalgsfiltrene som skal anvendes for

dynamisk å utvide funksjonaliteten til systemprosesser Tilvalgsfiltrene som blir anvendt av en tilvalgsmodul-styrer for å utvide funksjonaliteten til en prosess (som muliggjort av systemarkitekturen i figur 4) vil kunne måtte omfatte en viss standard funksjonalitet for å jobbe effektivt mot tilvalgsmodul-styreren og systemprosesser. For eksempel er tilvalgsfiltre i stand til å motta flere typer inndata og tilveiebringe flere typer utdata. Ett slikt filter er et sammenføyningsfilter som kan ta som inndata flere bilder og produsere ett bilde som utdata. Videre kan et dokumentskanningsfilter ta inn ett bilde og produsere flere typer utdata, så som bilder og tekstdata. Eksempler på filtre som produserer andre typer utdata enn bilder omfatter annoteringsgeneratorer og bildemålings-filtre. En annoteringsgenerator kan ekstrahere data så som datoen fra et dato-merke i bildet, eller hvorvidt det er mennesker i et bilde. Et bildemålingsfilter kan produsere et histogram eller måle aspekter ved et forhåndsvist skannerbilde som skal anvendes for å sette skanningsparametere.

Videre bør tilvalgsfiltre være i stand til å motta sine inndata fra et annet filterobjekt og også å sende sine egne utdata til et annet filterobjekt. Som vist i figur 14 kan tilvalgsfiltrene 1410, 1420 og 1430 være forbundet i et kjede, slik at mediadata 1440 kan prosessert ved anvendelse av flere filtre 1410, 1420 og 1430 på en gang. Ellers må hvert av tilvalgsfiltrene 1410, 1420 og 1430 prosesseres separat og rendres og deretter prosesseres igjen av et annet filter. Dette kan være tidkrevende. Med funksjonaliteten til filtrene som skal assosieres i en kjede kan tilvalgsmodul-styreren liste flere filtre, og applikasjonene kan velge flere effektfiltre samtidig for å utvide sin funksjonalitet.

Nok et annet særtrekk ved tilvalgsfiltrene er illustrert i figur 15. Generelt er filtre kun i stand til å prosessere deler av en komplett innmating av mediadata. For eksempel, i forbindelse med mediaprosessering, kan filtre så som tilvalgs-effektfilteret 1510 være i stand til å motta deler av et helt bilde (f.eks. identifisert ved deres koordinater), prosessere denne valgte delen og mate den ut til en rendringsdestinasjon 1530.1 denne forbindelse, når et bilde blir manipulert av en applikasjon via et filter, kan et originalt utsnitt av bildet vedvare mens deler av bildet blir endret av effekten. Dette vil gjøre det mulig for applikasjonen å tilveiebringe brukeren med et nær momentant utsnitt av virkningen til en tilvalgsmodul. Dersom for eksempel virkningen ikke er ønsket, kan tilvalgsmodulen velges bort. Selv om figur 15 anvender et eksempel med en bildefil for å illustrere denne filter-egenskapen, kan andre medier (f.eks. lyd eller video) bli prosessert på samme måte med sine respektive filtertyper.

Som vist i figur 16, kan muligheten for å forbinde tilvalgsfiltre i en kjede (figur 14) og muligheten for å prosessere deler av en mediafil kombineres for å forbinde flere filtre i en kjede og betrakte eller lytte til virkningen til tilvalgsfiltre mens deler av inndatafilen blir prosessert. For eksempel kan deler av et helt bilde ved 1610 skaleres ved 1620, og deretter kan den utvalgte delen negeres ved 1630 for å fjerne et rødt øye før bildet rendres ved 1640.

Fremgangsmåtene og systemene beskriver funksjonaliteten til flere system-komponenter så som systemtjenestens tilvalgsmodul-styrer, tilvalgsfiltre og systemprosesser. Det skal være underforstått at funksjonaliteten tillagt disse og alle andre komponenter beskrevet ovenfor også kan bli utført av hvilke som helst av de andre relaterte komponentene dersom de er programmert til å gjøre dette.

Videre diskuterer eksemplene prosessering av konkrete typer medier (f.eks. video, lyd, bilder, etc), men konseptene som ligger bak eksempelet er like an-vendbare for alle former for mediadata. I lys av de mange mulige utførelsesform-ene vil det forstås at de illustrerte utførelsesformene kun omfatter eksempler og ikke skal betraktes som en begrensning av oppfinnelsens ramme. I stedet skal oppfinnelsen defineres av de etterfølgende patentkravene. Vi krever derfor som oppfinnelsen alle slike utførelsesformer som faller innenfor rammen til disse kravene.

Claims (26)

1. Fremgangsmåte for å administrere mediafiltre (245), der fremgangsmåten implementeres i en datamaskin som kjører et operativsystem med en system-nivå tjeneste for installering og listing av mediafiltre (245), idet fremgangsmåten omfatter trinn der: system-nivå tjenesten (220) mottar en forespørsel fra det ene eller de flere mediafiltrene (245) om å installere de ett eller flere mediafiltre (245); system-nivå tjenesten (220) installerer det ene eller de flere mediafiltrene (245) system-nivå tjenesten mottar en forespørsel om å liste ett eller flere av de installerte mediafiltrene; og system-nivå tjenesten lister ett eller flere av de installerte mediafiltrene.

2. Fremgangsmåte ifølge krav 1, videre omfattende en prosess (210) som benytter et grensesnitt til system-nivå tjenesten (220) for å anrope ett av de ett eller flere listede mediafiltrene (245) for å prosessere mediadata (1440).

3. Fremgangsmåte ifølge krav 1, der forespørselen om å liste de installerte mediafiltrene (245) mottas fra den ene eller de flere prosessene (210) assosiert med datamaskinen.

4. Fremgangsmåte ifølge krav 1, der de installerte mediafiltrene (245) listes i henhold til én eller flere kategorier svarende til mediafiltrene (245).

5. Fremgangsmåte ifølge krav 4, der hver av kategoriene svarer til en unik system-omspennende identifikator og forespørselen om å liste filtrene (245) omfatter den unike kategori-identifikatoren.

6. Fremgangsmåte ifølge krav 1, videre omfattende det å bestemme akseptabiliteten til én eller flere digitale signaturer assosiert med det ene eller de flere mediafiltrene (245) før installering av filtrene (245).

7. Fremgangsmåte ifølge krav 6, videre omfattende det å bestemme akseptabiliteten til den ene eller de flere digitale signaturene assosiert med filtrene (245) før listing av de installerte filtrene (245).

8. Fremgangsmåte ifølge krav 1, videre omfattende det å bestemme akseptabiliteten til én eller flere digitale signaturer assosiert med filtrene (245) før listing av de installerte filtrene (245).

9. Fremgangsmåte ifølge krav 8, videre omfattende det å separere fra prosessene (210) som ber om listing av de installerte filtrene (245) de filtrene (245) som bestemmes å ikke ha akseptable digitale signaturer.

10. Fremgangsmåte ifølge krav 8, der akseptabiliteten til de installerte filtrene (245) for listing bestemmes i henhold til kriterier som mottas fra den prosessen som ber om listing.

11. Fremgangsmåte ifølge krav 8, der akseptabiliteten til de installerte filtrene (245) i systemet for listing bestemmes i henhold til kriterier som mottas fra én eller flere av følgende: den prosessen (210) som ber om listing; de installerte filtrene (245); og operativsystemet.

12. Datamaskinlesbart medium omfattende datamaskin-eksekverbare instruksjoner for å utføre fremgangsmåten ifølge krav 1.

13. Fremgangsmåte ifølge krav 1, der mediafiltrene (245) forbindes i en kjede og innmatede mediadata (1440) prosesseres sekvensielt av mediafiltrene (245) i kjeden.

14. Fremgangsmåte ifølge krav 1, der et hvilket som helst av mediafiltrene (245) kan anvendes av flere prosesser samtidig.

15. Fremgangsmåte ifølge krav 1, der forespørselen om å installere det ene eller de flere mediafiltrene (245) omfatter én eller flere av følgende: én eller flere unike identifikatorer svarende til kategorier assosiert med mediafiltrene (245); én eller flere unike identifikatorer svarende til mediafiltrene (245); ett eller flere navn svarende til mediafiltrene (245); én eller flere beskrivelser av mediafiltrene (245); og én eller flere digitale signaturer assosiert med hvert av mediafiltrene (245).

16. Fremgangsmåte ifølge krav 1, der det ene eller de flere mediafiltrene (245) er installert i datasystemet i henhold til unike identifikatorer relatert til hvert av filtrene (245).

17. Fremgangsmåte ifølge krav 1, der hvert av det ene eller de flere mediafiltrene (245) svarer til en filterkategori og det ene eller de flere filtrene (245) er installert i henhold til deres tilhørende kategori.

18. Fremgangsmåte ifølge krav 17, der det ene eller de flere filtrene (245) som er installert i datasystemet blir listet i henhold til deres tilhørende kategori.

19. Fremgangsmåte ifølge krav 17, videre omfattende kode for å slette den ene eller de flere kategoriene svarende til det ene eller de flere filtrene (245) som er installert i datasystemet.

20. Fremgangsmåte ifølge krav 19, der sletting av den ene eller de flere kategoriene resulterer i sletting av deres tilhørende filtre (245) fra datasystemet.

21. Fremgangsmåte ifølge krav 1, videre omfattende kode for å slette det ene eller de flere filtrene (245) som er installert i datasystemet.

22. I et datamaskinsystem som har et operativsystem med en systemtjeneste for administrering av mediafiltre (220), der tjenesten (220) for administrering av filtre omfatter: kode for å motta forespørseler fra mediafiltre (245) om å bli installert; kode for å installere mediafiltre (245); kode for å motta forespørseler fra systemprosesser (210) om listing av installerte filtre (240); og kode for å utforske og liste de installerte filtrene (240).

23. Tjeneste for administrering av filtre ifølge krav 22, videre omfattende en prosess (210) som benytter et grensesnitt til en tilvalgsmodul-styrer for å anrope ett av de ett eller flere listede mediafiltrene (240) for å prosessere mediadata (1440).

24. Tjeneste for administrering av filtre ifølge krav 22, videre omfattende kode for å bestemme gyldigheten til mediafiltrene (245) før installering av mediafiltrene (245).

25. Tjeneste for administrering av filtre ifølge krav 22, videre omfattende kode for å velge filtrene (245) som skal listes i henhold til kriterier spesifisert av de system prosessene (210) som ber om listing av filtrene (245).

26. Tjeneste for administrering av filtre ifølge krav 22, videre omfattende kode for å velge ett eller flere av de listede filtrene (245) for å bli anropt som en prosess (210) som er atskilt fra systemprosessene som ber om listing.