EP1723562A1 - Storage of content-location information - Google Patents

Storage of content-location information

Info

Publication number
EP1723562A1
EP1723562A1 EP05717324A EP05717324A EP1723562A1 EP 1723562 A1 EP1723562 A1 EP 1723562A1 EP 05717324 A EP05717324 A EP 05717324A EP 05717324 A EP05717324 A EP 05717324A EP 1723562 A1 EP1723562 A1 EP 1723562A1
Authority
EP
European Patent Office
Prior art keywords
file format
content
file
media content
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05717324A
Other languages
German (de)
French (fr)
Inventor
Emre Baris Aksu
Sami Pippuri
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Oyj filed Critical Nokia Oyj
Publication of EP1723562A1 publication Critical patent/EP1723562A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers

Definitions

  • the invention generally relates to file formats. Especially, certain embodiments of the invention relate to providing a DCF file format (e.g., DCF v2.0 file format) or similar.
  • a DCF file format e.g., DCF v2.0 file format
  • OMA DRM Release 2 is standardizing the DCF (DRM Content Format) v2.0 File Format to be used as part of the OMA DRM-enabled services (OMA stands for Open Mobile Alliance; DRM stands for Digital Rights Management).
  • OMA Open Mobile Alliance
  • DRM Digital Rights Management
  • the purpose is to define the content format for DRM protected encrypted media objects and associated metadata.
  • This content format (or file format) can be used as content- wrapper for many other types of content as well. For example, all components of a SMIL presentation can be "packaged" into a single file with well-defined place-holders and content-definitive meta-data structures.
  • This file format is expected to be commonly used by the industry for multimedia content distribution and storage with or without DRM protection.
  • 3GPP Packet Switched Streaming (PSS, Packet- switched Streaming Service) Release 6 is currently working on adoption of new technologies to enlarge the scope of the 3GPP File Format to enable it to be a "wrapper" file format (i.e., a container file format). It is currently under 3GPP SA4's discussion whether to use the DCF v2.0 file format, or to use the file format extensions, which will be inherited from the new MPEG ISO Base Media File Format Amendment- 1 Specification (ISO/IEC 14496-12:2003 I 15444-12:2003: "ISO base media file format” Amendment-1).
  • the DCF v2.0 file format can be used as a single container to contain all the com- ponents of a multimedia presentation (which can be represented by a SMIL file), or simply archive a collection of multimedia content, be it static or dynamic content.
  • a multimedia presentation which can be represented by a SMIL file
  • the user may not have DRM rights to modify the SMIL file
  • the directory structure may be lost on the target side, which may like to store the media components in different directories (e.g. images in ⁇ images directory, 3GP files in ⁇ 3GP directory, etc., depending on the Media storage structure defined by the user or the OS-present media gallery application).
  • directories e.g. images in ⁇ images directory, 3GP files in ⁇ 3GP directory, etc., depending on the Media storage structure defined by the user or the OS-present media gallery application).
  • ZIP has a directory structure storage capability. ZIP can be considered as a "archive” file format, but with ZIP it is not possible to identify the "maestro” file of the presentation (e.g. a SMIL file which actually defines the whole presentation's layout and structure).
  • Ericsson has proposed an extension to the ISO Base Media File Format to include the "file-tree" structure and the static media content in the file format, as additional meta-data in MPEG meeting on December 2003.
  • 3GP file format extensions - container format 3GPP TSG-SA WG4 Meeting #30, Malaga, Spain, 23-27 February 2004
  • Ericsson Per Fr ⁇ jdh, Presentation and file-tree extensions to the ISO base media file format, ISO EC JTC1/SC29/WG11, MPEG2003/M 10406, December 2003, Waikoloa, USA.
  • the contents of both documents are incorporated herein by reference.
  • the presented proposal seems partially to solve the problem, it does not solve the problem relating to DCF v2.0 files, which simply do not make use of this new file format.
  • a method for com- munication comprising: providing a file format for a media content; and indicating content-location information of the media content with the aid of the file format.
  • the method is applicable for wireless as well as wired communication.
  • each media content inside the file can be extracted to its proper target location or consumed "in place” by establishing a virtual file tree inside a single file.
  • the same directory structure before "packaging” is preserved.
  • the presentation lay-out files e.g. SMIL
  • the presentation lay-out files does not need to be modified to "flatten" the directory structures or "rename” the duplicate file names.
  • a read-only copy- righted SMIL presentation e.g. authored by a recognized artist
  • user-generated content e.g. own pictures, videos
  • a sender device configured to be used with the method of the first aspect of the invention.
  • the sender device may be a network element. It may be, e.g., a server in a net- work, such as the internet or a mobile network. It may be a streaming server or any suitable server used for (multi)media download or file download or file or content delivery. Alternatively, it may be a mobile or fixed terminal device.
  • the receiver device may be, e.g., a mobile client or a fixed client device.
  • the software applications may be computer program products, comprising program code, stored on a medium, such as a memory.
  • the OMA DRM defines a delivery method in which a media object is encrypted and the rights containing an encryption key are delivered to a device apart from the media object.
  • the goal of the specification is to define a content format that, in addition to encrypting the media object, supports metadata such as: original content type of the media object; unique identifier for this DRM protected media object to associate it with rights; - information about the encryption details; information about the rights issuing service for this DRM protected media object; and extensions and other media type dependent metadata.
  • the standard specification suggests two profiles for the content format.
  • One that is DCF
  • discrete media such as still images, ring tones, applications, etc.
  • This profile is used to package and protect discrete media.
  • the discrete media profile allows one to wrap any content in an envelope (DCF). That content is then encrypted as a single object agnostic of the contents internal structure and layout.
  • the other suggested profile that is PDCF, is intended to be used with continuous media (e.g., audio, such as music, and video). It is used to protect continuous (packetized) media.
  • continuous media is protected in a separate format because it is packetized. Applications that read and parse continuous media are meant to work on the file on a packet-by-packet basis.
  • the storage format needs to be structured in such a way that the packets are individually protected. This structurally aware packetization is also required in order to stream continuous media.
  • An OMA DRM compliant streaming server is be able to understand the content format's structure in order to break the content into headers and packets that can be delivered to a client that understands the protected format.
  • both profiles share data structures for the purpose of reusing components. Furthermore, both profiles are based on a widely accepted and deployed standard format, the ISO Base Media File format [ISO14496-12], but the discrete media profile is meant to be an all-purpose format, not aiming for full compatibility with ISO media files.
  • the content issuer can decide which profile to use for their content, but in general, the profile for continuous media should be used for con- tinuous media content, in order to create a harmonious user experience.
  • the discrete media profile should be used for other types of content. To a user, the difference is that a DCF looks like a DRM protected file, whereas a PDCF looks and functions like a media file to the outside.
  • Section 5.1 of the above-mentioned standard describes the ISO base media file format and its general relation to the suggested content format.
  • the ISO base media file format is structured around an object-oriented design of boxes.
  • the suggested DCF v2 file format also has a boxed structure based on the ISO base format. It can be used to "wrap" any media types. It comprises headers section per content object. Content objects may or may not be encrypted.
  • a first content object determines media type visible outside (e.g., SMIL).
  • An other content object may be referenced via a CID mechanism. After mandatory boxes, proprietary extensions are allowed. It also supports embedded file icons, preview etc.
  • Figure 1 shows a schematic high-level overview of the structure of the discrete media profile (DCF).
  • the numbers indicating length in Figure 1 represent octets.
  • a DCF file includes at least one OMA DRM Container box 10.
  • the OMA DRM Container box 10 is a container for a single content object and its associated head- ers.
  • the format includes the file header (Fixed DCF header), immediately followed by the OMA DRM Container box 10.
  • the OMA DRM Container box 10 includes a DCF headers box 11 and a Protected Content box 12.
  • the de- sign principles for the format include that the DCF headers box 11 is located at a fixed offset from the beginning of the file.
  • the OMA DRM Container box 10 is the first box after the file header; and the DCF headers box 11 is the first box in the OMA DRM Container 10.
  • the OMA DRM Container box 10 comprises an OMA DRM common headers box 13 and, optionally, a (ISO) user data box 14. In case of multipart, the first OMA DRM Container box 10 is followed by a second OMA DRM Container box 20.
  • the PDCF profile (or format) differs from the DCF format to some extent. However, a similar common headers box appears also in PDCF.
  • the standard specification (DCF v2.0) defines a method to extend the meta-data structure of the file format by using the common headers with TextualHeaders field.
  • the common headers box 14 can comprise textual headers -fields containing additional information of the content.
  • a new custom header is defined as follows:
  • Token URI (as defined in RFC 2396)
  • V (this means that content is in the same directory as the SMIL presentation);
  • the header name "Content-Location” is just an example name, and may be called differently by different standards (or technical specifications) still covering the same concept.
  • FIG. 2 shows another illustration of the DCF v2.0 File Format.
  • DCF is designed to be used to protect high-value discrete media objects. It includes the original MIME type of the contained media object. Common DRM headers are used to indicate, e.g., encryption algorithm, where rights may be purchased etc.
  • 3GPP asset information can be used as defined by the 3GP file format. The media object is encrypted and inserted into the wrapper format as such - complete with the original file format.
  • Figure 3 shows another embodiment for providing the DCF v2.0 file format with content-location information.
  • the DCF format can be used to host multipart multimedia presentations.
  • the first content object determines the media type association, so having a SMIL document 31 as the first object associates the file with a SMIL player.
  • SMIL document may then reference to other objects 32-34 within the file.
  • the SMIL document comprises a set of content-location fields, which indicate a path and a filename.
  • each referenced file may contain a content-location field, which provides the path of the content.
  • file-level interleaving is disabled. Having file-level interleaving would in many cases add unnecessary complexity.
  • each media data is encapsulated inside a "file".
  • each file has a content-location header. It may reside, e.g., in the beginning of each file.
  • the content can be mapped easily with the aid of, e.g., the SMIL file and the content-location headers.
  • the directory structure is preserved after a content packaging operation and also restored after a possible extraction of the con- tent.
  • Content can be played "in place" from the file, e.g., reading the content block- by-block from the file, without extracting it to the file system, thus saving space.
  • This still enables a file tree type of representation of the file's contents.
  • a progressive download application can make use of this field to understand whether this is the correct content to be fetched.
  • each file entity contains its own content-location information, it is simple to add or remove content without affecting the other parts of the container file. Enables mixing high-value, copyrighted and protected works with user- generated, personal content
  • the parser/composer must or should be aware of the header, so that if a modification is done, it should be updated.
  • Extra level of packaging (DCF inside a DCF) can be done in order to mix copy- righted (protected) content with user- generated content.
  • FIG. 1 shows a transmission system for multimedia content streaming.
  • the system comprises an encoder EC, which may also be referred to as an editor, preparing media content data for transmission typically from a plurality of media sources MS, a streaming server SS transmitting the encoded multimedia files over a network NW and a plurality of clients C receiving the files.
  • the content may be from a recorder recording live presentation, e.g. a video camera, or it may be previously stored on a storage device, such as a video tape, CD, DVD, hard disk etc.
  • the content may be e.g.
  • the multimedia files from the encoder EC are transmitted to the server SS.
  • the server SS is able to serve a plurality of clients C and respond to client requests by transmitting multimedia files from a server database or immediately from the encoder EC using unicast or multicast paths.
  • the network NW may be e.g. a mobile communications network, a local area network, a broadcasting network or multiple different networks separated by gateways.
  • drawing sheet 4 shows a communications system according to an embodiment of the invention.
  • the system comprises a (streaming) server 111, which is coupled to an IP- network (Internet Protocol) 104.
  • IP-network 104 may be, for example, the Internet or a service provider operator's intranet (an intranet network belonging to the operator's domain).
  • the IP-network 104 is coupled to a core network 103 of a mobile communications network. The coupling may be performed via a G; interface.
  • the mobile communications network may be, for example, a '2.5 th generation' GPRS or EGPRS network, or a 3 rd or further generation cellular mobile communications network.
  • the mobile communications network also comprises a radio access network (RAN) 102 coupled to the core network 103.
  • the radio access network 102 provides mobile client devices 101 with access to the mobile communications network over an air-interface.
  • the mentioned access may be provided e.g. by circuit switched means (e.g. circuit switched data call) or packet switched means (e.g. GPRS (General Packet Radio Service)). Accordingly, these techniques may be used to carry media stream packets over the air-interface portion.
  • circuit switched means e.g. circuit switched data call
  • packet switched means e.g. GPRS (General Packet Radio Service)
  • FIG. 5 in drawing sheet 5 shows an illustration of the server 111.
  • the server 111 comprises a processing unit 151, a first memory 153, a network interface 155, and a second memory 152.
  • the first memory 153, the network interface 155, and the second memory 152 are coupled to the processing unit 151.
  • the processing unit 151 controls, in accordance with computer software 154 stored in the first memory 153, the operation of the server 111, such as handling file formats and sending of appropriate contents stored, e.g., in the second memory (disk) 152, to the client 101 via the network interface 155.
  • the software 154 comprises program code for implementing a suitable layered protocol stack.
  • Figure 6 in drawing sheet 5 shows an illustration of the client device 101.
  • the client 101 may be, e.g., a mobile station of a cellular radio tele- phone network.
  • the client may, alternatively, be a fixed terminal.
  • the client 101 comprises a processing unit 171, a radio frequency part 175, and the user interface 109.
  • the radio frequency part 175 and the user interface 109 are coupled to the processing unit 171.
  • the user interface 109 typically comprises a display, a speaker and a keyboard (not shown) with the aid of which a user can use the client device 101.
  • the processing unit 171 comprises a processor (not shown), a memory 173 and computer software 174 stored in the memory 173.
  • the processor controls, in ac- cordance with the software, the operation of the client device 101, such as handling of file formats, receiving streaming media or media files from the server 111 and presentation of the received streaming media on the user interface 109.
  • the software 174 comprises program code for implementing a suitable layered protocol stack.
  • Procedures relating to file format can be implemented by software.
  • a computer program product comprising program code stored in the receiver device 101 and run in the processor 171 can be used to implement the procedures at the receiving end of a transmission session, whereas a computer program product comprising program code stored in the sender device 111 and run in the processor 151 can be used to implement the procedures at the transmitting end.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)

