EP1552420A4 - Procede permettant de gerer des metadonnees - Google Patents

Procede permettant de gerer des metadonnees

Info

Publication number
EP1552420A4
EP1552420A4 EP03808905A EP03808905A EP1552420A4 EP 1552420 A4 EP1552420 A4 EP 1552420A4 EP 03808905 A EP03808905 A EP 03808905A EP 03808905 A EP03808905 A EP 03808905A EP 1552420 A4 EP1552420 A4 EP 1552420A4
Authority
EP
European Patent Office
Prior art keywords
metadata
information
fragment data
authentication
related information
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
EP03808905A
Other languages
German (de)
English (en)
Other versions
EP1552420A1 (fr
Inventor
Yang-Lim Choi
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.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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
Priority claimed from KR1020030013002A external-priority patent/KR100860984B1/ko
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of EP1552420A1 publication Critical patent/EP1552420A1/fr
Publication of EP1552420A4 publication Critical patent/EP1552420A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/48—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • 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/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes

Definitions

  • the present invention relates to a method for managing metadata in a transmission server and a client that receives the metadata, and more particularly, to a method for managing metadata including authentication of a message source, and message integrity and confidentiality until a client receives the metadata.
  • a service provider provides multimedia content and its related metadata to a client.
  • the metadata transmitted to the client may be used for various purposes.
  • the metadata can be used by the client to select multimedia content to be reproduced, recorded, or transmitted.
  • the amount and complexity of data that can be contained in metadata used by a client of a broadcasting system have increased.
  • metadata management method that enables effective metadata authentication has not yet been proposed.
  • the present invention provides a method for managing metadata to be transmitted in a metadata transmission server so that authentication of the metadata to be transmitted can be effectively performed.
  • the present invention also provides a method for managing in a client metadata received from a transmission server so that authentication of the received metadata can be effectively performed.
  • a method for managing metadata in a metadata transmission server involves (a) generating a plurality of fragment data by partitioning metadata to be transmitted on the basis of a predetermined segment unit, (b) selecting predetermined fragment data among the plurality of fragment data, (c) generating metadata-related information using the selected fragment data, and (d) transmitting the selected fragment data and the metadata-related information with data format information indicating the type of the selected fragment data.
  • a method for managing metadata in a client that receives the metadata. The method involves (a) reading predetermined fragment data and its corresponding metadata-related information and data format information indicating the type of the predetermined fragment data from the received metadata, (b) generating metadata-related information using the predetermined fragment data and its corresponding data format information, and (c) determining whether or not the received metadata has been authenticated by comparing the metadata-related information generated in step (b) with the metadata-related information read in step (a).
  • a method for managing metadata in a client that receives the metadata. The method involves (a) receiving fragment data of the received metadata, metadata-related information, data format information indicating the type of the fragment data, metadata authentication information, and an encrypted first encryption key, (b) generating metadata-related information using the fragment data of the received metadata and its corresponding data format information, (c) decrypting the encrypted first encryption key using a second encryption key stored in the client, (d) generating metadata authentication signature information using the generated metadata-related information and the decrypted first encryption key, and (e) determining whether or not the received metadata has been authenticated by comparing the generated metadata authentication signature information with the received metadata authentication signature information.
  • the present invention relates to a method for managing metadata in a transmission server and a client device, which is capable of identifying whether or not metadata has been damaged during being transmitted from the transmission server to the client device and effectively verifying which service provider or metadata content provider has transmitted the corresponding metadata to the client device.
  • FIG. 1 is a block diagram illustrating metadata authentication levels
  • FIG. 2 is a diagram illustrating a method of transmitting data using different transmission units
  • FIG. 3 is a diagram illustrating the format of a metadata container used for metadata container-level authentication in a unidirectional channel
  • FIG. 4 is a diagram illustrating a SOAP message used for metadata container-level authentication in a bi-directional channel
  • FIG. 5 is a block diagram illustrating a metadata classification method using index information of metadata
  • FIG. 6 is a flowchart of a method for managing metadata in a metadata transmission server according to a preferred embodiment of the present invention.
  • FIG. 7 is a flowchart of a method for managing metadata in a metadata client according to a preferred embodiment of the present invention.
  • FIG. 8 is a flowchart of a method for managing metadata in a metadata transmission server according to another preferred embodiment of the present invention.
  • FIG. 9 is a flowchart of a method for managing metadata in a metadata client according to another preferred embodiment of the present invention.
  • FIG. 10 is a diagram illustrating the format of a data container in a unidirectional channel.
  • FIG. 11 is a diagram illustrating a SOAP message in a bi-directional channel.
  • Metadata authentication may be performed at a transmission level or a source level.
  • transmission-level metadata authentication includes authentication of a message source, and message integrity and confidentiality.
  • the message source is not a source from which a message, i.e., metadata content, is generated but a source from which the message is transmitted.
  • a metadata content provider 120 and a service provider 140 such as SK Telecom Corp., are separately provided as shown in FIG. 1 , it can be verified through transmission-level authentication of a message source whether metadata A received by a client 160 has been transmitted from the service provider 140.
  • transmission-level authentication of message integrity verifies whether or not the metadata A has been changed in the process of transmitting the metadata A from the service provider 140 to the client 160.
  • Transmission-level authentication of message confidentiality verifies whether or not the metadata A has not yet been disclosed to a third party during the transmission process.
  • These three transmission-level authentication processes are performed using an SSL/TLS algorithm in a TCP/IP protocol, a DTCP algorithm in an IEEE 1394 protocol, and an HDCP algorithm in a DVI protocol.
  • source-level metadata authentication also includes authentication of a message source, and message integrity and confidentiality.
  • source-level authentication of a message source verifies a source from which a message, i.e., metadata content, is generated.
  • source-level authentication of a message source of the metadata A shows that the metadata A received by the client 160 has been transmitted from the metadata content provider 120.
  • Source-level authentication of message integrity verifies whether or not the metadata A has been changed in the process of transmitting the metadata A from the metadata content provider 120 to the client 160.
  • Source-level authentication of message confidentiality verifies whether or not the metadata A has not yet been disclosed to a third party during the transmission of the metadata A between the metadata content provider 120 and the client 160.
  • transmission-level metadata authentication may not need to be performed.
  • FIGS. 2(a) through 2(c) show a method of transmitting data in different transmission units in a physical layer.
  • FIG. 2(a) illustrates transmission packets that are subject to transmission-level metadata authentication.
  • Transmission-level metadata authentication is performed on each transmission packet shown in FIG. 2(a).
  • Each transmission packet has a binary XML format.
  • FIG. 2(c) illustrates metadata subject to source-level metadata authentication.
  • the metadata shown in FIG. 2(c) has a text XML format.
  • FIG. 2(b) illustrates metadata containers subject to metadata container-level authentication. Each predetermined semantic unit of metadata is contained in a metadata container. Examples of such metadata container are shown in FIGS. 3 and 4.
  • FIG. 3 is a diagram illustrating the format of a metadata container subject to metadata container-level authentication in a unidirectional channel.
  • a metadata container includes a header, fragment data, and metadata authentication information, and the header contains control information used for metadata container-level authentication.
  • the control information includes first control information F_1 , second control information F_2, third control information F_3, fourth control information F_4, and fifth control information F_5.
  • the control information ranging from the first control information F_1 through the fifth control information is comprised of a signal or a flag.
  • the first control information F_1 is an authentication flag indicating whether or not metadata container-level authentication has been performed on the fragment data.
  • the metadata container-level authentication may be performed using a media authentication code (MAC) or digital signature algorithm (DSA).
  • MAC media authentication code
  • DSA digital signature algorithm
  • the second control information F_2 is information on a specific algorithm used for generating metadata container-level authentication information.
  • the second control information F_2 may be represented by a set of binary codes. The relationship between the specific algorithm and the binary codes is defined in advance and is rendered to a server providing services and a client receiving metadata containers.
  • the third control information F_3 is data format information showing in detail the way to apply the specific algorithm to the fragment data.
  • the fragment may have a binary XML format or a text XML format, and thus the method of applying the specific algorithm to the fragment data varies depending on the format of the fragment data.
  • Metadata authentication information in the present invention is comprised of values obtained by substituting metadata into a hash function, i.e., hash values. Therefore, authentication information of fragment data having a text XML format has nothing to do with authentication information of fragment data having a binary XML format, and this is the reason why the third control information F_3 is necessary.
  • the fourth control information F_4 is encryption key information concerning metadata authentication.
  • the encryption key information is inserted into the metadata container together with metadata and then directly transmitted from a server to a client. Alternatively, the encryption key information may be transmitted from the server to the client via an additional security channel.
  • the fifth control information F_5 is an authentication level flag indicating a level of metadata authentication that has been performed. For example, when the fifth control information F_5 is set to '0', it indicates that transmission-level metadata authentication has been performed. When the fifth control information F_5 is set to '1 ', it indicates that source-level metadata authentication has been performed. With the help of the authentication level flag indicating whether or not transmission-level or source-level metadata authentication has been performed, it is possible to determine, using an application program of a client, how much reliable the metadata transmitted from a server is. Based on the reliability of the received metadata, it can be further determined whether to use the received metadata or not based on the reliability of the received metadata.
  • the metadata container includes a fragment data storage region where at least one fragment data is contained.
  • a predetermined semantic unit of metadata for example, fragment data, such as information on a program, is inserted into the metadata container in the present embodiment.
  • the metadata container of the present invention may also be used to selectively carry arbitrary units of metadata.
  • a group of related metadata is transmitted from a service provider to a client, while being carried by a series of metadata containers.
  • one metadata container includes one or more metadata fragments.
  • one of the metadata fragment data may be a sub-tree of an XML tree structure representing the entire metadata.
  • the metadata container-level authentication information includes metadata digest information and metadata authentication signature information.
  • the metadata digest information represents a value obtained by substituting one of the fragment data stored in the fragment data storage region into a unidirectional function, such as a hash function specified in the second control information F_2.
  • Each metadata digest information is related to its corresponding fragment data using a predetermined pointer.
  • first metadata digest information is related to the first fragment data using the predetermined pointer.
  • a hash function has been used to generate the metadata digest information.
  • other functions having the same characteristics as a unidirectional function such as a hash function, can also be used to obtain the metadata digest information.
  • the metadata authentication signature information is a value obtained by substituting the metadata digest information and an encryption key K into a unidirectional function, for example, the hash function specified in the second control information F_2.
  • Each metadata authentication signature information is related to its corresponding fragment data using a predetermined pointer.
  • first metadata authentication signature information is related to the first fragment data using the predetermined pointer.
  • a hash function has been used to generate the metadata authentication signature information.
  • other functions having the same characteristics as a unidirectional function such as a hash function, can also be used to obtain the metadata digest information.
  • FIG. 4 is a diagram illustrating the format of an SOAP envelope used for metadata container-level authentication in a bi-directional channel. As shown in FIG. 4, authentication-related information is included in an SOAP header, and metadata fragment data is included in the body of the SOAP envelope.
  • 'Algorithm ID' information, 'SignatureValueBaseType' information, and 'Keylnfo' information correspond to the second control information F_2, the third control information F_3, and the fourth control information F_4, respectively, of FIG. 3.
  • 'Digest' information and 'SignatureValue' information correspond to the metadata digest information and the metadata authentication signature information, respectively, described above with reference to FIG. 3.
  • 'AuthenticationLevel' information specifies a level of metadata authentication and corresponds to an authentication level flag, i.e., the fifth control information F_5 of FIG. 3. As shown in FIGS. 3 and 4, it is possible to effectively perform encryption management and metadata management by inserting fragment data obtained by partitioning the metadata on the basis of a predetermined semantic unit into a metadata container.
  • FIG. 6 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 6 is a flowchart of the operation of the metadata content provider 120 or the service provider 140 of FIG. 1. Referring to FIG.
  • a plurality of fragment data are generated by dividing metadata on the basis of a predetermined semantic unit.
  • Each fragment data generated in the present embodiment is a predetermined semantic unit of metadata that has a predetermined meaning, like program information.
  • predetermined fragment data is selected from among the plurality of fragment data generated in step 610.
  • metadata digest information is generated by substituting the selected fragment data into a hash function, for example, a secured hash algorithm, such as SHA-1.
  • a hash function is used to generate message digest information.
  • other functions having the same characteristics as a unidirectional function, such as a hash function can also be used.
  • a metadata container including the selected fragment data, the generated metadata digest information, and data format information indicating whether the format of the selected fragment data is binary XML or text XML, is generated and then transmitted to a client.
  • the format of the selected fragment data is specified using the data format information because two different types of fragment data can bring about two different types of metadata digest information in step 620 even though the two fragment data are basically the same.
  • step 640 Examples of the metadata container generated in step 640 are shown in FIGS. 3 and 4.
  • a predetermined authentication flag is set so as to indicate that metadata container-level authentication has been performed on fragment data of metadata carried by the metadata container.
  • Algorithm information that has been used to generate the metadata digest information may be inserted into the metadata container.
  • algorithm information indicating that the hash function has been used as an authentication information generation algorithm is inserted into the metadata container.
  • the algorithm information is already well known to both a server and a client, there is no need to insert such algorithm information into the metadata container.
  • metadata digest information corresponding to each of the plurality of fragment data is contained in the metadata container, and so is pointer information indicating a relationship between each of the plurality of fragment data and its corresponding metadata digest information.
  • indexing information for each of the plurality of fragment data is also contained in the metadata container.
  • FIG. 7 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 7 is the flowchart of the operation of the client 160 of FIG. 1. Referring to FIG. 7, in step 710, a metadata container is received from the metadata content provider 120 or the service provider 140.
  • step 720 first control information F_1 , i.e., an authentication flag, of a header of the received metadata container is read.
  • step 730 if the result of reading the authentication flag shows that metadata container-level authentication has been performed on fragment data contained in the metadata container, the method moves on to step 740. Otherwise, the method moves on to step 742.
  • step 740 an algorithm used for generating metadata digest information included in the metadata container is read by identifying second control information F_2, i.e., an algorithm used for generating authentication information.
  • the algorithm used for generating authentication information is a hash function. In a case where the algorithm used for generating authentication information is determined in advance and known to both the metadata content provider 120 (or the service provider 140) and the client 160, the process of reading the algorithm used for generating authentication information can be omitted.
  • step 740 the format of fragment data, used in computing metadata digest information included in the metadata container, is identified by recognizing third control information F_3, i.e., metadata format information.
  • step 742 such metadata container-level authentication is completed.
  • step 750 predetermined fragment data of metadata and its corresponding metadata digest information are read.
  • step 760 metadata digest information is generated based on the fragment data and the data format information read in step 740 by using the algorithm used for generating metadata digest information, for example, a hash function.
  • step 770 it is determined whether or not the metadata container-level authentication has been performed on metadata transmitted from the metadata content provider 120 or the service provider 140 by comparing the metadata digest information generated in step 760 with the metadata digest information of the predetermined fragment data read in step 750.
  • a metadata authentication level flag may be further included in the metadata container transmitted from the metadata content provider 120 or the service provider 140.
  • the metadata container-level authentication is a transmission-level metadata authentication or a source-level metadata authentication by reading the metadata authentication level flag using an application program of the client 160.
  • FIG. 8 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 8 is the flowchart of the operation of the metadata content provider 120 or the service provider 140 shown in FIG. 1.
  • a plurality of fragment data are generated by partitioning metadata on the basis of a predetermined semantic unit.
  • Each fragment data generated in the present embodiment is a predetermined semantic unit, such as program information.
  • step 820 predetermined fragment data among the plurality of fragment data is selected.
  • step 830 metadata digest information is generated by substituting the selected fragment data into a hash function.
  • a hash function is used to generate the metadata digest information.
  • other functions having the same characteristics as a unidirectional function, such as a hash function can also be used.
  • a metadata authentication signature is generated by substituting the metadata digest information generated in step 830 and an encryption key K into the hash function.
  • the encryption key K is specific to the service provider 140.
  • a hash function is used to generate the metadata digest information.
  • other functions having the same characteristics as a unidirectional function, such as a hash function can also be used.
  • the encryption key K used to generate the metadata authentication signature is encrypted using another encryption key L.
  • an encrypted encryption key value obtained using the encryption key L will be represented by E(K).
  • the encrypted encryption key value E(K) is transmitted to the client 160, being carried by a metadata container.
  • the encrypted encryption key value E(K) is transmitted to the client 160 via a security channel.
  • the encryption key L is transmitted to the client 160 via another security channel.
  • a metadata container including the metadata digest information, the metadata authentication signature, and data format information of the selected fragment data is generated and then transmitted to the client 160.
  • step 850 metadata container-level authentication flag is allotted to the generated metadata container so as to indicate that metadata container-level authentication has been performed on fragment data of metadata carried by the metadata container.
  • Information on an algorithm used for generating the metadata digest information may be inserted into the metadata container.
  • the data format information of the selected fragment data indicates whether the format of the selected fragment data used for generating the metadata digest information and the authentication information is binary XML or text XML.
  • metadata digest information and metadata authentication signature information for each of the plurality of fragment data are also included in the metadata container.
  • pointer information indicating a relationship between each of the plurality of fragment data and its corresponding metadata digest information and metadata authentication signature information is further included in the metadata container.
  • FIG. 9 is a flowchart of a metadata container-level authentication method using the metadata container shown in FIGS. 3 and 4. More specifically, FIG. 9 is a flowchart of the operation of the client 160 of FIG. 1.
  • a metadata container is received from the metadata content provider 120 or the service provider 140.
  • step 920 first control information included in a header of the metadata container, i.e., an authentication flag, is read.
  • step 930 if the result of reading the authentication flag shows that metadata container-level authentication has been performed on fragment data contained in the metadata container, the method moves on to step 940. Otherwise, the method moves on to step 942.
  • an algorithm used for generating metadata digest information included in the metadata container is read by recognizing second control information F_2, i.e., an algorithm used for generating authentication information.
  • the algorithm used for generating authentication information is a hash function. In a case where the algorithm used for generating authentication information is determined in advance and known to both the metadata content provider 120 (or the service provider 140) and the client 160, the process of reading the algorithm used for generating authentication information can be omitted.
  • step 940 the format of fragment data, used in computing metadata digest information included in the metadata container, is identified by recognizing third control information F_3, i.e., metadata format information.
  • step 942 metadata container-level authentication is completed.
  • step 950 predetermined fragment data of metadata contained in the metadata container, and its corresponding metadata digest information, metadata authentication signature information, and data format information are read.
  • step 960 metadata digest information is generated based upon the predetermined fragment data and its corresponding data format information read in step 950 by using the algorithm read in step 940, for example, a hash function.
  • step 970 an encryption key K that has been encrypted is decrypted using another encryption key L stored in the client 160.
  • the encryption key L has been transmitted from the metadata content provider 120 or the service provider 140 to the client 160.
  • a metadata authentication signature S is generated using the metadata digest information generated in step 960 and the decrypted key K.
  • step 990 it is determined whether or not a metadata authentication signature received by the client 160 is verified by comparing the metadata authentication signature S generated in step 980 with the metadata authentication signature information read in step
  • the metadata container may further include an authentication level flag indicating the level of metadata authentication performed on the metadata container, in which case the metadata authentication level is read using an application of the client 160 and depending on the metadata authentication level, it is determined whether to use metadata contained in the metadata container or not.
  • K_s indicates a secret key
  • K_p indicates a public key
  • a client can obtain the public key K__p through reliable sources. Therefore, in a case where the client receives a metadata container with the service provider's signature, the client figures out who the service provider that has transmitted the metadata container is and obtains the public key K_p corresponding to the identified service provider. The client verifies whether or not the received signature is valid using the public key K_p.
  • 'View' is one of the simplest examples of metadata use and is simply performed by accessing the metadata.
  • a metadata file management system is required.
  • copying the metadata using a remote application for example, in the case of transmitting the metadata from a client to a service provider, a request for the metadata and transmission of the requested metadata and its source authentication information are required.
  • metadata may include highly confidential or private data.
  • metadata needs to be encrypted before being transmitted or stored so that it can be prevented from being undesirably exposed to the public.
  • the confidentiality of the metadata can be preserved by performing transmission-level encryption on the metadata, i.e., encrypting a transmission unit or container of the metadata.
  • source-level encryption of the metadata can solve all possible problems concerning the confidentiality of metadata at a transmission level or a storage level.
  • the unidirectional channel environment concerning a conditional access system includes terrestrial broadcasting, such as ATSC or DVB, satellite broadcasting, such as Direct TV, cable TV, and IP-multicasting.
  • a unidirectional channel is used except for a case where data exchanges, such as transactions, are carried out using a return channel. Functions provided in the unidirectional channel environment concerning a conditional access system are as follows.
  • a receiver and a transmitter with hardware devices automatically authorize each other.
  • the receiver and the transmitter are enabled to share a common secret via a predetermined channel.
  • the common secret represents a code shared by the receiver and the transmitter.
  • Packet payload is encrypted and transmitted. Later, the encrypted packet payload is decrypted using the common secret or using a key decrypted with the use of the common secret.
  • a handshake protocol is used and a server and a client authorize each other by exchanging and authenticating certificates issued by a third certificate authorization organization.
  • a common secret is shared by the client and the server, and a session key is generated later.
  • Packet payload is encrypted using the session key and then transmitted.
  • the encrypted packet payload is decrypted using the session key.
  • Source authentication may be performed using an algorithm, such as DSA or MAC.
  • authorization of the client and the server is performed through the authentication and exchange of certificates issued a third certificate authorization organization. The confidentiality of data transmitted between the client and the server to the other is preserved through encryption of packet payload and message authentication.
  • the common secret needs to be shared by the receiver and the transmitter in a safe manner so that the receiver and the transmitter can authorize each other and data transmitted there between and data can be encrypted and then transmitted.
  • authorization of a receiver and a transmitter is carried out at a transmission level, and authorization of the metadata and preservation of the confidentiality of the metadata are carried at a broadcasting system level.
  • each SOAP message consisting of a head and a body can be used as a unit of protection, as shown in FIG. 10.
  • data signature information is transmitted using a SOAP message, in which case the data information is included in the body of the SOAP message, as shown in FIG. 1 1.
  • Data contained in the body of the SOAP message can be encrypted.
  • the preservation of metadata integrity and confidentiality in a broadcasting system is enabled by allotting an authentication signature to metadata and encrypting the metadata.
  • the entire metadata is not always subjected to such an encryption process because of no need to preserve the integrity of the entire metadata, it is necessary to represent specific portions of the metadata that have been encrypted or authenticated with a predetermined pointer, and this process can be performed at a source level where the predetermined pointer can be maintained by using a right management protection (RMP) system.
  • RMP right management protection
  • a source level signature a metadata source can be practically authenticated.
  • the metadata must include such information as a source authentication signature.
  • a standard description of metadata access and usage rights and implementation thereof are required.
  • a standard description may have an XML schema format or may assume the form of an element of a set of data having a predetermined meaning. Such a standard description may be generated using a conventional markup language, such as XrML, XACML, or SAML.
  • a license description and a usage rule can be isolated from metadata. In a case where there are many metadata fragments, usage information of which is worth describing, access/usage control can be performed in such a simple way as follows. Once access to an application is authorized, the application is believed to operate following predetermined usage rules set as default values.
  • an application program interface (API) of an RMP system is used to access or use metadata.
  • the API is needed when access/usage control information is managed by a TVA RMP system.
  • the API issues and authorizes a request for accessing metadata.
  • the API modifies, copies, and exports metadata.
  • authentication there are several types of authentication that can be performed at a predetermined structure level, and they are transmission-level authentication, metadata container-level authentication or SOAP message-level authentication, and source-level authentication.
  • authentication information on specific portions of metadata that have been authenticated is provided using a pointer.
  • authentication information is included in a header of a SOAP message together with a pointer for part of metadata contained in the body of the SOAP message or a pointer for the entire metadata.
  • Authentication of a metadata source requires metadata container-level authentication and SOAP message-level authentication.
  • the syntax of a metadata container enabling source authentication is shown in FIG. 1 1.
  • source authentication information needs to be provided to each node between the source and the final destination. More specifically, metadata is authenticated at a predetermined node between a source and a final destination using authentication information transmitted from a previous node, new authentication information is generated, and the metadata and the new authentication information are passed on to a next node. Alternatively, metadata is authenticated at a predetermined node using authentication information transmitted from a previous node, and the metadata and the authentication information are directly passed on to a next node so that the metadata can be authenticated again at the next node using the authentication information.
  • a flag or a signal indicating whether new authentication information is generated or not after the metadata is authenticated at a predetermined node using authentication information transmitted from a previous node, can be inserted into the authentication information.
  • the flag or signal indicating the presence of source authentication information helps a receiver determine whether to accept the corresponding metadata or not.
  • the above-described embodiments of the present invention can be realized as computer-readable codes written on a computer-readable recording medium.
  • the computer-readable recording medium includes all kinds of storages where computer-readable data can be stored, such as a ROM, a RAM, a CD-ROM, a magnetic tape, a hard disk, a floppy disk, a flash memory, an optical data storage, and a carrier wave, such as data transmission through the Internet.
  • the computer-readable recording medium can be distributed over computer systems connected via a network so that the computer-readable codes written on the computer-readable recording medium can be executed in an independent manner.
  • the method for managing metadata according to the present invention makes it possible to authenticate metadata at a metadata container level. Therefore, it is possible to carry out transmission-level authentication in any channel environment.
  • the present invention makes it possible to selectively carry out either transmission-level authentication or source-level authentication or both by inserting data format information indicating the format of metadata into a metadata container. Considering that the size of a metadata container-level packet is larger than the size of a transmission-level packet, the present invention reduces the number of packets to be transmitted, thus simplifying a system.

Abstract

L'invention concerne un procédé permettant de gérer des métadonnées dans un serveur de transmission de métadonnées. Ce procédé consiste à générer une pluralité de données fragmentaires en divisant les métadonnées destinées à être transmises sur la base d'une unité segmentaire prédéterminée, à sélectionner des données fragmentaires prédéterminées dans la pluralité de données fragmentaires, à générer des informations relatives aux métadonnées en utilisant les données fragmentaires sélectionnées et à transmettre les données fragmentaires sélectionnées et les informations relatives aux métadonnées avec des informations sur le format des données indiquant le type de données fragmentaires sélectionnées.
EP03808905A 2002-10-15 2003-04-09 Procede permettant de gerer des metadonnees Withdrawn EP1552420A4 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US41816002P 2002-10-15 2002-10-15
US418160P 2002-10-15
US42525902P 2002-11-12 2002-11-12
US425259P 2002-11-12
KR2003013002 2003-03-03
KR1020030013002A KR100860984B1 (ko) 2002-10-15 2003-03-03 메타데이터 관리 방법
PCT/KR2003/000713 WO2004036449A1 (fr) 2002-10-15 2003-04-09 Procede permettant de gerer des metadonnees

Publications (2)

Publication Number Publication Date
EP1552420A1 EP1552420A1 (fr) 2005-07-13
EP1552420A4 true EP1552420A4 (fr) 2009-01-21

Family

ID=32110678

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03808905A Withdrawn EP1552420A4 (fr) 2002-10-15 2003-04-09 Procede permettant de gerer des metadonnees

Country Status (4)

Country Link
EP (1) EP1552420A4 (fr)
JP (2) JP4397373B2 (fr)
AU (1) AU2003235490A1 (fr)
WO (1) WO2004036449A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20045201A (fi) 2004-05-31 2005-12-01 Nokia Corp Menetelmä ja järjestelmä kuvien katsomiseksi ja parantamiseksi
US7860989B2 (en) * 2005-02-02 2010-12-28 Microsoft Corporation Efficient transformation of interchange format messages
US20060294383A1 (en) * 2005-06-28 2006-12-28 Paula Austel Secure data communications in web services
US8527563B2 (en) 2005-09-12 2013-09-03 Microsoft Corporation Remoting redirection layer for graphics device interface
CN103957102B (zh) * 2014-03-11 2017-02-08 西南科技大学 一种基于分组数据包匹配的安全组播源认证方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001052178A1 (fr) * 2000-01-13 2001-07-19 Digimarc Corporation Authentification de metadonnees et incorporation de metadonnees dans des filigranes dans des signaux media
US6389403B1 (en) * 1998-08-13 2002-05-14 International Business Machines Corporation Method and apparatus for uniquely identifying a customer purchase in an electronic distribution system
US20020103920A1 (en) * 2000-11-21 2002-08-01 Berkun Ken Alan Interpretive stream metadata extraction

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100279735B1 (ko) * 1998-11-20 2001-02-01 정선종 메타데이터를 이용한 멀티미디어 컨텐츠 전달방법
JP2002023903A (ja) * 2000-07-11 2002-01-25 Nippon Telegr & Teleph Corp <Ntt> ユーザ対話方法、この方法を実施する装置、およびこの方法を実行するプログラムを記憶する記憶媒体
JP2002057662A (ja) * 2000-08-07 2002-02-22 Sony Corp 情報処理装置、情報処理方法、並びに記録媒体
JP4296698B2 (ja) * 2000-08-17 2009-07-15 ソニー株式会社 情報処理装置、情報処理方法、並びに記録媒体
KR100417569B1 (ko) * 2000-12-08 2004-02-05 학교법인 인하학원 메타데이터 교환표준을 이용한 분산 이종 데이터베이스검색방법
KR100398610B1 (ko) * 2001-01-30 2003-09-19 한국전자통신연구원 멀티미디어 컨텐츠에 동기화된 메타데이터 전송 장치 및방법
JP2003051816A (ja) * 2001-08-07 2003-02-21 Sony Corp コンテンツ配信システム、コンテンツ配信方法、およびデータ処理装置、データ処理方法、並びにコンピュータ・プログラム
AUPR970301A0 (en) * 2001-12-21 2002-01-24 Canon Kabushiki Kaisha Content authentication for digital media based recording devices
JP2003248737A (ja) * 2002-02-22 2003-09-05 Ntt Comware Corp メタ情報への信頼性付与システム、及び信頼性付与方法
JP2004072184A (ja) * 2002-08-01 2004-03-04 Nippon Hoso Kyokai <Nhk> データ改竄防止装置およびそのプログラム
JP4309629B2 (ja) * 2002-09-13 2009-08-05 株式会社日立製作所 ネットワークシステム
JP4009634B2 (ja) * 2004-03-04 2007-11-21 日本電気株式会社 アクセス制御方法、アクセス制御システム、メタデータ制御機、及び送信系装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6389403B1 (en) * 1998-08-13 2002-05-14 International Business Machines Corporation Method and apparatus for uniquely identifying a customer purchase in an electronic distribution system
WO2001052178A1 (fr) * 2000-01-13 2001-07-19 Digimarc Corporation Authentification de metadonnees et incorporation de metadonnees dans des filigranes dans des signaux media
US20020103920A1 (en) * 2000-11-21 2002-08-01 Berkun Ken Alan Interpretive stream metadata extraction

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2004036449A1 (fr) 2004-04-29
EP1552420A1 (fr) 2005-07-13
JP4740923B2 (ja) 2011-08-03
JP4397373B2 (ja) 2010-01-13
JP2008118653A (ja) 2008-05-22
JP2006506025A (ja) 2006-02-16
AU2003235490A1 (en) 2004-05-04

Similar Documents

Publication Publication Date Title
US8301884B2 (en) Method of managing metadata
KR100965886B1 (ko) 메타데이터 관리 방법
US9569627B2 (en) Systems and methods for governing content rendering, protection, and management applications
US7668316B2 (en) Method for encrypting and decrypting metadata
KR100753932B1 (ko) 컨텐츠 암호화 방법, 이를 이용한 네트워크를 통한 컨텐츠제공 시스템 및 그 방법
US8683602B2 (en) System and method for multilevel secure object management
US7200230B2 (en) System and method for controlling and enforcing access rights to encrypted media
US20130283051A1 (en) Persistent License for Stored Content
US20040139312A1 (en) Categorization of host security levels based on functionality implemented inside secure hardware
CN109067814B (zh) 媒体数据加密方法、系统、设备及存储介质
JP3695992B2 (ja) 放送受信装置及びコンテンツ利用制御方法
EP2466511B1 (fr) Structures de stockage de média pour le stockage de contenu et dispositifs pour l&#39;utilisation de telles structures
US20060161502A1 (en) System and method for secure and convenient handling of cryptographic binding state information
US20060106721A1 (en) Method for retransmitting or restoring contents key for decrypting encrypted contents data
US9311492B2 (en) Media storage structures for storing content, devices for using such structures, systems for distributing such structures
JP4740923B2 (ja) メタデータの管理方法
CN101216869B (zh) 用于管理元数据的方法

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: 20050426

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 IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB IT NL

A4 Supplementary search report drawn up and despatched

Effective date: 20081223

17Q First examination report despatched

Effective date: 20090710

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SAMSUNG ELECTRONICS CO., LTD.

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: 20191101