Disclaimer: This text has been machine-scanned and may contain errors – please refer to "Publications" for legally binding content.
En datafremgangsmåte er beskrevet for å enkapsulere multimedia-innholdsdata, multimedia- innholdsbeskrivelsesdata og program-instruksjonskode i en aggregert •datarepresentasjon som omfatter en logisk struktur. Fremgangsmåten omfatter: - å lagre på en lagringsenhet informasjon om multimedia-innholdsdataene, multimedia-innhoidsbeskrivelsesdataene og program-instruksjonskoden for å lage en main header seksjon (300) i den logiske strukturen; - å lagre på lagringsenheten flere blokk headere for alle multimedia-innholdsdata, multimedia-innholdsbeskrivelsesdata og program-instruksjonskoden for å lage en blokk header seksjon (301) i den logiske strukturen; og - å lagre på lagringsenheten flere datablokker for alle multimedia-innholdsdata, multimedia-innholdsbeskrivelsesdata og program-instruksjonskoden for å lage en datablokk-seksjon (302) i den logiske strukturen.
Publications
B1A
Checking availability of the latest published version...
Documents
ExpandDownload files (2)
Date
Date
Doc. No.
Process
Case number
In/Out
Journal description
To/from
23.04.2014
17-01
Saksbehandling
20024640
UT
PT Batch Opphørt Patent - SPC for ikke betalt årsavgift (3311)
02.12.2013
16-01
Saksbehandling
20024640
UT
Batch STARTGRACE Patent varsel ikke betalt
06.12.2011
15-01
Saksbehandling
20024640
UT
Grace period has started (Patent) (2011.12.06)
16.10.2006
14-01
Saksbehandling
20024640
UT
Generelt Brev Patent (2006.10.16)
06.01.2006
13-01
Saksbehandling
20024640
UT
Grace period has started (Patent) (2006.01.06)
26.04.2005
12-01
Saksbehandling
20024640
UT
PT RegistreringsBrev (2005.04.26)
20.04.2005
11-01
Saksbehandling
20024640
UT
Patent Specifications (2005.04.20)
14.04.2005
10-04
Saksbehandling
20024640
INN
Krav
14.04.2005
10-02
Saksbehandling
20024640
INN
Sammendrag
14.04.2005
10-01
Saksbehandling
20024640
INN
Korrespondanse (hoved dok)
27.12.2004
09-01
Saksbehandling
20024640
UT
PT Medelelse om patent (2004.12.27)
20.10.2004
08-01
Saksbehandling
20024640
UT
Patent First Page (2004.10.20)
15.09.2004
07-04
Saksbehandling
20024640
INN
Patenttegninger
15.09.2004
07-03
Saksbehandling
20024640
INN
Krav
15.09.2004
07-02
Saksbehandling
20024640
INN
Beskrivelse
15.09.2004
07-01
Saksbehandling
20024640
INN
Korrespondanse (hoved dok)
15.06.2004
05-01
Saksbehandling
20024640
UT
PT Realitet_patent (2004.06.15)
08.06.2004
03-01
Saksbehandling
20024640
INN
Korrespondanse
03.05.2004
02-01
Saksbehandling
20024640
UT
ALL Reinstatement request refusal letter (2004.05.03)
29.03.2004
06-02
Saksbehandling
20024640
INN
Krav
29.03.2004
06-01
Saksbehandling
20024640
INN
Korrespondanse (hoved dok)
26.01.2004
01-04
Saksbehandling
20024640
INN
Patenttegninger
26.01.2004
01-03
Saksbehandling
20024640
INN
Krav
26.01.2004
01-02
Saksbehandling
20024640
INN
Beskrivelse
26.01.2004
01-01
Saksbehandling
20024640
INN
Korrespondanse (hoved dok)
1a
Saksbehandling
20024640
INN
Sammendrag
Description, claims and drawings
Disclaimer: This text has been machine-scanned and may contain errors – please refer to "Publications" for legally binding content.Description
Oppfinnelsen er generelt sett relatert til data behandlingssystemer, og mer spesifikt til et format for å inneholde og/eller beskrive multimedia innhold som kan inkludere program instruksjonskode for å kontrollere avspilningen av multimedia innholdet.Det eksisterer en rekke fil- og/eller strømningsformater innen det tekniske feltet for oppfinnelsen. Noen eksempler på dette er:Disse formatene er typisk brukt til å inneholde og beskrive multimedia innhold for bruk på internett. Filen eller strømmen som er basert på formatet blir overført via et nettverk til en destinasjons datamaskin som inneholder en avspiller, som prosesserer og viser innholdet. Historisk sett ble disse formatene konstruert og utviklet for destinasjons maskiner med kraftige maskinvareressurser (mikroprosessor, lager, grafikk-kort, osv.), som personlige datamaskiner (PCer). Typisk støtter de fleste av disse formatene media typer som bilder og tekst. Noen støtter også video, lyd og 3D grafikk.Konvensjonelle fil- og/eller strømningsformater for å inneholde og/eller beskrive multimedia innhold som kan inkludere program instruksjonskode, haren rekke begrensninger. Innledningsvis, kan det nevnes at formatene typisk ikke hensyntar at innholdet må kunne benyttes på enhver form for klasse av maskiner, fra maskiner med svært begrensede maskinvareressurser (mikroprosessor, minne, lager, grafikkort, osv.), til maskiner med kraftige maskinvareressurser. Slike formater krever typisk en implementasjon av avspilleren som vil være for stor i forhold til lagrings- eller minneplass som blir brukt av program instruksjonskoden, eller bruker for mye av maskinvareressursene, for maskiner med svært begrensede maskinvare ressurser (som f.eks. håndholdte enheter). En annen begrensning med slike formater er at de generellt sett er begrenset i fleksibilitet for å representere ulike typer media. Slike formater støtter et ganske begrenset sett med predefinerte multimedia innholdstyper. De støtter som regel ikke ekte 3D grafikk (teksturen polygon mesh), som er viktig for å kunne lage gode illustrasjoner av fysiske objekter i en multimedia avspilning. En ytterligere begrensning med slike formater er at de typisk ikke er istand til å inneholde ulike nivåer av innholdsskaleringer for ulike destinasjonsmaskiner. Det er ikke sikkert at maskiner med begrensede ressurser vil være istand til å spille av komplekse kombinasjoner av multimedia innhold. Det er ikke sikkert at maskiner med en treg nettverksforbindelse vil være istand til å laste ned/strømme større mengder med multimedia data, som video og audio. Medi innholdsskalering er det mulig å ivareta flere representasjoner av det samme innholdet for ulike destinasjonsmaskiner. Enda en svakhet med slike formater er at de ikke ikke kan tilby en god nok komprimering for rask overføring over overføringsmedium. Slike formater tilbyr ikke alltid strømningsmuligheter, slik at destinasjons avspilleren kan spille av multimedia innholdet samtidig med at multimedia innholdet blir overført via overføringsmediet.Den US-patent søknad US 20020062313 Al beskriver et system og en metode relatert til filstruktur for et strømningstjente. Metoden omfatter filstruktur en objektoverskrift inneholdende informasjoner relaterte til en fil og til en applikasjonstjeneste, et dataobjekt inneholdende multimedia data og et nøkkel-indeksobjekt for lagring av informasjoner relatert en mediablokk.Den US-patent søknad US 6,061,054 A beskriver et system og en metode for fremvisning av informasjoner ved hjelp av en multimedia-applikasjon, hvor multimedia-applikasjonen omfatter en ekstern datafil inneholdende data relatert til kontroll av applikasjonen, et ekstern fil-innhold innbefatter forskjellige medier, og et ekstern fil-program som benyttes til å prosessere datafilen og fil-innholdet som er lagret i systemet.Den europeiske patentsøknad EP 1113360 A2 beskriver et system og en metode relatert til informasjonsbehandling, hvor et informasjonsinnhold som overføres fra en sender til en mottaker omfatter en program-kode som benyttes til å prosessere informasjonsinnholdet. Systemet omfatter i
tillegg anordninger for blant annet å frembringe program-koden fra informasjonsinnholdet og å lagre det i et lager.US-patentsøkand US 6,073,166 A beskriver et system og en metode for overføring av informasjoner via et nettverk, hvor informasjonsinnhold omfatter deler inneholdende et adresseoverskrift, et informasjonsinnholdoverskrift og en data program-kode som benyttes til å kjøre informasjonsinnhold.Et format er defined og tatt I bruk for en logisk struktur som enkapsulerer og/eller beskriver multimedia innhold som kan inkludere program instruksjonskode for å kontrollere avspillningen av multimedia innholdet. Multimedia innholdet kan bestå av forskjellige media. Data til multimedia innholdet er partisjonen i blokker som er passende for overføring over et overføringsmedium. Blokkene kan inkludere beskrivelse av multimedia innholdet og/eller multimedia innholds dataene. Blokkene kan også inkludere program kode som kan være tolket og/eller eksekvert på destinasjons avspillerne. Blokkene kan være komprimerte og/eller krypterte.Oppfinnelsen inkluderer et datasystem som har en logisk struktur for å enkapsulere multimedia innholds som er partisjonen i blokker for å bevare og/eller beskrive multimedia innholdet som kan inkludere program instruksjonskode for å kontrollere avspillningen av multimedia innholdet. En data metode for å lage, overføre, og spille av innholdet, basert på den logiske strukturen, er også inkludert.I henhold til et første aspect gir oppfinnelsen; en metode, i et datasystem, for å enkapsulere multimedia innholds data, multimedia innholds beskrivelses data, og program instruksjonskode i en aggregert data representasjon omfattende en logisk struktur, hvor metoden omfatter å lagre på en lagringsenhet, informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode for å lage en main header seksjon i den logiske strukturen; lagre på en lagringsenhet, flere blokk headere for alle multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode for å lage en blokk header seksjon i den logiske strukturen; og lagre på en lagringsenhet, flere data blokker for alle multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode for å lage en data blokk seksjon i den logiske strukturen.I en foretrukken legemliggjørelse omfatter metoden videre å avgjøre lagringsrekkefølgen for ressursene, for de ulike multimedia typene, f.eks. audio, video, image og text, for å oppnå effektiv strømningsoverføring; komprimering av data i noen av data blokk seksjonene med bruk av passende komprimerings metoder, f.eks. ZLIB, PNG eller JPEG; og lage ulike skalerte innholds representasjoner av en eller flere scener, avhengig av ulike maskinvare profiler av destinasjonsmaskiner, f.eks. bitrate, skjerm, språk, og/eller maskin.I en videre foretrukken legemliggjørelse overføres den aggregerte data representasjonen eller den logiske strukturen over et overføringsmedium til en eller flere destinasjonsmaskiner. Linking mellom flere filer med multimedia innhold kan oppnås med å bruke et externaljink felt i blokk headers seksjonen.I henhold til enda et aspekt, gir oppfinnelsen, i et datasystem, en metode for å motta multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskode fra en aggregert data representasjon lagret på en lagringsenhet, hvor data representasjonen omfatter en logisk struktur som enkapsulerer multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskode, hvor metoden omfatter å lese fra lagringsenheten en main header seksjon (300) til den logiske strukturen, hvor main header seksjonen har informasjon om multimedia innholds dataene, multimedia innholds beskrivelsesdata, og program instruksjonskoden; flere header blokker fra header seksjonen (301) til den logiske strukturen, hvor de fler blokk headerene innbefatter informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskoden; og flere data blokker fra data seksjonen (302) til den logiske strukturen, hvor de flere data blokkene innbefatter multimedia innholds data, multimedia innholds bekrivelsesdata, og program instruksjonskode.Metoden omfatter videre mottak av den aggregerte data representasjonen eller den logiske strukturen over et overføringsmedium på en destinasjonsmaskin, for umiddelbart, eller på et senere tidspunkt, å spille av innholdet ved hjelp av en avspiller.I en legemliggjørelse at blokk header seksjonene innbefatter en scene blokk header; blokk header seksjonen innbefatter en image ressurs blokk header, en text ressurs blokk header, en mesh ressurs blokk header, eller en video ressurs blokk header; data blokk seksjonen innbefatter en scene data blokk; data blokk seksjonen innbefatter en image ressurs data blokk, en text ressurs data blokk, en mesh ressurs data blokk, eller en video ressurs data blokk; antallet data blokker i data blokk seksjonen er lik to antallet blokk headere i blokk header seksjonen med et tomt externaljink felt; og program instruksjonskoden kontrollerer avspilling av multimedia innholdet. Den logiske strukturen kan være en XML formattert struktur.I et ytterligere aspekt, gir oppfinnelsen en maskin-lesbar aggregert data representasjon som enkapsulerer multimedia innholds data, multimedia innholds beskrivelsesdata, and program instruksjonskode, hvor den aggregerte data representasjonen omfatter en logisk struktur lagret på en maskin lesbar lagringsenhet, hvor den logiske strukturen omfatter; en main header seksjon som omfatter informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode i en logisk struktur som definerer den aggregerte data representasjonen; en blokk header seksjon som omfatter flere blokk headere for multimedia innholds dataene, multimedia innhold beskrivelsesdataene, og program instruksjonskoden; og en data blokk seksjon som omfatter flere data blokker for alle multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode. Den logiske strukturen kan være også i dette tilfellet være en XML formattert struktur.Oppfinnelsen gir også i et videre aspekt et maskin-lesbar lagringsmedium som oppbevarer instruksjoner for enkapsulering av multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode i en aggregert data representasjon som omfatter en logisk struktur, i henhold til encapsuleirngsmetoden beskrevet ovenfor. Videre i et annet aspekt gir oppfinnelsen et maskin-lesbart lagringsmedium som oppbevarer instruksjoner for å hente multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode fra en aggregert data representasjon lagret på en lagringsenhet, hvor data representasjonen omfatter en logiske struktur som enkapsulerer multimedia innholds dataene, multimedia innholds beskrivelsesdataene, og program instruksjonskoden, hvor instruksjonene omfatter å lese fra lagringsenheten: en main header seksjon av den logiske strukturen, hvor main header seksjonen har informasjon om multimedia innholds dataene, multimedia innholds beskrivelsesdataene, og program instruksjonskoden; flere header blokker fra header seksjonen til den logiske strukturen, hvor de flere blokk headerene omfatter informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode; og flere data blokker fra data seksjonen i den logiske strukturen, hvor de flere data blokkene omfatter multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode.Oppfinnelsen gir opphav til et format (GX) for å bevare og/eller beskrive multimedia innhold som kan inkludere program instruksjonskode for å kontrollere avspillingen av multimedia innholdet. En GX fil/strøm kan også kalles en GX movie. En GX movie kan inneholde en eller flere scener, og/eller en eller flere ressurser, inneholdt I en block-basert struktur. En scene spesifiserer innholdsbeskrivelsen og layout data, an/eller program instruksjonskode for kontroll av avspillingen av multimedia innholdet. En ressurs kan inneholde spesifikke dataenheter, som images, text video, osv. FIG. 14 viser et eksempel på to GX filer (1400 og 1401). File 1 inneholder en image ressurs ("Image resource 1"), en scene ("Scene 1"), og linker til to ressurser i File 2. File 2 inneholder en image ressurs ("Image resource 2") og ("Text resource 2").GX er vellegnet for effektiv bruk på enhver klasse maskin, fra maskiner med svært begrensede maskinvare ressurser (f.eks. håndholdte enheter som mobiltelefoner, PDA'er og set-top bokser for interaktiv TV), til maskiner med kraftige maskinvare ressurser. GX bruker et blokk-basert format for å bevare og/eller beskrive multimedia innhold. Siden det blokk-baserte formatet er relativt faltt og ukomplekst, i strukturell organisering, er det enkelt å prosesserer og spille av på destinasjonsmaskinen. Dette resulterer i en svært liten avspiller implementasjon, og svært lite bruk av maskinvare ressurser på destinasjonsmaskinen.GX er fleksibel med hensyn på ulike media typer og/eller program kode typer som den kan inneholde. Den blokk-baserte strukturen til formatet gjør det lett å utvide med bred variasjon av media typer.
Avhengig av verdien på type feltet, kan header og data blokkene inneholde et større antall forskjellige media typer, begrenset bare av de ulike renderer implementasjonene. GX gir god støtte for innholdsskalering. Forfatteren kan skalere scenen med hensyn på bitrate (båndbredde), språk (Norsk, Engelsk, osv.), skjerm (oppløsning, refresh, osv.), og maskin (maskinklasse). Videre kan forfatteren dele det skalerte innholdet I flere filer some r linket sammen med bruk av external_link feltet, som er viktig for rask lasting av en spesifikk innholdsskalering av destinasjonen sin avspiller. Se eksempel i FIG. 14.GX er svært effektiv med hensyn til kompakthet I bevaring av multimedia innhold. De individuelle blokkene, eller data i blokkene, kan bruke ulike komprimerings metoder, som ZLIB, PNG eller JPEG komprimering. Forfatteren kan spesifisere hvilken komprimeirngsmetode som skal brukes i innholdsutviklingsfasen. GX støtter streaming overføring, slik at destinasjonsavspilleren kan vise multimedia innholdet mens multimedia innholdet blir overført over overføringsmediet. GX bruker ressurser for å lagre de ulike media typene, som scenene bruker. Se eksempler i FIG. 5, 6,12, og 13. Figurene illustrerer hvordan en kan lagre multimedia innholdstype; image, text, mesh, og video, som ressurser, ved bruk av blokk headere og data blokker. Ressursene kan lagres i enhver rekkefølge av innholdsutviklingsprosessen, som gir innholdsforfatteren muligheten til å spesifisere i hvilken rekkefølge ressursene skal bli lastet, når strømmet over et overføringsmedium. Dette er svært viktig på trege overføringsmedium. Se eksempel i FIG. 14. Figuren illustrerer to GX filer som er linket sammen med bruk av external_link. De to eksempl filene inneholder ressurser som er ordnet, og linket sammen, for effektiv streaming overføring.FIG. 1 er et blokkdiagram som illustrerer et datasystem som er egnet for å praktisere denne oppfinnelsen, FIG. 2 er et flytdiagram som illustrerer et datasystem som er egnet for å praktisere denne oppfinnelsen, FIG. 3 er et blokkdiagram som illustrerer komponentene av GX formatet i henhold til en legemliggjørelse av oppfinnelsen, FIG. 4 er et blokkdiagram som illustrerer formatet av scene_block_header i henhold til en legemliggjørelse av oppfinnelsen, FIG. 5 er et blokkdiagram som illustrerer formatet av image_resource_block_header og text_resource_block_header i henhold til en legemliggjørelse av oppfinnelsen, FIG. 6 er et blokkdiagram som illustrerer formatet av mesh_resource_block_header og video_resource_block_header i henhold til en legemliggjørelse av oppfinnelsen, FIG. 7 er et blokkdiagram som illustrerer formatet av scene_data_block j henhold til en legemliggjørelse av oppfinnelsen, FIG. 8 er et blokkdiagram som illustrerer formatet av image_data i henhold til en legemliggjørelse av oppfinnelsen, FIG. 9 er et blokkdiagram som illustrerer formatet av text_data i henhold til en legemliggjørelse av oppfinnelsen, FIG. 10 er et blokkdiagram som illustrerer formatet av mesh_data i henhold til en legemliggjørelse av oppfinnelsen, FIG. 11 er et blokkdiagram som illustrerer formatet av video_data i henhold til en legemliggjørelse av oppfinnelsen, FIG. 12 er et blokkdiagram som illustrerer formatet av image_resource_data_block og text_resource_data_block i henhold til en legemliggjørelse av oppfinnelsen, FIG. 13 er et blokkdiagram som illustrerer formatet av mesh_resource_data__block 0g video_resource_data_block i henhold til en legemliggjørelse av oppfinnelsen,Appendiks A er kodelistingen av XSD spesifikasjonen for GXML formatet, med en eksempel GXML formatert fil, ogAppendiks B viser klassene som brukes av program instruksjonskoden for å kontrollerer avspillningen.FIG. 1 viser et blokkdiagram på et illustrativt system for praktisering av en legemliggjørelse av oppfinnelsen. Oppfinnelsen kan praktiseres på maskiner med svært begrensede maskinvare ressurser (mikroprosessor, minne, lager, skjermkort, osv.), til maskiner med kraftige maskinvare ressurser.Maskiner med svært begrensede maskinvare ressurser kan være set-top bokser for interaktiv TV og håndholdte enheter som mobiltelefoner, PDA'er og andre enheter med mikroprosessor og minne, og også PC er med mikroprosessor, minne, lager, skjermkort, og inn/ut enheter. FIG. 2 er et flytdiagram som illustrerer stegene som utføres i den illustrerte legemliggjørelsen i FIG. 1. Fil-innholdet, heretter kalt GX innholdet (104), er laget av en forfatter (steg 200 i FIG. 2) og lagret på et lagringsmedium (102) på en kildemaskin (100). På et tidspunkt senere, blir GX innholdet (104) overført via et overføringsmedium(105), som f.eks. en nettverksforbindelse, til en destinasjonsmaskin (101) (steg 201 i FIG. 2). Destinasjonsmaskinen (101) inkluderer flere avspillere (103) for å vise multimedia innholdet som befinner seg i GX innholdet (104). For eksempel, kan GX innholdet (104) inkludere programkode, bilde-type data og tekst-type data. Avspillerne (103) på destinasjonen (101) inkluderer en program kode tolker, en bilde visualiseringsimplementasjon og en tekst visualiseringsimplementasjon. Tolkeren og visualiseringsimplementasjonene kan begynne å vise data såsnart de mottar data, før hele GX innholdet(104) er fullstendig overført (se steg 202 i FIG. 2). Tolkerne og visualiseringsimplementasjonene trenger ikke nødvendigvis å vise dataene umiddelbart, men kan brukes til å vise dataene på et senere tidspunkt.FIG. 3 viser den grunnleggende logisk organiseringen av GX innhold (104). Det er opp til forfatteren å fylle inn innholdet i GX innholdet i henhold til dette formatet. GX innholdet (104) er delt inn i en main header seksjon (300), en blokk header seksjon (301) og data blokk seksjon (302). Generellt sett, blir header seksjonene (300 og 301) først overført fra kilde maskinen (100) til destinasjonsmaskinen (101) slik at destinasjonsmaskinen kan prosessere informasjonen i header seksjonen. Deretter, blir data blokk seksjonen (302) overført fra kildemaskinen (100) til destinasjonsmaskinen (101) på en blokk-for-blokk måte.Main header seksjonen (300) som illustrert i FIG. 3 inneholder informasjon om GX innholdet (104). Signaturen (310) spesifiserer hovedtypen av GX innhold, og er typisk et stort tall som er unikt for utviklingsmiljøet. Feltet byte_count (311) spesifiserer det totale antall byter som er lagret i GX innholdet(104). Feltet block_count (312) spesifiserer det totale antallet med blokker (eksterne og interne) som er lagret i, eller brukt av, GX innholdet (104). Feltene major_version (313), minor_version (314), major_revision (315), og minor_revision (316) spesifiserer versjonen til GX innholdsformatet. Feltet extra_data (317) gir ekstra informasjon om GX innholdet (104), avhengig av den spesifikke implementasjonen av GX formatet. Feltet extra_data (317) er valgfritt, og kan bestå av et variabelt antall byter, avhengig av den spesifikke implementasjonen.Eksempler på mulige data typer er indikert i figurene. Vi benytter her forkortelser for data typer som spesifisert i programmeirngsspråket C++. "ulong" er kort for "unsigned long", "ushort" er kort for "unsigned short", "bool" er kort for "boolean", "string" begynner med en unsigned long verdi som angir byte lengden på strengen etterfulgt av byter for den UTF-8 formatterte tegnsekvensen, "ulonglong" er en 64-bit unsigned long. Oppfinnelsen er ikke begrenset til programmeirngsspråket C++. Andre programmeirngsspråk kan også benyttes.Blokk header seksjonene (301) som illustrert i FIG. 3 inneholder et antall blokk headere som gir informasjon om GX innholdet (104). Antallet blokk headere er spesifisert av feltet block_count (312) i main header seksjonen (300). Informasjonen som er lagret i blokk header kan variere, avhengig av typen innhold den beskriver. En blokk header vil alltid begynne med feltene som angitt i FIG. 3. Feltet type(320) indikerer typen på innholdet som headeren beskriver; dette kan for eksempel indikere en scene, en billedressurs, eller en tekstressurs. Feltet byte_count (321) spesifiserer det totale antall byter i blokk headeren. Feltet block_byte_count (322) spesifiserer det totale antall byter i den assosierte data blokken. Feltet name (323) spesifiserer navnet på innholdsenheten. Feltet extemal Jink (324) spesifiserer en link til eksternt GX innhold, som inneholder den assosierte data blokken. Feltet externaljink er tom hvis den assosierte data blokken er lagret i GX innholdet. Feltet extra_data_l (325) gir ekstra informasjon om blokk headeren og/eller innholdsenheten, avhengig av den spesifikke implementasjonen av GX formatet. Feltet extra_data_l (325) er valgfritt, og kan inneholde et variabelt antall byter, avhengig av den spesifikke implementasjonen. Feltet specific data (326) kan inneholde tilleggsinformasjon om innholdsenheten.Data blokk seksjonen (302) som illustrert i FIG. 3 inneholder data blokker som igjen inneholder dataene til innholdsenhetene i GX innholdet. Antallet datablokker i GX innholdet er lik antallet blokk headere iGX innholdet med en tom external_link. Der eksisterer nøyaktig en data blokk for hver blokk header med tom externaljink i GX innholdet. Data blokkene er gitt i samme rekkefølge, og er av samme innholdstype, som blokk headerene. Feltet type (330) indikerer typen av innhold som data blokken inneholder; dette kan for eksempel indikere en scene, en billedressurs, eller en tekstressurs. Feltet byte_count (331) spesifiserer det totale antall byter i data blokken. Feltet name (332) spesifiserer navnet på innholdsenheten. Feltet extra_data_l (333) gir ekstra informasjon om data blokken og/eller innholdsenheten, avhengig av den spesifikke implementasjonen av GX formatet. Feltet extra_data_l(333) er valgfritt, og kan inneholde et variabelt antall byter, avhengig av den spesifikke implementasjonen. Feltet specific data (334) kan inneholde tilleggsinformasjon om innholdsenheten.Innholdstypen scene kan bli brukt i GX innhold for å representere den visuelle layouten av flere innholdsenheter av forskjellige typer. Det kan være flere scener i en FK fil. Scenen kan også være skalert (skalerbart innhold) av avspillerne (103) for ulike representasjoner avhengig av karakteirstikkene på destinasjonsmaskinen (101), Feltet scene_block_header (400) som illustratert i FIG. 4 inneholder blokk header dataene for den assosierte scene data blokken Feltet scene_data_block (700) som illustrert i FIG. 7 inneholder scene dataene. Feltet type (320 og 330) indikerer at typen av innholdsenheten er av innholdstypen scene. Feltet bitrate_ids (411 og 711) spesifiserer bitrate identifiseringene brukt for innholdsskalering. Feltet bitrate_id_count (410 og 710) spesifiserer antallet bitrate identifiseringer. Feltet language_ids (413 og 713) spesifiserer språk identifiseringene brukt for innholdsskalering. Feltet language_id_count (412 og 712) spesifiserer antallet språk identifiseringer. Feltet screen_ids (415 og 715) spesifiserer skjerm identifiseringer brukt for innholdsskalering. Feltet screen_id_count (414 og 714) spesifiserer antallet skjerm identifiseringer. Feltet machine_ids (417 og 717) spesifiserer macskin identifiseringer brukt for innholdsskalering. Feltet machine_id_count (416 og 716) spesifiserer antallet maskin identifiseringer. Feltene bitrate_ids, language_ids, screen_ids, og machine_ids, kan i en legemliggjørelse være av unsigned long data type. Feltet extra_data_2 (418 og 718) gir ekstra informasjon om scene blokken og/eller innholdsenheten, avhengig av den spesifikke implementasjonen av GX formaten. Feltet extra_data_2 (418 og 718) er valgfritt, og kan bestå av et variabelt antall med byter, avhengig av den spesifikke implementasjonen. Feltet auto_size (719) spesifiserer layouten av scenen innen scene containeren. Feltene width (720) og height (721) spesifiserer størrelsen av scenen. Feltet mouse_pointer (722) spesifiserer hvordan muspekeren skal se ut på scenen. Feltet back_color (723) spesifiserer bakgunnsfargen til scenen. Feltet back_style (724) spesifiserer bakgrunnsstilen til scenen. Feltet antialias (725) spesifiserer antialiasing for scenen. Feltet quality (726) spesifiserer kvaliteten av scene visualiseringen. Feltet frames_per_ksec (727) spesifiserer frame-rate av scene visualiseringen. Feltet program_code (729) spesifiserer programkoden til scenen. Feltet program_code kan begynne med en unsigned long verdi for å indikere byte antallet til programkoden, og kan være etterfulgt av bytene til programmet. Feltet element_count (731) spesifiserer byte antallet til elementets data. Feltet element_data(732) inneholder element definitisjoner for scenen. Feltene extra_data_3 (728), extra_data_4 (730), og extra_data_5 (733) gir ekstra informasjon om scenen, avhengig av den spesifikke implementasjonen av GX formatet. Feltene extra_data_3 (728), extra_data_4 (730), og extra_data_5 (733) er valgfrie, og kan bestå av et variabelt antall med byter, avhengig av den spesifikke implementasjonen. Feltet program_code(729) kan være I et hvilket som helst programmeringsspråk eller instruksjonssett, kompilert eller kildekode, avhengig av den spesifikke implementasjonen.Programkoden bruker klasser; Scene, Image, Text, Mesh, Video, osv., som spesifisert i Java-språk i Appendiks B. Klassene kan implementere ekstra funksjonalitet, og det kan være flere klasser, avhengig av den spesifikke implementasjonen.Feltet image_data (800) som illustrert i FIG. 8 inneholder element definisjons data for scenen, av image element type. Feltet text_data (900) som illustrert i FIG. 9 inneholder element definisjons data for scenen, av text element type. Feltet mesh_data (1000) som illustrert i FIG. 10 contain eholder element definisjons data for scenen, av mesh element type. Feltet video_data (1100) som illustrert i FIG. 11 eholder element definisjons data for scenen, av video element type. Feltene image_data (800), text_data (900), mesh_data(1000), og video_data (1100) kan være lagret i element_data (732) av scenen. Feltene left (805,905, 1005,1105), top (806, 906,1006. 1106), width (807, 907,1007,1107), og height (808, 908, 1008, 1108) spesifiserer posisjon og størrelse til elementet. Feltet rotasjon (809, 909, 1009, 1109) spesifiserer rotasjonen til elementet. Feltet enabled (810,910, 1010,1110) spesifiserer om elementet er aktivt eller ikke-aktivt. Feltet visible (811,911,1011,1111) spesifiserer om elementet er synlig. Feltet transparency(812, 912, 1012,1112) spesifiserer gjennomsikteligheten til elementet. Feltet mouse_pointer (813, 913, 1013,1113) spesifiserer hvordan musepekeren skal se ut på elementet. Feltet back_color (814,914, 1014, 1114) spesifiserer bakgrunnsfargen til elementet. Feltet back_style (815, 915,1015,1115) spesifiserer bakgrunnsstilen til elementet. Feltene extra_data_l (804,904,1004,1104), og extra_data_2 (816, 916, 1016,1116) gir ekstra informasjon om scenen, avhengig av den spesifikke implementasjonen av GX formatet. Feltene extra_data_l (804, 904,1004, 1104), og extra_data_2 (816,916, 1016, 1116) er valgfrie, og kan bestå av et variabelt antall med byter, avhengig av den spesifikke implementasjonen.Ressursene image, text, mesh og/eller video kan bli brukt i GX innholdet for å lagre image, text, 3D mesh og/eller video data, respektivt. Feltet image_resource_block_header (500) som illustrert i FIG. 5 inneholder blokk header data for den assossierte image ressurs data blokken. Feltet image_resource_data_block (1200) som illustrert i FIG. 12 inneholder ressursdataene for et image. Feltet text_resource_block_header (550) som illustrert i FIG. 5 inneholder blokk header data for den assossierte text ressurs data blokken. Feltet text_resource_data_block (1250) som illustrert i FIG. 12 inneholder ressursdataene for text. Feltet mesh_resource_block_header (600) som illustrert i FIG. inneholder blokk header data for den assossierte mesh ressurs data blokken. Feltet mesh_resource_data_block (1300) som illustrert i FIG. 13 inneholder ressursdataene for et mesh. Feltet video_resource_block_header (650) som illustrert i in FIG. 6 inneholder blokk header data for den assossierte video ressurs data blokken. Feltet video_resource_data_block (1350) som illustrert i FIG. 13 inneholder ressursdataene for video. Feltet imagetype (510 og 1210) spesifiserer typen av image data. Feltene width (511 og 1211) og height (512 og 1212) spesifiserer støørelsen av image. Feltet bit_count (513 og 1213) spesifiserer antallet bits per pixel til image. Feltet resource_data (1215,1261,1311,1361) spesifiserer dataene til ressursen. Feltet resource_data kan begynne med en unsigned long verdi som indikerer byte antallet av ressursdataene, ok kan være etterfulgt av byter for ressursdataene. Feltene extra_data_2 (514, 560, 610, 660, 1214, 1260, 1310, 1360), og extra_data_3 (1216,1262,1312, 1362) gir ekstra informasjon om scenen, avhengig av den spesifikke implementasjonen av GX formatet. Feltene extra_data_2 (514, 560, 610, 660,1214, 1260, 1310,1360), og extra_data_3 (1216,1262, 1312, 1362) er valgfrie, og kan bestå av et variabelt antall med byter, avhengig av den spesifikke implementasjonen.World Wide Web Consortium (W3C) har definert Extensible Markup Language (XML), et universal format for strukturerte dokumenter og data på Web. Det er lett å se at GX formatet lett kan representeres i XML. Appendiks A viser et XML Schema (XSD), for å representere GX formatet, i henhold til W3C XSD spesifikasjonene. Programkode listing A.2 er et eksempel XML dokument, som inneholder GX formattert innhold i XML format, basert på XML Schemaet. XSD spesifikasjonen i programkode listing A.l spesifiserer den foretrukkene XML representasjonen av GX formattert innhold (GXML). GXML dokumentet kan være i tekst eller binær kodet form. Typisk vil GXML bli bruk med mer funksjonalitet (elementer, attributer, osv.) enn hva som er spesifisert i XML Schemaet i programkode listing A.l. Enhver elementtype i GXML kan inkludere flere elementer og attributter enn det som er spesifisert av XML Schemaet (f.eks. inkludere elementer fra andre XML Schema typer). For visse applikasjoner kan det være å foretrekke å gjøre visse strukturelle endringer og/eller bruke andre navn på noen av elementene og attributene for å tilfredstille terminologien i den spesifikke applikasjons context.Tag-paret "<gxml>" og "</gxml>" vil typisk markere starten og slutten på GXML. Taggen kan inkludere ekstra attributeer (f.eks. "version" for å markere versjon). For visse applikasjoner kan det være ønskelig å ikke inkludere denne taggen (f.eks. når GXML formatet er enkapsulert i andre types XML dokumenter eller schemas) eller bruke et annet navn som er mer passende for den spesifikke applikasjonen.Tag-paret "<head>" og "</head>" vil typisk markere starten og slutten på header seksjonen til GXML dokumentet. Header seksjonen vil typisk inneholde informasjon om innholdet. For visse applikasjoner kan det være ønskelig å ikke inkludere denne taggen eller bruke et annet navn som er mer passende for den spesifikke applikasjonen (f.eks. "Descriptor", "DescriptorMetadata", "Description", "DescriptionMetadata", "MovieDescriptor").Programkode listing A.3 er et eksempel på GXML formattert innholds header hvor vi bruker ordet "Descriptor" istedet for "Header". Vi har også definert atributt grupper, som "SystemBitRate", "SystemLanguages", "SystemScreen", "SystemMachine", "Format" og "ExternalURL". "ExternalURL" vil typisk bruke andre navn i andre applikasjoner (f.eks. "ExternalLink", "Locator", "ExternalLocator",
"ResourceLocator", "SceneLocator", "ImageLocator", "MediaLocator"). Det kan være ønskelig å gruppere descriptorene i en "descriptors" tag. For visse applikasjoner, viser programkode listingen en illustrasjon på en foretrukken XML representasjon for GXML header seksjonen.Programkode listing A.4 er en eksempel GXML formattert innholdsheader hvor vi strukturerer descriptorene under en "descriptors" tag, og de eksterne linkene under "references" taggen. For visse applikasjoner, viser programkode listingen en illustrasjon på en foretrukken XML representasjon for GXML header seksjonen.Tag-paret "<movie>" og "</movie>" vil typisk markere starten og slutten på data seksjonen til GXML dokumentet. For visse applikasjoner kan det være ønskelig å ikke inkludere denne taggen eller bruke et annet navn som er mer passende for den spesifikke applikasjonen.Programkode listing A.5 er et eksempel på en GXML formattert data seksjon hvor vi har definert atributtgnipper, som "Layout", "Behavior", og "Appearance". For visse applikasjoner, viser programkode listingen en illustrasjon på en foretrukken XML representasjon for GXML data seksjonen.Programkode listing A.6 er et eksempel på bruk av GXML i en spesifikk applikasjon. I dette eksemplet har GXML formatet blitt brukt som en del av det spesifikke formatet til applikasjonen. Slik bruk av formater inni formater er vanlig i XML dokumenter.Det å inkludere binærdata i XML dokumenter har vært et industriproblem for en stund. I GXML bruker vi "xs:hexBinary" typen på "HexBinaryData" elementer. Tilsvarende, er det også mulig å ha en "xs:base64Binary" type på "Base64BinaryData" elementer, alternativt til "HexBinaryData". GXML kan også inkludere binærdata på slutten av XML dokumentet.FIG. 14 er et eksempel på hvordan innhold kan være effektivt linket sammen for effektiv transmisjon av multimedia innhold over et tregt overføringsmedium. Typisk er hovedproblemene med trege overføringsmedium; høy aksesstid og lav transmisjonsrate. Aksesstiden er tiden fra destinasjonsmaskinen ber om innholdet til destinasjonsmaskinen mottar det. Transmisjonsraten er raten som data kan leveres i over overføringsmediet. GX formatet kan embedde mange små innholdsenheter som ressurser, som reduserer den totale innholds overføringstiden på transmisjonsmedium med høy aksesstid. Som en kan se i FIG. 14, inneholder GX filene (1400 og 1401) flere data bloker, som inneholder data enheter, i hver GX fil. Pilene i FIG. 14 illustrerer innholds linking, ved bruk av feltet externaljink (324) i blokk headerene.Feltet externaljink indikerer hvor data blokken er lokalisert, enten i den samme filen, eller en ekstern fil. Feltet externaljink kan være en URL. Ved å linke multimedia innhold på denne måten, kan en få effektiv gjenbruk av multimedia innhold mellom ulike GX filer, mens an samtidig opprettholder et minimum antall GX innholdsfiler. Gjenbruk av multimedia innhold er viktig, ettersom det kan brukes for å unngå å måtte overføre det same innholdet flere ganger. Du ønsker å unngå å overføre innholds enheter flere ganger på trege overføringsmedium.Selv om oppfinnelsen har blitt beskrevet med referanse i en legemliggjørelse, vil de som er erfarne i kunsten innse at ulike variasjoner i form og detalj kan gjøres uten å avvike fra intensjonen i skopet til oppfinnelsen som definert i de vedlagte krav. De spesifikke detaljene ovenfor er ment bare for å være illustrative og skopet av oppfinnelsen er definert av de vedlagte krav. For eksempel kan oppfinnelsen praktiseres med et multimedia innholdsformat som avviker fra formatet som er beskrevet ovenfor. Alternative multimedia innholdsformater kan inkludere bare et subset av de ovenfor nevnte feltene eller inkludere ekstra felter som avviker fra de som er nevnt ovenfor. Det må også neves at lengden på verdiene og organiseringen av strukturene ovenfor er ikke ment for å begrense skopet til oppfinnelsen.Programkode listing A. 1:
Claims
1. I et data system, en metode for å enkapsulere multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskode i en aggregert data representasjon bestående av en logisk struktur, hvor metoden innebefatter:
- lagre på en lagringsenhet, informasjon om multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskoden for å lage en main header seksjon (300) i den logiske strukturen;
- lagre på en lagringsenhet, flere blokk headere for alle multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskoden for å lage en block headers seksjon (301) i den logiske strukturen; og
- lagre på en lagringsenhet, flere data blokker for alle multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskoden for å lage en data blokk seksjon (302) i den logiske strukturen; hvormetoden er karakterisert ved;
- at feltet "name" (323) i blokk header seksjone (301) gir logiske navn til data blokker;
- den aggregerte data representasjonen eller den logiske strukturen samtidig, eller på et senere tidspunkt, vil, eller kan bli, overført over et overføringsmedium (105) til en eller flere destinasjonsmaskiner (101); og
- å oppi linking mellom flere filer i multimedia innhold med bruk av et externaljink felt (324) i blokk header seksjonen (301).2. Metode ifølge krav 1, karakterisert ved at
- blokk header seksjonene (301) omfatter en scene blokk header (400);
- blokk header seksjonene (301) omfatter en image ressurs blokk header (500), en text ressurs blokk header (550), en mesh ressurs blokk header (600), eller en video ressurs blokk header (650);
- data blokk seksjonene (302) omfatter en scene data blokk (700);
- data blokk seksjonene (302) omfatter en image ressurs data blokk (1200), en text ressurs data blokk (1250), en mesh ressurs data blokk (1300), eller en video ressurs data blokk (1350);
- antallet data blokker i data blokk seksjonen (302) er lik antallet blokk headere i blokk header seksjonen (301) med et tomt externaljink felt (324); og
- program instruksjonskoden kontrollerer avspillningen av multimedia innholdet.3. Metode ifølge krav 1, karakterisert ved at
- avgjøre lagringsrekkefølgen for ressursene, for de ulike multimedia typene, f.eks. audio, video, image og text, for å oppnå effektiv strømningsoverføring;
- komprimering av data i noen av data blokk seksjonene med bruk av passende komprimerings metoder, f.eks. ZLIB, PNG eller JPEG; og
- lage ulike skalerte innholds representasjoner av en eller flere scener, avhengig av ulike maskinvare profiler av destinasjonsmaskiner (101), f.eks. bitrate, skjerm, språk, og/eller maskin.4. Metode ifølge krav 1, karakterisert ved at den logiske strukturen er en XML formattert struktur.5. I et datasystem, en metode for å motta multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskode fra en aggregert data representasjon lagret på en lagringsenhet, hvor data representasjonen omfatter en logisk struktur som enkapsulerer multimedia innholdsdata, multimedia innholds beskrivelsesdata, og program instruksjonskode, hvor metoden omfatter å lese fra lagringsenheten:
- en main header seksjon (300) til den logiske strukturen, hvor main header seksjonen har informasjon om multimedia innholds dataene, multimedia innholds beskrivelsesdata, og program instruksjonskoden;
- flere header blokker fra header seksjonen (301) til den logiske strukturen, hvor de fler blokk headerene innbefatter informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskoden; og
- flere data blokker fra data seksjonen (302) til den logiske strukturen, hvor de flere data blokkene innbefatter multimedia innholds data, multimedia innholds bekrivelsesdata, og program instruksjonskode; hvormetoden er karakterisert ved;
- at feltet "name" (323) i blokk header seksjon (301) gir logiske navn til data blokker;
- den aggregerte data representasjonen eller den logiske strukturen samtidig, eller på et tidligere tidspunkt, har, eller kan ha blitt, overført over et overføringsmedium (105) til en eller flere destinasjonsmaskiner (101) ; og
- å lese informasjon om linking mellom flere filer i multimedia innhold med bruk av et externaljink felt (324) i blokk header seksjonen (301).6. Metode ifølge krav 5, karakterisert ved at
- blokk header seksjonene (301) innbefatter en scene blokk header (400);
- blokk header seksjonen (301) innbefatter en image ressurs blokk header (500), en text ressurs blokk header (550), en mesh ressurs blokk header (600), eller en video ressurs blokk header (650);
- data blokk seksjonen (302) innbefatter en scene data blokk (700);
- data blokk seksjonen (302) innbefatter en image ressurs data blokk (1200), en text ressurs data blokk (1250), en mesh ressurs data blokk (1300), eller en video ressurs data blokk (1350);
- antallet data blokker i data blokk seksjonen (302) er lik to antallet blokk headere i blokk header seksjonen (301) med et tomt externaljink felt (324); og
- program instruksjonskoden kontrollerer avspilling av multimedia innholdet.7. Metode ifølge krav 5, karakterisert ved at den logiske strukturen er en XML formattert struktur.8. Metode ifølge krav 5, karakterisert ved at den videre innbefatter mottak av den aggregerte data representasjonen eller den logiske strukturen over et overføringsmedium (105) på en destinasjonsmaskin (101), for umiddelbart, eller på et senere tidspunkt, å spille av innholdet ved hjelp av en avspiller (103).9. Maskin-lesbar aggregert data representasjon som enkapsulerer multimedia innholds data, multimedia innholds beskrivelsesdata, and program instruksjonskode, hvor den aggregerte data representasjonen omfatter en logisk struktur lagret på en maskin lesbar lagringsenhet, hvor den logiske strukturen omfatter:
- en main header seksjon (300) som omfatter informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode i en logisk struktur som definerer den aggregerte data representasjonen;
- en blokk header seksjon (301) som omfatter flere blokk headere for multimedia innholds dataene, multimedia innhold beskrivelsesdataene, og program instruksjonskoden; og
- en data blokk seksjon (302) som omfatter flere data blokker for alle multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode; hvorden logiske strukturen er karakterisert ved;
- at feltet "name" (323) i blokk header seksjon (301) gir logiske navn til data blokker;
- den aggregerte data representasjonen eller den logiske strukturen samtidig, eller på et senere tidspunkt, vil, eller kan bli, overført over et overføringsmedium (105) til en eller flere destinasjonsmaskiner (101); og
- linking informasjon mellom flere filer i multimedia innhold med bruk av et externaljink felt (324) i blokk header seksjonen (301).10. Maskin-lesbar aggregert data representasjon i krav 9, karakterisert ved at
- blokk header seksjonen (301) omfatter en scene blokk header (400);
- blokk headers seksjonen (301) omfatter en image ressurs blokk header (500), en text ressurs blokk header (550), en mesh ressurs blokk header (600), eller en video ressurs blokk header (650);
- data blokk seksjonen (302) omfatter en scene data blokk (700);
- data blokk seksjonen (302) omfatter en image ressurs data blokk (1200), en text ressurs data blokk (1250), en mesh ressurs data blokk (1300), eller en video ressurs data blokk (1350);
- antallet data blokker i data blokk seksjonen (302) er lik antallet blokk headere i blokk header seksjonen (301) med et tomt externaljink felt (324); og
- program instruksjonskoden inneholder avspillning av multimedia innholdet.11. Maskin-lesbar aggregert data representasjon i krav 9, karakterisert ved atden logiske strukturen er en XML formattert struktur.12. Et maskin-lesbar lagringsmedium som oppbevarer instruksjoner for enkapsulering av multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode i en aggregert data representasjon som omfatter en logisk struktur, hvor instruksjonene omfatter:
- lagre på en lagringsenhet, informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode for å lage en main header seksjon (300) i den logiske strukturen-,
- lagre på en lagringsenhet, flere blokk headere for alle multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode for å lage en blokk header seksjon (301) i den logiske strukturen-, og
- lagre på en lagringsenhet, flere data blokker for alle multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode for å lage en data blokk seksjon (302) i den logiske strukturen; hvorinstruksjonene er karakterisert ved;
- at feltet "name" (323) i blokk header seksjon (301) gir logiske navn til data blokker;
- den aggregerte data representasjonen eller den logiske strukturen samtidig, eller på et senere tidspunkt, vil, eller kan bli, overført over et overføringsmedium (105) til en eller flere destinasjonsmaskiner (101); og
- å oppi linking mellom flere filer i multimedia innhold med bruk av et externaMink felt (324) i blokk header seksjonen (301).13. Et maskin-lesbar lagringsmedium som oppbevarer instruksjoner for å hente multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode fra en aggregert data representasjon lagret på en lagringsenhet, hvor data representasjonen omfatter en logiske struktur som enkapsulerer multimedia innholds dataene, multimedia innholds beskrivelsesdataene, og program instruksjonskoden, hvor instruksjonene omfatter å lese fra lagringsenheten:
- en main header seksjon (300) av den logiske strukturen, hvor main header seksjonen har informasjon om multimedia innholds dataene, multimedia innholds beskrivelsesdataene, og program instruksjonskoden;
- flere header blokker fra header seksjonen (301) til den logiske strukturen, hvor de flere blokk headerene omfatter informasjon om multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode; og
- flere data blokker fra data seksjonen (302) i den logiske strukturen, hvor de flere data blokkene omfatter multimedia innholds data, multimedia innholds beskrivelsesdata, og program instruksjonskode; hvor instruksjonene er karakterisert ved;
- at feltet "name" (323) i blokk header seksjon (301) gir logiske navn til data blokker;
- den aggregerte data representasjonen eller den logiske strukturen samtidig, eller på et tidligere tidspunkt, har, eller kan ha blitt, overført over et overføringsmedium (105) til en eller flere destinasjonsmaskiner (101) ; og
- å lese informasjon om linking mellom flere filer i multimedia innhold med bruk av et externaljink felt (324) i blokk header seksjonen (301).