Abstract

A method, devices, system and software applications for wired or wireless communication. A file format for a DRM (Digital Rights Management) media content is provided. The file format has textual content-location header(s) in a common headers box for indicating content-location information of the media content.

Description

STORAGE OF CONTENT-LOCATION INFORMATION
FIELD OF THE INVENTION
The invention generally relates to file formats. Especially, certain embodiments of the invention relate to providing a DCF file format (e.g., DCF v2.0 file format) or similar.
BACKGROUND OF THE INVENTION
OMA DRM Release 2 is standardizing the DCF (DRM Content Format) v2.0 File Format to be used as part of the OMA DRM-enabled services (OMA stands for Open Mobile Alliance; DRM stands for Digital Rights Management). Accord- ingly, a standard specification: Open Mobile Alliance, DRM Content Format, Draft Version 2.0 - 16 January-2004 has been drawn up, the contents of this document being incorporated herein by reference. The purpose is to define the content format for DRM protected encrypted media objects and associated metadata. This content format (or file format) can be used as content- wrapper for many other types of content as well. For example, all components of a SMIL presentation can be "packaged" into a single file with well-defined place-holders and content-definitive meta-data structures. This file format is expected to be commonly used by the industry for multimedia content distribution and storage with or without DRM protection.
3GPP Packet Switched Streaming (PSS, Packet- switched Streaming Service) Release 6 is currently working on adoption of new technologies to enlarge the scope of the 3GPP File Format to enable it to be a "wrapper" file format (i.e., a container file format). It is currently under 3GPP SA4's discussion whether to use the DCF v2.0 file format, or to use the file format extensions, which will be inherited from the new MPEG ISO Base Media File Format Amendment- 1 Specification (ISO/IEC 14496-12:2003 I 15444-12:2003: "ISO base media file format" Amendment-1).
The DCF v2.0 file format can be used as a single container to contain all the com- ponents of a multimedia presentation (which can be represented by a SMIL file), or simply archive a collection of multimedia content, be it static or dynamic content. For SMIL presentations, it is desirable to be able to store the directory structure (also called file-tree structure) information of the presentation's media components, in order not to modify the SMIL presentation after "packaging" it into the DCF v2.0 file.
Currently, there is no well-defined or standard way of storing such information in the DCF v2.0 file. Hence, if a user wants to package a SMIL presentation, the user has to modify the SMIL file to contain no paths (or every media component must be at the root directory level as the SMIL file). This has the following impacts:
1. The user may not have DRM rights to modify the SMIL file;
2. There can be file name clashes;
3. There is additional complexity and memory consumption in modifying the SMIL presentation; and/or
4. The directory structure may be lost on the target side, which may like to store the media components in different directories (e.g. images in \images directory, 3GP files in \3GP directory, etc., depending on the Media storage structure defined by the user or the OS-present media gallery application).
ZIP has a directory structure storage capability. ZIP can be considered as a "archive" file format, but with ZIP it is not possible to identify the "maestro" file of the presentation (e.g. a SMIL file which actually defines the whole presentation's layout and structure).
Ericsson has proposed an extension to the ISO Base Media File Format to include the "file-tree" structure and the static media content in the file format, as additional meta-data in MPEG meeting on December 2003. For further information, please see the documents: Ericsson, 3GP file format extensions - container format, 3GPP TSG-SA WG4 Meeting #30, Malaga, Spain, 23-27 February 2004; Ericsson, Per Frδjdh, Presentation and file-tree extensions to the ISO base media file format, ISO EC JTC1/SC29/WG11, MPEG2003/M 10406, December 2003, Waikoloa, USA). The contents of both documents are incorporated herein by reference. Although the presented proposal seems partially to solve the problem, it does not solve the problem relating to DCF v2.0 files, which simply do not make use of this new file format.
SUMMARY OF THE INVENTION
According to a first aspect of the invention, there is provided a method for com- munication, the method comprising: providing a file format for a media content; and indicating content-location information of the media content with the aid of the file format.
The method is applicable for wireless as well as wired communication.
In accordance with an embodiment of the invention, there is defined a new header in the DCF v2.0 File Format, inside which the content-location information of the media content is stored. With the definition of such a header, each media content inside the file can be extracted to its proper target location or consumed "in place" by establishing a virtual file tree inside a single file. Hence, the same directory structure before "packaging" is preserved. This also means that the presentation lay-out files (e.g. SMIL) does not need to be modified to "flatten" the directory structures or "rename" the duplicate file names.
By using embodiments of the invention, it is possible to have a read-only copy- righted SMIL presentation (e.g. authored by a recognized artist), which is later on used for composing a rich multimedia presentation together with user-generated content (e.g. own pictures, videos).
According to further aspects of the invention, there is provided a sender device, a receiver device, a system, software applications and a file format configured to be used with the method of the first aspect of the invention.
The sender device may be a network element. It may be, e.g., a server in a net- work, such as the internet or a mobile network. It may be a streaming server or any suitable server used for (multi)media download or file download or file or content delivery. Alternatively, it may be a mobile or fixed terminal device.
The receiver device may be, e.g., a mobile client or a fixed client device.
The software applications may be computer program products, comprising program code, stored on a medium, such as a memory.
Dependent claims relate to embodiments of the invention. The subject matter con- tained in dependent claims relating to a particular aspect of the invention is also applicable to other aspects of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which:
Drawing sheets 1-5 show/illustrate embodiments of the invention. DETAILED DESCRIPTION
The subject-matter contained in the introductory portion of this patent application may be used to support the detailed description. In the following, the DCF v2.0 is used as an example without an intention to limit the present invention to involve DCF v2.0 only. Any of the methods described in the following can also be used in any possible and functionally suitable combination.
According to the standard specification (Open Mobile Alliance, DRM Content Format, Draft Version 2.0 - 16 January-2004) mentioned in the section "background of the invention" the OMA DRM defines a delivery method in which a media object is encrypted and the rights containing an encryption key are delivered to a device apart from the media object. The goal of the specification is to define a content format that, in addition to encrypting the media object, supports metadata such as: original content type of the media object; unique identifier for this DRM protected media object to associate it with rights; - information about the encryption details; information about the rights issuing service for this DRM protected media object; and extensions and other media type dependent metadata.
The standard specification suggests two profiles for the content format. One, that is DCF, is intended to be used with discrete media (such as still images, ring tones, applications, etc.). This profile is used to package and protect discrete media. The discrete media profile allows one to wrap any content in an envelope (DCF). That content is then encrypted as a single object agnostic of the contents internal structure and layout. The other suggested profile, that is PDCF, is intended to be used with continuous media (e.g., audio, such as music, and video). It is used to protect continuous (packetized) media. The standard specification suggests that continuous media is protected in a separate format because it is packetized. Applications that read and parse continuous media are meant to work on the file on a packet-by-packet basis. To facilitate the playback of protected continuous media, the storage format needs to be structured in such a way that the packets are individually protected. This structurally aware packetization is also required in order to stream continuous media. An OMA DRM compliant streaming server is be able to understand the content format's structure in order to break the content into headers and packets that can be delivered to a client that understands the protected format.
According to the standard specification, both profiles share data structures for the purpose of reusing components. Furthermore, both profiles are based on a widely accepted and deployed standard format, the ISO Base Media File format [ISO14496-12], but the discrete media profile is meant to be an all-purpose format, not aiming for full compatibility with ISO media files. According to the standard specification, the content issuer can decide which profile to use for their content, but in general, the profile for continuous media should be used for con- tinuous media content, in order to create a harmonious user experience. The discrete media profile should be used for other types of content. To a user, the difference is that a DCF looks like a DRM protected file, whereas a PDCF looks and functions like a media file to the outside.
Section 5.1 of the above-mentioned standard describes the ISO base media file format and its general relation to the suggested content format.
The ISO base media file format is structured around an object-oriented design of boxes. The suggested DCF v2 file format also has a boxed structure based on the ISO base format. It can be used to "wrap" any media types. It comprises headers section per content object. Content objects may or may not be encrypted. A first content object determines media type visible outside (e.g., SMIL). An other content object may be referenced via a CID mechanism. After mandatory boxes, proprietary extensions are allowed. It also supports embedded file icons, preview etc.
Figure 1 shows a schematic high-level overview of the structure of the discrete media profile (DCF). The numbers indicating length in Figure 1 represent octets.
A DCF file includes at least one OMA DRM Container box 10. The OMA DRM Container box 10 is a container for a single content object and its associated head- ers.
More closely, the format includes the file header (Fixed DCF header), immediately followed by the OMA DRM Container box 10. The OMA DRM Container box 10 includes a DCF headers box 11 and a Protected Content box 12. The de- sign principles for the format include that the DCF headers box 11 is located at a fixed offset from the beginning of the file. The OMA DRM Container box 10 is the first box after the file header; and the DCF headers box 11 is the first box in the OMA DRM Container 10.
The OMA DRM Container box 10 comprises an OMA DRM common headers box 13 and, optionally, a (ISO) user data box 14. In case of multipart, the first OMA DRM Container box 10 is followed by a second OMA DRM Container box 20.
The PDCF profile (or format) differs from the DCF format to some extent. However, a similar common headers box appears also in PDCF.
The standard specification (DCF v2.0) defines a method to extend the meta-data structure of the file format by using the common headers with TextualHeaders field. In other words, the common headers box 14 can comprise textual headers -fields containing additional information of the content. The syntax is as follows: OtherHeader := Header-name " " Header-value Header-name := token Header-value := token
Using the syntax above, in accordance with an embodiment of the invention, a new custom header is defined as follows:
ContentLocationHeader := Content- Location ":" Location
Location := Token
Token = URI (as defined in RFC 2396) | <path >
Some examples are as follows:
Content-Location: "V" (this means that content is in the same directory as the SMIL presentation);
Content-Location: "\images" (this means that content is in the \images directory one-level below the directory where the SMIL file is present);
Content-Location :"http://server.com/" (this means that content is in the speci- fied HTTP server).
The header name "Content-Location" is just an example name, and may be called differently by different standards (or technical specifications) still covering the same concept.
Figure 2 shows another illustration of the DCF v2.0 File Format. Normally, DCF is designed to be used to protect high-value discrete media objects. It includes the original MIME type of the contained media object. Common DRM headers are used to indicate, e.g., encryption algorithm, where rights may be purchased etc. 3GPP asset information can be used as defined by the 3GP file format. The media object is encrypted and inserted into the wrapper format as such - complete with the original file format.
Figure 3 shows another embodiment for providing the DCF v2.0 file format with content-location information. The DCF format can be used to host multipart multimedia presentations. The first content object determines the media type association, so having a SMIL document 31 as the first object associates the file with a SMIL player. SMIL document may then reference to other objects 32-34 within the file. The SMIL document comprises a set of content-location fields, which indicate a path and a filename. In addition, each referenced file may contain a content-location field, which provides the path of the content.
According to an embodiment of the invention, file-level interleaving is disabled. Having file-level interleaving would in many cases add unnecessary complexity.
According to an embodiment of the invention, each media data is encapsulated inside a "file". On the other hand, in the prior- art solution, there exists at least one media track at the main 3GP file level, which makes a physical binding between the container file and some raw media data bitstream. According to an embodiment of the invention, each file has a content-location header. It may reside, e.g., in the beginning of each file.
Some advantages obtained by embodiments of the invention comprise the follow- ing:
The content can be mapped easily with the aid of, e.g., the SMIL file and the content-location headers. The directory structure is preserved after a content packaging operation and also restored after a possible extraction of the con- tent. Content can be played "in place" from the file, e.g., reading the content block- by-block from the file, without extracting it to the file system, thus saving space. This still enables a file tree type of representation of the file's contents. A progressive download application can make use of this field to understand whether this is the correct content to be fetched. - It is simple to generate and change if, e.g., the SMIL file is modified. As each file entity contains its own content-location information, it is simple to add or remove content without affecting the other parts of the container file. Enables mixing high-value, copyrighted and protected works with user- generated, personal content
In some embodiments, the parser/composer must or should be aware of the header, so that if a modification is done, it should be updated.
Extra level of packaging (DCF inside a DCF) can be done in order to mix copy- righted (protected) content with user- generated content.
Published international patent application WO 03/028293 Al shows a general environment for which embodiments of the invention fit into. The contents of the application are incorporated herein by reference. Especially Figure 2 of that appli- cation shows a transmission system for multimedia content streaming. The system comprises an encoder EC, which may also be referred to as an editor, preparing media content data for transmission typically from a plurality of media sources MS, a streaming server SS transmitting the encoded multimedia files over a network NW and a plurality of clients C receiving the files. The content may be from a recorder recording live presentation, e.g. a video camera, or it may be previously stored on a storage device, such as a video tape, CD, DVD, hard disk etc. The content may be e.g. video, audio, still images, and it may also comprise data files. The multimedia files from the encoder EC are transmitted to the server SS. The server SS is able to serve a plurality of clients C and respond to client requests by transmitting multimedia files from a server database or immediately from the encoder EC using unicast or multicast paths. The network NW may be e.g. a mobile communications network, a local area network, a broadcasting network or multiple different networks separated by gateways.
Further, drawing sheet 4 (Fig. 4) shows a communications system according to an embodiment of the invention. The system comprises a (streaming) server 111, which is coupled to an IP- network (Internet Protocol) 104. The IP-network 104 may be, for example, the Internet or a service provider operator's intranet (an intranet network belonging to the operator's domain). The IP-network 104 is coupled to a core network 103 of a mobile communications network. The coupling may be performed via a G; interface. The mobile communications network may be, for example, a '2.5th generation' GPRS or EGPRS network, or a 3rd or further generation cellular mobile communications network. The mobile communications network also comprises a radio access network (RAN) 102 coupled to the core network 103. The radio access network 102 provides mobile client devices 101 with access to the mobile communications network over an air-interface. The mentioned access may be provided e.g. by circuit switched means (e.g. circuit switched data call) or packet switched means (e.g. GPRS (General Packet Radio Service)). Accordingly, these techniques may be used to carry media stream packets over the air-interface portion.
Figure 5 in drawing sheet 5 shows an illustration of the server 111. The server 111 comprises a processing unit 151, a first memory 153, a network interface 155, and a second memory 152. The first memory 153, the network interface 155, and the second memory 152 are coupled to the processing unit 151.
The processing unit 151 controls, in accordance with computer software 154 stored in the first memory 153, the operation of the server 111, such as handling file formats and sending of appropriate contents stored, e.g., in the second memory (disk) 152, to the client 101 via the network interface 155.
The software 154 comprises program code for implementing a suitable layered protocol stack.
Figure 6 in drawing sheet 5 shows an illustration of the client device 101. In this embodiment, the client 101 may be, e.g., a mobile station of a cellular radio tele- phone network. However, the client may, alternatively, be a fixed terminal.
The client 101 comprises a processing unit 171, a radio frequency part 175, and the user interface 109. The radio frequency part 175 and the user interface 109 are coupled to the processing unit 171. The user interface 109 typically comprises a display, a speaker and a keyboard (not shown) with the aid of which a user can use the client device 101.
The processing unit 171 comprises a processor (not shown), a memory 173 and computer software 174 stored in the memory 173. The processor controls, in ac- cordance with the software, the operation of the client device 101, such as handling of file formats, receiving streaming media or media files from the server 111 and presentation of the received streaming media on the user interface 109.
The software 174 comprises program code for implementing a suitable layered protocol stack.
Procedures relating to file format can be implemented by software. A computer program product comprising program code stored in the receiver device 101 and run in the processor 171 can be used to implement the procedures at the receiving end of a transmission session, whereas a computer program product comprising program code stored in the sender device 111 and run in the processor 151 can be used to implement the procedures at the transmitting end.
Particular implementations and embodiments of the invention have been de- scribed. It is clear to a person skilled in the art that the invention is not restricted to details of the embodiments presented above. Furthermore, one skilled in the art will be aware that there are many additional ways to embody this invention, which are within the scope of this invention, even though not shown in one of the limited subset of examples. Especially, the invention should not be limited to any specific names of any protocols or parametres, or field names. The invention can be im- plemented in other embodiments using equivalent means without deviating from the characteristics of the invention. The scope of the invention is only restricted by the attached patent claims.

Claims

CLAIMS:
1. A method for communication, the method comprising: providing a file format for a media content; and indicating content-location information of the media content with the aid of the file format.
2. The method of claim 1, wherein the file format is configured for storing content-location information of the media content inside the file format.
3. The method of claim 1, wherein the media content is comprised in a file having the file format, and wherein the file format indicates the a target location to which the media content inside the file should be extracted or whether it should be consumed in place.
4. The method of claim 1, wherein the format comprises a file header, immediately followed by a container box, the container box having a common headers box, the common headers box providing textual header(s) for storing the content-location information.
5. The method of claim 1, wherein the method comprises establishing a virtual file tree inside a single file having one or more media contents.
6. The method of claim 1, wherein the file format contains metadata, such as a header field, indicating said content-location information.
7. The method of claim 1, wherein the file format is communicated between a sender and a receiver.
8. The method of claim 1, wherein the file format is "file-based" so that it is comprised in each file.
9. The method of claim 1, wherein the file format is for delivery method in which a media object is encrypted and the rights containing an encryption key are delivered to a device apart from the media object.
10. The method of claim 1, wherein the file format has a boxed structure based on an ISO Base Media File format, the file format being a DCF v2.0 file format or similar.
11. The method of claim 1, wherein the file format comprises a content-location header indicating a path of the media content.
12. The method of claim 11, wherein the path is indicated as an URI (Uniform Resource Indicator).
13. The method of claim 1, wherein the file format indicates a filename of the media content.
14. A sender device for communication comprising: means for generating a file format for a media content; and means for sending the file format to a receiver, wherein the file format indicates content-location information of the media content.
15. The sender device of claim 14, wherein the file format is configured for stor- ing content-location information of the media content inside the file format.
16. The sender device of claim 14, wherein the format comprises a file header, immediately followed by a container box, the container box having a common headers box, the common headers box providing textual header(s) for storing the content-location information.
17. The sender device of claim 14, wherein the file format is configured for establishing a virtual file tree inside a single file having one or more media contents.
18. The sender device of claim 14, wherein the file format comprises a content- location header indicating a path of the media content.
19. The sender device of claim 14, wherein the file format indicates a filename of the media content.
20. The sender device of claim 14, wherein the sender device is a network element, such as a server or web server.
21. A receiver device for communication comprising: means for receiving a file format for a media content; and means for using the file format, wherein the file format indicates content-location information of the media content.
22. The receiver device of claim 21, wherein the file format is configured for stor- ing content-location information of the media content inside the file format.
23. The receiver device of claim 21, wherein the format comprises a file header, immediately followed by a container box, the container box having a common headers box, the common headers box providing textual header(s) for storing the content-location information.
24. The receiver device of claim 21, wherein the file format is configured for establishing a virtual file tree inside a single file having one or more media contents.
25. The receiver device of claim 21, wherein the file format comprises a content- location header indicating a path of the media content.
26. The receiver device of claim 21, wherein the file format indicates a filename of the media content.
27. The receiver device of claim 21, wherein the receiver device is a fixed or mobile terminal.
28. A system comprising the sender device of claim 14, a network and a receiver device of claim 21, the system being configured to employ the method of claim 1.
29. The system of claim 28, wherein the file format is communicated between the sender and the receiver via the network.
30. The system according to claim 28, wherein the network is wireless, at least in part.
31. A software application executable in a sender device, the software application comprising: program code for generating a file format for a media content; and program code for causing the sender device to send the file format to a receiver, wherein the file format indicates content-location information of the media content.
32. A software application executable in a receiver device, the software application comprising: program code for receiving a file format for a media content; and program code for interpreting the file format, wherein the file format in- dicates content-location information of the media content.
3. A file format for a media content, wherein the file format is configured for storing content-location information of the media content inside the file format.
EP05717324A 2004-03-10 2005-03-09 Storage of content-location information Withdrawn EP1723562A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US55231604P 2004-03-10 2004-03-10
PCT/FI2005/050071 WO2005086028A1 (en) 2004-03-10 2005-03-09 Storage of content-location information

Publications (1)

Publication Number Publication Date
EP1723562A1 true EP1723562A1 (en) 2006-11-22

Family

ID=34919597

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05717324A Withdrawn EP1723562A1 (en) 2004-03-10 2005-03-09 Storage of content-location information

Country Status (13)

Country Link
US (1) US20050209995A1 (en)
EP (1) EP1723562A1 (en)
JP (1) JP2007525759A (en)
KR (2) KR20090098911A (en)
CN (1) CN1938700A (en)
AU (1) AU2005218205B2 (en)
BR (1) BRPI0508986A (en)
CA (1) CA2559079A1 (en)
MX (1) MXPA06010140A (en)
SG (1) SG151258A1 (en)
TW (1) TW200540696A (en)
WO (1) WO2005086028A1 (en)
ZA (1) ZA200608434B (en)

Families Citing this family (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
US8364136B2 (en) 1999-02-01 2013-01-29 Steven M Hoffberg Mobile system, a method of operating mobile system and a non-transitory computer readable medium for a programmable control of a mobile system
US7904187B2 (en) 1999-02-01 2011-03-08 Hoffberg Steven M Internet appliance system and method
US8918073B2 (en) 2002-03-28 2014-12-23 Telecommunication Systems, Inc. Wireless telecommunications location based services scheme selection
US8126889B2 (en) 2002-03-28 2012-02-28 Telecommunication Systems, Inc. Location fidelity adjustment based on mobile subscriber privacy profile
US7426380B2 (en) 2002-03-28 2008-09-16 Telecommunication Systems, Inc. Location derived presence information
US8290505B2 (en) 2006-08-29 2012-10-16 Telecommunications Systems, Inc. Consequential location derived information
US9154906B2 (en) 2002-03-28 2015-10-06 Telecommunication Systems, Inc. Area watcher for wireless network
US8027697B2 (en) 2007-09-28 2011-09-27 Telecommunication Systems, Inc. Public safety access point (PSAP) selection for E911 wireless callers in a GSM type system
US7424293B2 (en) 2003-12-02 2008-09-09 Telecommunication Systems, Inc. User plane location based service using message tunneling to support roaming
US7260186B2 (en) 2004-03-23 2007-08-21 Telecommunication Systems, Inc. Solutions for voice over internet protocol (VoIP) 911 location services
US20080090546A1 (en) 2006-10-17 2008-04-17 Richard Dickinson Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging
US20080126535A1 (en) 2006-11-28 2008-05-29 Yinjun Zhu User plane location services over session initiation protocol (SIP)
US6985105B1 (en) 2004-10-15 2006-01-10 Telecommunication Systems, Inc. Culled satellite ephemeris information based on limiting a span of an inverted cone for locating satellite in-range determinations
US7629926B2 (en) 2004-10-15 2009-12-08 Telecommunication Systems, Inc. Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas
US7353034B2 (en) 2005-04-04 2008-04-01 X One, Inc. Location sharing and tracking using mobile phones or other wireless devices
US20070008870A1 (en) * 2005-07-08 2007-01-11 Feller Jedediah M Customizable electronic presentation medium
US8660573B2 (en) 2005-07-19 2014-02-25 Telecommunications Systems, Inc. Location service requests throttling
US9282451B2 (en) 2005-09-26 2016-03-08 Telecommunication Systems, Inc. Automatic location identification (ALI) service requests steering, connection sharing and protocol translation
US7825780B2 (en) 2005-10-05 2010-11-02 Telecommunication Systems, Inc. Cellular augmented vehicle alarm notification together with location services for position of an alarming vehicle
US8467320B2 (en) 2005-10-06 2013-06-18 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) multi-user conferencing
US7907551B2 (en) 2005-10-06 2011-03-15 Telecommunication Systems, Inc. Voice over internet protocol (VoIP) location based 911 conferencing
CN100463515C (en) * 2005-11-23 2009-02-18 中国移动通信集团公司 Data protection method of multimedia broadcast multicast service
CN100362791C (en) * 2006-01-26 2008-01-16 华为技术有限公司 Method and device for obtaining content data packet in DRM
KR100782836B1 (en) 2006-02-08 2007-12-06 삼성전자주식회사 Method, apparatus and storage medium for managing contents and adaptive contents playback method using the same
US8150363B2 (en) 2006-02-16 2012-04-03 Telecommunication Systems, Inc. Enhanced E911 network access for call centers
US8059789B2 (en) 2006-02-24 2011-11-15 Telecommunication Systems, Inc. Automatic location identification (ALI) emergency services pseudo key (ESPK)
US9167553B2 (en) 2006-03-01 2015-10-20 Telecommunication Systems, Inc. GeoNexus proximity detector network
US7471236B1 (en) * 2006-03-01 2008-12-30 Telecommunication Systems, Inc. Cellular augmented radar/laser detector
US7899450B2 (en) 2006-03-01 2011-03-01 Telecommunication Systems, Inc. Cellular augmented radar/laser detection using local mobile network within cellular network
US8208605B2 (en) 2006-05-04 2012-06-26 Telecommunication Systems, Inc. Extended efficient usage of emergency services keys
WO2008057477A2 (en) 2006-11-03 2008-05-15 Telecommunication Systems, Inc. Roaming gateway enabling location based services (lbs) roaming for user plane in cdma networks without requiring use of a mobile positioning center (mpc)
US8050386B2 (en) 2007-02-12 2011-11-01 Telecommunication Systems, Inc. Mobile automatic location identification (ALI) for first responders
JP2008219702A (en) * 2007-03-07 2008-09-18 Murata Mach Ltd Image processor
KR100898326B1 (en) 2007-04-16 2009-05-20 삼성전자주식회사 Management method for drm contents based in usual history and portable device using the same
KR101451239B1 (en) * 2007-08-13 2014-10-15 삼성전자 주식회사 Method for creating and accessing media metadata in media file format and apparatus thereof
EP2196014A4 (en) 2007-09-17 2014-12-24 Telecomm Systems Inc Emergency 911 data messaging
US7929530B2 (en) 2007-11-30 2011-04-19 Telecommunication Systems, Inc. Ancillary data support in session initiation protocol (SIP) messaging
US9130963B2 (en) 2011-04-06 2015-09-08 Telecommunication Systems, Inc. Ancillary data support in session initiation protocol (SIP) messaging
KR100941756B1 (en) * 2007-12-07 2010-02-11 한국전자통신연구원 Digital contents providing system and method thereof, usr teminal for providing digital contents and method theteof
US8068587B2 (en) 2008-08-22 2011-11-29 Telecommunication Systems, Inc. Nationwide table routing of voice over internet protocol (VOIP) emergency calls
KR20100040545A (en) * 2008-10-10 2010-04-20 삼성전자주식회사 Apparatus and method for providing user interface based structured rich media data
EP2347395A4 (en) 2008-10-14 2016-11-02 Telecomm Systems Inc Location based proximity alert
US8548946B2 (en) * 2008-10-14 2013-10-01 Microsoft Corporation Content package for electronic distribution
US8892128B2 (en) 2008-10-14 2014-11-18 Telecommunication Systems, Inc. Location based geo-reminders
EP2194456A1 (en) * 2008-12-05 2010-06-09 NTT DoCoMo, Inc. Method and apparatus for performing a file operation
CN101477598B (en) * 2008-12-25 2012-02-15 华为终端有限公司 File type and copyright format conversion method and apparatus for DRM file
US8904191B2 (en) 2009-01-21 2014-12-02 Microsoft Corporation Multiple content protection systems in a file
US9301191B2 (en) 2013-09-20 2016-03-29 Telecommunication Systems, Inc. Quality of service to over the top applications used with VPN
US8867485B2 (en) 2009-05-05 2014-10-21 Telecommunication Systems, Inc. Multiple location retrieval function (LRF) network having location continuity
LU91698B1 (en) * 2010-06-10 2011-12-12 Pleimo S A System and method for processing digital content
US8336664B2 (en) 2010-07-09 2012-12-25 Telecommunication Systems, Inc. Telematics basic mobile device safety interlock
US8315599B2 (en) 2010-07-09 2012-11-20 Telecommunication Systems, Inc. Location privacy selector
US8942743B2 (en) 2010-12-17 2015-01-27 Telecommunication Systems, Inc. iALERT enhanced alert manager
US8688087B2 (en) 2010-12-17 2014-04-01 Telecommunication Systems, Inc. N-dimensional affinity confluencer
WO2012087353A1 (en) 2010-12-22 2012-06-28 Telecommunication Systems, Inc. Area event handling when current network does not cover target area
WO2012141762A1 (en) 2011-02-25 2012-10-18 Telecommunication Systems, Inc. Mobile internet protocol (ip) location
US8649806B2 (en) 2011-09-02 2014-02-11 Telecommunication Systems, Inc. Aggregate location dynometer (ALD)
US9479344B2 (en) 2011-09-16 2016-10-25 Telecommunication Systems, Inc. Anonymous voice conversation
WO2013048551A1 (en) 2011-09-30 2013-04-04 Telecommunication Systems, Inc. Unique global identifier for minimizing prank 911 calls
US9313637B2 (en) 2011-12-05 2016-04-12 Telecommunication Systems, Inc. Wireless emergency caller profile data delivery over a legacy interface
US9264537B2 (en) 2011-12-05 2016-02-16 Telecommunication Systems, Inc. Special emergency call treatment based on the caller
US8984591B2 (en) 2011-12-16 2015-03-17 Telecommunications Systems, Inc. Authentication via motion of wireless device movement
US9384339B2 (en) 2012-01-13 2016-07-05 Telecommunication Systems, Inc. Authenticating cloud computing enabling secure services
US8688174B2 (en) 2012-03-13 2014-04-01 Telecommunication Systems, Inc. Integrated, detachable ear bud device for a wireless phone
US9307372B2 (en) 2012-03-26 2016-04-05 Telecommunication Systems, Inc. No responders online
US9544260B2 (en) 2012-03-26 2017-01-10 Telecommunication Systems, Inc. Rapid assignment dynamic ownership queue
US9338153B2 (en) 2012-04-11 2016-05-10 Telecommunication Systems, Inc. Secure distribution of non-privileged authentication credentials
US9313638B2 (en) 2012-08-15 2016-04-12 Telecommunication Systems, Inc. Device independent caller data access for emergency calls
US9208346B2 (en) 2012-09-05 2015-12-08 Telecommunication Systems, Inc. Persona-notitia intellection codifier
US9456301B2 (en) 2012-12-11 2016-09-27 Telecommunication Systems, Inc. Efficient prisoner tracking
US8983047B2 (en) 2013-03-20 2015-03-17 Telecommunication Systems, Inc. Index of suspicion determination for communications request
US9408034B2 (en) 2013-09-09 2016-08-02 Telecommunication Systems, Inc. Extended area event for network based proximity discovery
US9516104B2 (en) 2013-09-11 2016-12-06 Telecommunication Systems, Inc. Intelligent load balancer enhanced routing
US9479897B2 (en) 2013-10-03 2016-10-25 Telecommunication Systems, Inc. SUPL-WiFi access point controller location based services for WiFi enabled mobile devices
US10089315B2 (en) * 2014-08-22 2018-10-02 AsterionDB, Inc. Systems, apparatus, and methods for accessing data from a database as a file
JP2018148310A (en) * 2017-03-02 2018-09-20 オリンパス株式会社 Information collection device, information terminal device, information processing system, information processing method, and information processing program
TWI806341B (en) * 2022-01-06 2023-06-21 威聯通科技股份有限公司 Container system in host, method of dynamically mounting host data to container, and application program for the same

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2182254C (en) * 1996-07-29 2000-02-15 Weidong Kou Generic file format for multiple security requirements
US5956729A (en) * 1996-09-06 1999-09-21 Motorola, Inc. Multimedia file, supporting multiple instances of media types, and method for forming same
KR100223184B1 (en) * 1996-12-28 1999-10-15 윤종용 Method storing/reading multimedia file for web brouser
US6976165B1 (en) * 1999-09-07 2005-12-13 Emc Corporation System and method for secure storage, transfer and retrieval of content addressable information
AU2001271704A1 (en) * 2000-06-29 2002-01-14 Cachestream Corporation Digital rights management
GB2371889A (en) * 2001-02-02 2002-08-07 Sony Uk Ltd Data structures
US8126810B2 (en) * 2001-06-04 2012-02-28 Panasonic Corporation Apparatus and method of flexible and common IPMP system for providing and protecting content
FI20011871A (en) * 2001-09-24 2003-03-25 Nokia Corp Processing of multimedia data
JP2003337822A (en) * 2002-05-21 2003-11-28 Fujitsu Ltd Compression retrieval archive processing method, compression retrieval archive processing program and recording medium with its program recorded
JP2006526837A (en) * 2003-06-03 2006-11-24 株式会社Ａｃｃｅｓｓ How to browse content using page save file

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005086028A1 *

Also Published As

Publication number Publication date
KR20060116255A (en) 2006-11-14
ZA200608434B (en) 2008-06-25
JP2007525759A (en) 2007-09-06
CA2559079A1 (en) 2005-09-15
KR100930295B1 (en) 2009-12-09
BRPI0508986A (en) 2007-08-28
SG151258A1 (en) 2009-04-30
KR20090098911A (en) 2009-09-17
TW200540696A (en) 2005-12-16
CN1938700A (en) 2007-03-28
WO2005086028A1 (en) 2005-09-15
US20050209995A1 (en) 2005-09-22
MXPA06010140A (en) 2007-03-01
AU2005218205B2 (en) 2010-04-08
AU2005218205A1 (en) 2005-09-15

Similar Documents

Publication Publication Date Title
AU2005218205B2 (en) Storage of content-location information
JP2007525759A5 (en)
JP7015617B2 (en) Content transmission / reception method and equipment
US8555329B2 (en) Container format for multimedia presentations
US8755524B2 (en) Motion picture file encryption method and digital rights management method using the same
AU2004306797B2 (en) Container format for multimedia presentations
CN109413447B (en) ISO-BMFF event box bearer in MPEG-2 transport stream
US20060075226A1 (en) Data file including encrypted content
WO2003040898A1 (en) An arrangement and a method for content policy control with a trusted environment in a multimedia messaging system
US9219931B2 (en) Method and apparatus for transmitting and receiving service discovery information in multimedia transmission system and file structure for the same

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060914

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080104

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111001