WO2007093932A2 - A device for and a method of managing auxiliary data assigned to main data - Google Patents

Abstract

A device (100) for managing auxiliary data assigned to main data, wherein the device (100) comprises a classification unit (101) adapted to classify auxiliary data into known auxiliary data and into unknown auxiliary data, a storage unit (102, 103) adapted to store auxiliary data classified by the classification unit (101) as unknown auxiliary data, and a management unit (104) adapted to manage a manner of storing the auxiliary data classified by the classification unit (101) as unknown auxiliary data based on a number of accesses to the auxiliary data classified by the classification unit (101) as unknown auxiliary data.

Description

A device for and a method of managing auxiliary data assigned to main data

FIELD OF THE INVENTION

The invention relates to a device for managing auxiliary data assigned to main data.

The invention further relates to a method of managing auxiliary data assigned to main data.

The invention further relates to a program element.

The invention further relates to a computer-readable medium.

BACKGROUND OF THE INVENTION Electronic entertainment devices become more and more important.

Particularly, an increasing number of users buy hard disk based audio/video players and other entertainment equipment. When using such devices to play back multi-media content, the management of metadata provided in addition to items of multi-media content and including additional information characterizing the multi-media content is an important issue. US 6,804,677 B2 discloses a method for encoding XML tree data that includes the step of encoding the semi- structured data into strings of arbitrary length in a way that maintains non-structural and structural information about the XML data, and enables indexing the encoded XML data in a way that shall facilitate efficient search and browsing. US 2003/0154216 Al discloses a database optimizer collecting statistics regarding which types of applications are accessing the database, and making one or more changes to the database schema to optimize performance according to the collected statistics. In a first embodiment, the optimizer detects when a certain type of application accesses the database a percentage of time that exceeds a predefined threshold level, and if the data in the database is stored in a less-than-optimal format for the application, the data type of one or more columns in the database is changed to a more optimal format for the application. This means that the database optimizer must recognize when a different type of application requests data from any changed column, and must potentially perform a conversion from the new data type to the old data type before returning the requested data. In a second embodiment, the optimizer detects when one type of application accesses a column a percentage of time that exceeds a first predefined threshold level and that accesses the column a percentage of time that is less than a second predefined threshold level. In this case, a new column is created in the database so the data is present in both formats, thereby optimizing the performance of both old and new applications that access the data. The database optimizer looks at what type of application requested data, and returns the data in the format optimized for that type of application.

BRIEF SUMMARY OF THE INVENTION

It is an object of the invention to enable efficient management of data. In order to achieve the object defined above, a device for managing auxiliary data assigned to main data, a method of managing auxiliary data assigned to main data, a program element and a computer-readable medium according to the independent claims are provided.

According to an exemplary embodiment of the invention, a device for managing auxiliary data assigned to main data is provided, wherein the device comprises a classification unit adapted to classify auxiliary data into known auxiliary data and into unknown auxiliary data, a storage unit adapted to store auxiliary data classified by the classification unit as unknown auxiliary data, and a management unit adapted to manage a manner of storing the auxiliary data classified by the classification unit as unknown auxiliary data based on a number of accesses to the auxiliary data classified by the classification unit as unknown auxiliary data.

According to another exemplary embodiment of the invention, a method of managing auxiliary data assigned to main data is provided, the method comprising classifying auxiliary data into known auxiliary data and into unknown auxiliary data, storing auxiliary data which has been classified as unknown auxiliary data, and managing a manner of storing the auxiliary data which has been classified as unknown auxiliary data based on a number of accesses to the auxiliary data which has been classified as unknown auxiliary data.

Beyond this, according to another exemplary embodiment of the invention, a computer-readable medium is provided, in which a computer program is stored, which computer program, when being executed by a processor, is adapted to control or carry out the above-mentioned method.

Moreover, according to still another exemplary embodiment of the invention, a program element is provided, which program element, when being executed by a processor, is adapted to control or carry out the above-mentioned method. The data processing or data management according to the invention can be realized by a computer program, that is to say by software, or by using one or more special electronic optimization circuits, that is to say in hardware, or in hybrid form, that is to say by means of software components and hardware components. According to an exemplary embodiment of the invention, a data management scheme is provided in which data of a scheme which is presently unknown by a device is not simply thrown away or deleted, but is stored in a separate category of presently unknown data apart from data of a known format understandable by the device. When the system detects that relatively high user access to items of the data in the presently unknown format occurs, such unknown data may be stored in a modified manner or may be upgraded to a higher relevance level taking into account this high amount of traffic. Such a classification of data into groups of "known data", "heavily accessed or particularly relevant unknown data" and "remaining unknown data" may allow for a very efficient data management based on the actual relevance and based on the format of the data in the data management system. Such a management scheme may be particularly applied in the context of the management of auxiliary data which is linked to main data. "Main data" may be actual content to be managed by the system, and "auxiliary data" may be metadata further specifying or characterizing assigned items of the main data. More particularly, the main data may be reproducible content like audio items (like songs or speeches), video items (like music video clips or movies), multimedia content, etc. The auxiliary data may be data specifying such content in more detail, for instance providing information with respect to an artist, background information, timing information, or any other control information.

The term "known" auxiliary data may denote auxiliary being provided in a format which is processable or interpretable by a system. The term "unknown" auxiliary data may particularly denote auxiliary data being in a format or describing a category which is not interpretable by the system, for instance since this is a new category which is not already recognizable by the system.

With regard to the classification between "known" and "unknown" metadata, the distinction between such data classes may be particularly denoted as a distinction between consolidated versus unconsolidated or active versus inactive or live versus archived or integrated versus not integrated data.

Particularly, there may be three types (classes) of data. Firstly, data that is described by an active part of the schema. Secondly, data that has a describing schema fragment but one that is not integrated into the active schema. Thirdly, "undescribed" or non- described data. The third is typically unknown. The second is unknown or retired. The first is known and active.

According to an exemplary embodiment, it is also possible that a device which is provided with such auxiliary data of unknown format searches for the (presently unknown) class to which the unknown metadata item belongs. Information with respect to a class to which the auxiliary data belongs may be taken from the auxiliary data containing data packet itself, namely from a packet or identifier attached to the main data/to the auxiliary data and representing a classification identification portion. Additionally or alternatively, such information may be requested by the device from an external source having sent this data, for instance from a connected device, from a network like the Internet, etc.

According to a further exemplary embodiment, the management of auxiliary data, regardless whether items of the auxiliary data are known and/or unknown, may be performed in a manner that, for storing such data, additional information regarding the order according to which items of such data have been received from a source is also stored. Taking this measure may allow to later retrieve or restore the original order of such a set of known and unknown data items, particularly in a scenario in which such a mixture is transmitted to a second device, in which portions of unknown data and portions of known data may differ from portions of unknown data and portions of known data stored in the first device. Therefore, it may be possible for the second device, using the original order information, to recover the data in the original order, even when the two devices have different versions of software installed thereon, even if there are formats which are known by a first device and not known by a second device and/or formats known by the second device but not by the first device.

According to an exemplary embodiment, a method of access tracking in an overflow field to build new columns is provided. In such a context, metadata available from other devices can often contain fields currently unknown to a consumer electronics device. An exemplary embodiment of the invention describes a method to preserve the metadata that is available from the other devices but is currently not in a state to be interpreted by the consumer electronics device. The preserved metadata may be stored in an overflow column or table in raw format.

According to an exemplary embodiment, a method is described to update the main database scheme (for instance adding a new column) based upon the amount of traffic accessing the preserved metadata in the overflow column/table thereby improving access speed while reducing or minimizing the size of the database schema. Exemplary embodiments of the invention may relate to the field of metadata storage in databases for use in consumer electronics devices that interact with other devices. Exemplary embodiments of the invention also relate to consumer electronics devices by which software can be updated for improved functionality. When currently unknown fields of metadata are available from other devices, such metadata may be stored nevertheless, even if such metadata is currently not in a state to be interpretable by the consumer electronics device. Such preserved metadata may be stored in an overflow column or a table in raw format, that is without immediate format adaptation. Future improvements in software functionality of the consumer electronics may later allow an interpretation of the raw metadata. However, parsing everything leads to a large database scheme. Thus, the main database scheme may be updated based on the amount of traffic accessing the preserved metadata in the overflow column/table, thereby improving access by reducing the size of the database scheme.

Consumer electronics devices are becoming software enabled, with regular upgrades in functionality. In such a consumer device, the metadata database may also evolve. A method of preserving all metadata for future parsing may thus improve the functionality of such a system. The future automatic improvement of performance by merging high traffic preserved data is beneficial for a user and is user- friendly.

The large amount of content on a typical consumer electronics device (for instance an eHub, a set top box, a personal video recorder, a mobile personal server), for example thousands or more of songs, pictures and videos can make access difficult for a user. Already the large amount of data may make it difficult to navigate to what a user wants or needs. Metadata, which may come from an external source and/or may be generated by local multimedia and video content analysis algorithms, becomes an important ingredient in building content retrieval systems. A data management system containing management content metadata and other related metadata on the embedded device according to an exemplary embodiment of the invention is of high value for a user during retrieval.

One of the challenges of designing and building such a data management system for an embedded device operating in a network environment is dealing with multiple different metadata formats and schemes (for instance MPEG 7, MPEG 21, MPV, WinFS, MTP, ID3Tag, etc.). This holds particularly when an application desires to be provided with answers fast, resources of the devices are limited, and when only a small or minimal amount of power shall be consumed. With regard to the necessity of dealing with multiple formats and schemes, it is possible to define one abstract global scheme being a superset of all other schemes, and then map other schemes to it. However, under particular circumstances, such a scheme may be not practical. The superset may be too big and will be most of the time practically empty. Also, new schemes evolve every day, and it is not easily possible or practical to anticipate all future variations. It is presently believed that the use of embedded relational database technologies offers the best performance even in handling XML formatted data. Many metadata standards are expressed in XML.

In the following, a solution of a problem of an efficient handling of semi- structured or opaque data (that is to say data that does not fit or that does not fully fit in a presently installed scheme) will be explained.

There are particularly two possibilities in dealing with such opaque or unknown metadata: Ignore it or keep it. Skipping such data may have the consequence losing valuable information that may be useful later. Recovering this data later or recreating it will be cumbersome and time consuming. Keeping it means either storing it as it is (in its own format) or trying to apply some algorithms and merge it with a global scheme. However, such algorithms may be complex, and the task may be virtually impossible without additional external information.

According to an exemplary embodiment of the invention, the opaque data may be stored in its own format until it is accessed. At that time it becomes clear that it is worthwhile to analyze this data and to extract specific field until more is known about it by the application (if it requests the data it is going to use, it must know what it is for). Thus, such opaque metadata may be stored in its own format (for instance expressed in XML) in a special column of a relational table or in a special table for overflow metadata in the data management system. This may allow this opaque metadata to be retrieved by applications which know what to do with it yet remain in the schema of the data management system unchanged (that means that there may be no need to spend effort on redesigning the schema and exporting and/or importing the existing data). This may increase flexibility and interoperability of the data management system. However, a challenge of such a system is that at access time the application may have to parse this overflow fragment to retrieve the designated data, and it may need to be aware that it needs to this. Also, searching through these overflow fragments may be much slower than searching through relational data (again because of parsing and the impossibility to use indexing techniques). In order to cope with this challenge, an access tracking mechanism may be used according to an exemplary embodiment of the invention to detect the user frequency of attributes stored inside the overflow data. If a particular attribute gets heavy access (for instance access above a certain threshold level), then the data management system may create a dedicated column in a schema and may copy or move values of this attribute from the overflow field. The data management system, if it gets a request, may first look through all "general" or "explicit" fields in the schema and then, only if does not find, may look through overflow fields (or tables), if any.

The usage of such a mechanism may increase access speed and/or interoperability, which may be of great value for embedded consumer electronics devices.

Exemplary fields of applications of exemplary embodiments of the invention are any devices containing and managing data from heterogeneous sources (for instance an eHub, a set top box, a personal video recorder, a mobile personal server, etc.).

According to another exemplary embodiment of the invention, a robust schema extension by an embedded extension identifier may be provided, as will be explained in the following.

As mentioned above, an increasing number of consumer electronics devices contain a large amount of content. The promise of the so-called "connected planet" is that these devices get interconnected and share their content. To enable the management and navigation of this distributed data, metadata may be employed. However, for connecting devices from different manufacturers that manage content from various sources, mismatches in the metadata that describe the content may occur, since different content sources may use different schemas.

In some cases, next to the data itself, the schema for the sent data may be also sent (most of the time not much more than just a label). The receiving application may then know what the new field shall describe, but it still does not know what to do with the data. Storing the unknown data as normal columns in the database would put a constraint on resources and extend processing times without providing a significant benefit to the target system. A way of handling this is that all metadata fields that are known to the target device (or application) are stored in their counterpart in the target device and that fields unknown to the target device are stored, for instance lumped together, in an overflow field (see description above).

Ideally the target system would know what the unknown fields contain. It may be desirable to know what the data means, so it could be used in identifying, managing or navigating the content or, equally useful, be thrown away if it is too specific to be used outside the originating system. However, it may also happen that the content and its metadata arrives at a target device as a static file, without a description of the schema.

With the connected planet paradigm mentioned above becoming reality, it may happen that more instances of schema extensions and field name collisions are bound to become more common. An issue in this context is how to transparently, automatically, consistently and robustly extend the schema used by an application or device to include metadata types being new or from unknown origin.

In such a context, the following measures may be taken. When communicating records with extensions, particularly two situations may be distinguished:

1. If no schema fragment is sent with the data, embedded in the value field of the extension may be an extension identifier and the value of the field.

2. If a schema fragment is sent with the data, there is the choice to still embed an extension identifier for reasons of compatibility or place it in the schema fragment for reasons of efficiency.

When requesting information, applications may first pose the query that they want to pose, which may include fields that do not have their own column in the queried database. The queried database may send the fields it does know and if the overflow field is not empty may add a special marker, like "may be", on the other fields. The querying application may send a schema fragment to describe what it wants. This may include the extension identifier. If a database management system (DBMS) now can find what the application is looking for, it may send the data and may update the scheme to include the new field.

According to still another exemplary embodiment of the invention, a record reconstitution may be provided which is transparent, as will be explained in the following.

As mentioned above, when connecting devices from different manufacturers, managing content from various sources may involve the problem of mismatches in the metadata that describes the content. A model used to define the metadata, comprising field names, properties and relations, is in database terms called a schema. So the problem is that different content sources use different schemas.

In such a scenario, particularly two problems may arise: Schema integration and schema evolution. Schema integration may be required when the core schemes are not aligned, for instance same name for different fields, different names for the same field, even combining or splitting fields. To align this, some sort of mapping may be carried out. Schema evolution occurs if the same core scheme is used but extensions are created. Particularly for that situation, a solution will be explained in the following. With a mapping, the schema integration case reverts to a schema evolution case.

There are particularly two exchange protocol variants. One where a schema fragment is sent with the data. Another one where no schema fragment is sent.

Ideally, the data in the overflow field may remain accessible to target systems that do have the complete schema for the record stored. An issue is how to achieve automatic and transparent access to the original record.

If a device asks for the set of data it knows only ("select a, b, c, d from efg"), no overflow information is communicated. If a device asks for the whole record ("select * from ..."), the content of the overflow field is either cut or sent as overflow field. Conventionally, there may be not enough information to reconstitute the original record. Thus, information may be lost.

According to an exemplary embodiment, upon request ("select * from ..."), the database management system may give the whole original record including content of an overflow field in its original order. In other words, it may reconstitute the record before it was stored. To enable this, next to the overflow field, the original positions of the field in the original record for the fields in the overflow field may be recorded.

Embodiments of the invention may be implemented in the context of any data management system, for instance for managing audio content, pictures, personal data, etc.

Next, further exemplary embodiments of the invention will be explained.

In the following, further exemplary embodiments of the device for managing auxiliary data assigned to main data will be explained. However, these embodiments also apply for the method of managing auxiliary data assigned to main data, for the program element and for the computer-readable medium.

The device may be adapted to manage metadata as the auxiliary data. The term "metadata" may particularly denote data being dependent on main data which provides more detailed information with respect to corresponding main data. Thus, the main data may also be used without the metadata, but the metadata usually has no meaning without (a relationship to) the main data.

The device may further be adapted to manage auxiliary data assigned to at least one of the group consisting of audio content, image content, video content and multimedia content as the main data. For instance, an item of the main data may be a music song. The corresponding auxiliary data or metadata may then be additional information further specifying this item of the main data, for instance by providing information about a genre, an artist, an album name, a release year, a recording mode (plugged/unplugged).

The device may comprise a search unit adapted to perform a search among the main data, the search being based on at least one user-defined criteria being related to the auxiliary data. Such a search unit may allow a user to define a search criteria (like "I want Michael Jackson songs"). Based on such a search criteria, a database including metadata assigned to available main data may be queried with regard to this keyword-based search criteria, and the metadata may provide the information which of the stored or available songs are from the artist "Michael Jackson". Such a search opportunity may allow a user to efficiently handle even a high amount of data.

The classification unit may be adapted to classify auxiliary data into known auxiliary data and into unknown auxiliary data based on whether a format of the auxiliary data is interpretable by the device or not. Thus, the classification unit does not simply throw away data which it

(presently) cannot handle, but may store even such data apart from the interpretable data. For instance, the classification unit may be capable of interpreting special data in the XML format, and may thus handle data being not available in the XML format separately. Furthermore, the classification unit may only be capable of interpreting special types of information in the XML format, for example artist metadata, but not genre metadata . Even in such a case, the unknown rest may be not simply thrown away, but may be stored as it is and may be used later.

The storage unit may be adapted to store auxiliary data classified by the classification unit as known auxiliary data separately from the auxiliary data classified by the classification unit as unknown auxiliary data. Thus, a hierarchy or a separation may be established between known and unknown data, for instance assuming that unknown data is less relevant than known data. Such semi-empiric search rules may allow to improve the velocity of a search in such a data landscape.

The storage unit may be adapted to store auxiliary data classified by the classification unit as unknown auxiliary data without modifying a format of the unknown auxiliary data. Therefore, no format transformation which would involve additional computational burden and complex algorithms has to be carried out, but the auxiliary data which is not interpretable at the moment by the device is stored as such in a raw format. The storage unit may be adapted to store auxiliary data classified by the classification unit as unknown auxiliary data in a separate portion of a relational table or in a separate table for overflow auxiliary data. Thus, the system may distinguish between known and unknown data therefore specifying a search strategy which may first query fields of known data, and only in the case of a non-successful search there, even unknown fields may be queried.

The management unit may be adapted to manage a manner of storing the auxiliary data classified by the classification unit as unknown auxiliary data based on a usage frequency of the auxiliary data classified by the classification unit as unknown auxiliary data. In other words, unknown auxiliary data being subject of heavy traffic may be considered to be more relevant than data which is not accessed very frequently. Therefore, the amount of traffic caused by a user may be taken as a measure for the relevance of such data, and may thus define an order according to which a search is performed. This may allow to rapidly find relevant data, since the search strategy is oriented on a reasonable assumption concerning the relevance. Therefore, a hierarchic search strategy may be applied.

The management unit may be adapted to modify properties of treating or ranking or storing auxiliary data classified by the classification unit as unknown auxiliary data in case that the number of accesses to the auxiliary data classified by the classification unit as unknown auxiliary data exceeds a predetermined threshold value. Such a predetermined threshold value may be a fixed value stored in the device or may be determined statically or dynamically on the basis of an (for instance) average access to data fields, that is to say fields of known data. Exceeding the threshold value may allow to assign a high relevance value to the corresponding unknown data, falling below the threshold value may have the consequence that the relevance of this data piece is downgraded. The search unit may be adapted to perform the search in accordance with a search order starting with searching based on the auxiliary data classified by the classification unit as known auxiliary data, continuing with searching based on the auxiliary data stored according to the modified storage scheme, and finishing with searching based on the auxiliary data classified by the classification unit as unknown auxiliary data. This order of search may, on the average, allow for an efficient retrieval of the necessary information in a short time.

The device may comprise a user interface adapted for a unidirectional or for a bidirectional communication with the device. Via such a user interface, a human user may provide the device with control commands, or may be provided with requested information (e.g. a search result) by the device. For instance, the user may define, via the user interface, a search criteria according to which a search for audio content stored in the device may be carried out. A search result may be provided to the user so as to enable a user to further refine the search, etc. Such a user interface may be graphical user interface (GUI). The user interface may include a display device (like a liquid crystal display, a plasma display device or the like) for displaying information to a human operator. Furthermore, the user interface may comprise an input device allowing the user to input data (like data specifying the operation mode of the device or keywords for a search) or to provide the system with control commands. Such an input device may include buttons, a keypad, a joystick, a trackball, a touch screen, or may even be a microphone of a voice recognition system. The user interface may allow a human user to communicate in a bidirectional manner with the system.

Furthermore, the device may comprise a data interface adapted for providing the device with the main data and/or with the auxiliary data. Such a data interface may be an interface like a USB interface, a connection to the Internet, etc., which may allow to connect a further device for wired or wireless communication with the device. In the case of a wired communication, a simple cable may be used. In the case of a wireless communication, schemes like WLAN, infrared communication or Bluetooth may be implemented.

The data interface may be adapted for transmitting the main data and/or the auxiliary data to a destination device connectable to the data interface. Therefore, the data interface may not only be a data receipt interface but also a data transmission interface. Receipt and transmission may be realized via a common shared bidirectional data interface, or via two separate data interfaces, one for data receipt and one for data transmission.

The device may comprise a class identification unit adapted to identify a class of unknown auxiliary data. When the format of unknown auxiliary data is presently not known, the device may try to find out to which class the auxiliary data may belong. For this purpose, the device may try to get access to any source of information which may allow for further specifying the requested class.

The class identification unit may particularly be adapted to identify the class of the unknown auxiliary data by requesting, from a source of the unknown auxiliary data connectable to the data interface, a classification identifier for the known auxiliary data indicative of the class to which the unknown auxiliary data belongs. Therefore, when a data packet has been received via the data interface by the device, the device being however incapable of interpreting data received from the source entity, may be sent a request via the communication network asking for further information defining the category of the data.

Additionally or alternatively, the class identification unit may be adapted to identify the class of unknown auxiliary data based on a classification identifier attached to the unknown auxiliary data by a source of the unknown auxiliary data connectable to the data interface and being indicative of the class to which the unknown auxiliary data belongs. Therefore, an identifier may be attached to the metadata further specifying a format in which the metadata is present. Based on such an identifier, the device may judge to which format the presently unknown metadata belongs. The management unit of the device may be adapted to manage a manner of storing the auxiliary data classified by the classification unit as unknown auxiliary data based on the class indicated by the classification identifier. Therefore, the manner of storing of the data, and also the manner defining a hierarchy within a search of content stored in the storage unit, may be determined based on the classification of such data. The management unit of the device may be adapted to manage the storing of auxiliary data classified by the classification unit as unknown auxiliary data and classified by the classification unit as known auxiliary data together with order information indicative of an order according to which the auxiliary data has been provided from a source of the unknown auxiliary data connectable to the data interface. In other words, when sending data to another entity, the data may be sent in a format or with corresponding information which is indicative of an order in which the data has been originally received by the device. This may be advantageous in a scenario in which the device and the destination entity are capable of interpreting different formats. For instance, it may be possible for the device to interpret a first format but not to interpret a second format, whereas the destination may interpret the second format but not the first format. By providing the data in a form allowing for sequencing data items in the original order, it may be easier to handle this data by a connected device. Therefore, when the stored auxiliary data is to be transmitted to a destination, the transmission may be performable in a manner that the destination receives the stored auxiliary data together with the order information so as to allow the destination to store the transmitted stored auxiliary data in the order according to which the auxiliary data has been provided originally from the source to the device.

The device may be realized as a consumer electronics device, particularly as a consumer electronics device via which a data transfer is possible in a unidirectional manner or in a bidirectional manner. The schemes mentioned above may enable a consumer electronics device to be used by a user in a user- friendly manner, and may allow particularly to find desired data items even among a huge amount of data rapidly.

The device may be realized as at least one of the group consisting of an electronic hub, a set top box, a personal video recorder, a mobile personal server, a multimedia server, a digital video recording device, a network-enabled device, a conditional access system, a portable audio player, a portable video player, a mobile phone, a DVD player, a CD player, a hard disk based media player, an Internet radio device, a computer, a television, a public entertainment device and an MP3 player. Therefore, any entertainment device dealing with a huge amount of multimedia data may advantageously implemented in systems according to exemplary embodiments of the invention.

The aspects defined above and further aspects of the invention are apparent from the examples of embodiment to be described hereinafter and are explained with reference to these examples of embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described in more detail hereinafter with reference to examples of embodiment but to which the invention is not limited.

Fig. 1 illustrates a device of managing auxiliary data assigned to main data according to an exemplary embodiment of the invention.

Fig. 2 illustrates an example of XML data mapping to relational table. Fig. 3 illustrates a song table of a user's device with overflow field. Fig. 4 illustrates a song table of a remote device with BPM and rating fields. Fig. 5 illustrates a song table of a user's device with tight overflow field. Fig. 6 illustrates a song table of a user's device with automatically created

BPM field.

Fig. 7A illustrates a flow-chart of an algorithm showing request handling in a traditional data management system.

Fig. 7B illustrates a flow-chart of an algorithm showing request handling in a data management system according to an exemplary embodiment of the invention (right-hand side of Fig. 7).

Fig. 8 to Fig. 14 illustrate storage schemes of main data and metadata in a device according to an exemplary embodiment of the invention. Fig. 15 and Fig. 16 show schemes illustrating an operation of devices according to exemplary embodiments of the invention.

Fig. 17 to Fig. 25 illustrate storing schemes of main data and metadata according to exemplary embodiments of the invention.

The Figures are schematically drawn and not true to scale, and the identical reference numerals in different Figures refer to corresponding elements. It will be clear for those skilled in the art, that alternative but equivalent embodiments of the invention are possible without deviating from the true inventive concept, and that the scope of the invention will be limited by the claims only.

DETAILED DESCRIPTION OF THE INVENTION

In the following, referring to Fig. 1, a system 110 for processing and reproducing audio content according to an exemplary embodiment of the invention will be explained.

The system 110 comprises a device 100 for managing audio data and assigned metadata.

The device 100, as will be explained below in more detail, may be connected to a further device 121 or 120 for uploading or downloading audio data and/or metadata in a bidirectional manner. The device 121 may be a USB stick, a flash memory card, or a device similar to the device 100. Furthermore, the device 100 may be connected via the Internet 122 to a server computer 120 which may be a provider computer for providing audio content and assigned metadata. The device 100 may be used to store, manage and reproduce audio content in correspondence with metadata describing this audio content in more detail, wherein the manner of playing back the audio content may be determined or controlled by a user. Thus, a personal audio content reproduction system may be provided.

The device 100 for managing the metadata assigned to the audio data comprises a classification unit 101 which is capable of classifying incoming metadata into a first category (namely known metadata) and into a second category (namely unknown metadata). The term "known" metadata may denote metadata being provided in a format which is processable or interpretable by the device 100. The term "unknown" metadata may particularly denote metadata being in a format or describing a category which is not interpretable by the system 100, for instance since this is a new category which is not already recognizable by the software running on the system 100.

Furthermore, the device 100 comprises a first storage unit 102 and a second storage unit 103. The first storage unit 102 is adapted for storing the metadata and may thus be denoted as a metadata storage unit 102. The second storage unit 103 is foreseen to store main data (that is to say the actual audio content) and may thus be denoted as a main data storage device 103. Although the storage units 102 and 103 are shown as separate devices in Fig. 1, it is alternatively possible to provide the storage units 102, 103 as a single common shared memory device, for instance being partitioned so as to administer the audio data and the corresponding metadata.

In the storage unit 102 received metadata classified by the classification unit 101 to be unknown auxiliary data is stored as well as the received metadata classified by the classification unit 101 as known metadata. Furthermore, the main data, that is the audio content, is stored in the storage unit 103. Furthermore, the device 100 comprises a central processing unit (CPU) or control unit 104 (which may also be denoted as a management unit) and which is adapted to manage a manner or a scheme of storing the metadata classified by the classification unit 101 as unknown metadata based on a number of accesses of a user 107 to the unknown metadata. In other words, a human user 107 may communicate with the device 100, more particularly with the CPU 104, via a user interface 105 and may provide the system 110 with commands specifying an operation mode of the device 100. In this context, the user may define a search command like "I want to hear Jazz music in the period from 1950 to 1960". The CPU 104 will recognize keywords related to this search and will search in the storage units 102, 103 for audio content related to the genre "Jazz" and being recorded in the period between "1950 and 1960". Such genre metadata and recording time metadata may be known or unknown by the device 100. When the user 107 uses metadata-related terms like genre "Jazz" or recording period "1950 to 1960" in her or his search query, this may be denoted as an "access" to the related metadata.

Moreover, the control unit 104 manages a manner of storing known metadata and main metadata by accessing and correspondingly controlling the storage devices 102, 103.

The control unit 104 also serves as a search entity coordinating or carrying out a search among the stored data, the search being based on one or more user-defined criteria which the user 107 may input via the user interface 105. The scheme according to which the known metadata and the unknown metadata is stored in the storage units 102, 103 will be explained below in more detail. The classification unit may classify the unknown metadata so that the storage unit 102 will store such unknown metadata separately from known metadata. For instance, the known metadata may be stored in a relational table, and the unknown data will be stored in a separate column. However, the unknown metadata is not processed before storage, but the unknown metadata will be stored in the raw format without any processing. Particularly, the unknown metadata may be stored in a separate table for overflow metadata, or in a separate column of a relational table. When it is detected by the system 100 that a user 107 desires access to the unknown metadata relatively frequently (that is to say more often than other unknown metadata, or more often than an average of known metadata, or more often than a predetermined threshold value), then the system 100 may reflect this obviously higher relevance of such unknown metadata items and may store these metadata items in another manner (for instance in another column) as compared to other unknown metadata items which are not accessed that frequently. Such a categorization may have effects on the further search strategy. For instance, a processing order or succession according to which different portions of the unknown/known metadata are queried during a search may be adapted based on the (updatable and thus dynamic) categorization "known metadata", "important unknown metadata", and "less important unknown metadata". Therefore, by this classification, a more efficient or less time-consuming retrieval of data from the database may be made possible, thus allowing to operate the system 100 with low computational burden and reduced computational resources.

For instance, such a search may be performed first based on known auxiliary data, then with unknown auxiliary data having an access frequency above the threshold value and after that based on the unknown metadata with a lower degree of relevance.

As can be taken from Fig. 1, the device 100 comprises a data interface 106 adapted for providing the device 100 with data, like the audio content data and/or corresponding metadata. The bidirectional data interface 106 is also capable of transmitting the audio data and/or the metadata to the destination devices 121, 120 which are connectable (in a wireless or wired manner) to the data interface 106. However, it is also possible to communicate between the devices 120, 121 and the device 100 in the other direction, that is to say to send audio data and/or corresponding metadata from one of the devices 120, 121 to the device 100. In case that unknown metadata is sent from one of the devices 120, 121 via the data interface 106 to the device 100, the classification unit 101 may classify such metadata into known and unknown metadata and may transmit the corresponding classification information also to the CPU 104. However, the CPU 104, instead of merely storing the metadata in the metadata storage unit 102 as known or unknown metadata, may also identify a class of an item of unknown metadata. For this purpose, the CPU 104 may detect whether an identifier is attached to a metadata packet sent from the units 120, 121. In such an identifier, a format of such (possibly unknown) metadata may be attached so that the CPU 104 may identify a class to which a corresponding metadata item belongs. Additionally or alternatively, the CPU 104 may send a request to one of the devices 120, 121 via the data interface 106 requesting such classification information. Upon receipt of such a request, the competent device 120 or 121 may then return an identification message to the CPU 104 including classification information for enabling the device 100 to classify the unknown metadata. Furthermore, it may happen that the device 100 is connected to a similar or identical device 100. In the configuration of Fig. 1, this would mean that the device 121 has a structure which is essentially equal to the structure of the device 100. In such a scenario, it may happen that the devices 100, 121 are of different versions or are from different manufacturers. That is to say, the metadata interpretation capability of the devices may differ. In order to allow a transfer of metadata between the devices 100 and 121, the CPU 104 may be capable of storing the metadata in the metadata storage device 102 together with order information indicative of an order according to which the metadata has been originally provided from a source 120 to the device 100. When such metadata is later sent from the device 100 to the device 121, it is possible to reconstruct the original order of transmission of the data from device 120 to the device 100. Therefore, problems occurring in a case in which interpretable metadata differ between the devices 100 and 121 may be prevented.

Furthermore, a user may query the databases 102, 103 under the control of the CPU 104. For instance, a user may generate a playlist based on her or his personal preferences, for instance to reproduce "Jazz music" from the period between "1950 and 1960". In accordance with such a playlist, which may be generated using the metadata stored in the device 102, the CPU 104 may find the corresponding audio data stored in the storage unit 103 for a reproduction via a loudspeaker 108. Thus, the loudspeaker may generate acoustic waves 109 which are audible for a human listener. However, the loudspeaker 108 may be substituted by earpieces, a headphone, or the like. It is also possible to have a plurality of loudspeakers 108.

In the following, referring to Fig. 2, a scheme 200 will be explained which shows an example of mapping an XML data file to a relational table. A portion 201 of Fig. 2 illustrates the layout of data in an XML document. A portion 202 of Fig. 2 illustrates an example of the layout of this data in a relational database management system (RDBMS).

Television content 203 is assigned to program information metadata 204 comprising a plurality of metadata items 205. When such an XML file is mapped into a relational database, the content of the individual metadata items 205 is reordered and placed in the table 206 comprising rows 207 and columns 208.

In the following, referring to Fig. 3 to Fig. 6, an implementation of the storage scheme distinguishing between known and unknown metadata according to an exemplary embodiment of the invention will be explained. To illustrate this exemplary embodiment of the invention, the following typical scenario will be considered.

The user 107 has a device 100 having a data management system 104 on board enhanced with the above-discussed classification and storage scheme (that is to say being able to cope with opaque data). This device 100 can be uploaded with music assets (that is to say downloaded via the Internet 122 or assets exchanged with another device like the USB stick 121, the server 120, etc.).

The device 100 also has a third party playlist generation application version 1, which generates music playlists based on genres. In that case, a fragment of the data scheme of the data management system 110 may look like the table 300 shown in Fig. 3. A headline 301 of the table 300 specifies metadata items 302, 303, 304, 305 and has furthermore an overflow column 306. In rows 307, 308, 309, various audio metadata items are shown which are stored in the device 100. For instance, the title of the song with the ID "1" is "Frozen" from the artist "Madonna" and belongs to the genre "Pop".

A typical query of a user 107 via the search unit 104 of the playlist generator version 1 could be "get all songs with genre Pop".

Fig. 4 shows a song table 400 of a remote device with additional fields 401 "BPM" and 402 "Rating".

At one time, the user acquired (downloaded, copied, etc.) songs shown in the rows 307, 308 of Fig. 4, which came with metadata describing the songs that have the structure of Fig. 4. Since the scheme of the user's device 100 does not know anything about the metadata classes "BPM" and "Rating", the data management system 104 copies the name value pairs for these fields to a separate "overflow field".

The database of the user's device will then look like the table 500 shown in Fig. 5 illustrating an overflow field 501.

After a while, the user 107 upgrades her or his playlists generation application to version 2. This version also takes "BPM" into account if the value for it is known. A typical query in that case would be "Get all songs with genre x or BPM y".

Since the data management system 100 is efficient, it first looks through the main attributes (that is to say ID, title 302, artist 303, album 304, genre 305) and then through the overflow field 501 to find values of the BPM attribute. Consequently, the user 107 does not need to upgrade the scheme, and all earlier obtained songs (for instance with the BPM) can now be retrieved for the playlist generator version 2.

Moreover, if the BPM field gets heavy traffic (for instance retrieved more frequently than main fields or above a certain daily threshold), the data management system 100 may decide to create a separate column (column 601 in the table 600 of Fig. 6) to speed up access to this field.

Therefore, Fig. 6 shows a song table 600 of the user's device 100 with automatically created BPM field 601. In the following, referring to Fig. 7A and Fig. 7B, an algorithm showing request handling in a traditional data management system (see Fig. 7A) and in an improved data management system according to an exemplary embodiment of the invention (see Fig. 7B) will be explained.

The flow-chart 700 of Fig. 7A starts with a begin block 701. In a block 702 the system gets a request from a user (that is to say get or set data). In a block 703, it is decided whether the request is in accordance with a scheme existing in a database.

If the result of this decision is yes, a get/set data block 704 is accessed and the data is retrieved in a data field 705. This data is returned to the system in a return data field 706, and the algorithm ends in a block 707. If the result of the decision in the field 703 is no, the system generates an

"invalid request" on no data signal in a corresponding block 708 and then continues with blocks 706 and 707.

In the following, the scheme 720 of Fig. 7B according to an exemplary embodiment of the invention will be explained. The begin 701 and get request 702 blocks are identical to Fig. 7A. Then, a block 721 is accessed checking whether the request is in accordance with a main schema. If the result of the decision is yes, a get/set data block 704 is accessed, and the data is returned via fields 705, 706 before the method ends in a block 707. However, if the result of the decision in block 721 is no, a get/set data from/to overflow table block 722 is accessed, and a field access counter is incremented in a block 723. In a block 724, it is detected whether the counter is larger than a threshold. If the result of the decision is yes, a block 725 is accessed for creating a field in a main table, moving data from an overflow table, and deleting the counter for this field. Then, the routine continues in steps 705 to 707.

If the result in block 724 is no, blocks 705 to 707 are directly accessed.

In the following, referring to Fig. 8 to Fig. 16, an implementation of a robust schema extension by an embedded extension identifier will be explained.

A personal mobile media server (which will be denoted as PiC in the following) stores songs. It has a nice description of those songs in its database. The local metadata record for a song contains common fields such as track name, album name, artist name, label, etc. The same songs are also stored on a PVR (personal video recorder), which uses the same metadata and therefore schema.

Fig. 8 shows a table 800 including metadata information ordered in rows 801, 802 and in columns 803 to 807.

At one time, the PiC is extended with headphones with a very sensitive embedded thermometer. On the PiC, a small driver is installed that records temperature variations of the ear and which song is being played. It is assumed that the variations are indicative of the effect the song has on the mood of the user. It uses a scale (e.g. relax, calm, normal, alert, agitated) to translate skin temperature to agitation level of the user (for instance 0 to 4). The agitation level a song causes most is recorded in the metadata record for that song.

Fig. 9 shows a table 900 having an additional column 901 in which the agitation level is stored. When the data is sent to another device, embedded in the value field is an extension identifier and the value.

Fig. 10 shows an extension identifier 1001 in a table 1000.

The PVR is still used to collect all songs in the AG-level is also communicated to the PVR. However, it does not have a concept of AG level. It does not appear in its schema. It puts the extra field in an overflow field (see overflow column 1101 in table 1100 of Fig. 11) so that a receiving DBMS would be able to identify the field in any case.

If a schema fragment was not sent (case A), the result will look as in table 1100 of Fig. 11 illustrating an overflow field 1101. If a schema fragment was sent (case B), the result will look like in table 1200 of Fig. 12 showing an overflow field 1201.

In the following, case A will be explained in more detail.

When the PiC queries the PVR for the AG level in the metadata records of the songs, it turns out the PVR does not know an AG level field. It does have some data in the overflow field though. Instead of returning nothing or an error, the PVR asks for the extension identifier. It is noted that the AG level may not be the only extension. Now the PiC sends the extension identifier and its schema for the requested record. The PVR compares to its own schema for the same record type and notices an extra field.

Such a scenario is shown in Fig. 13 illustrating a table 1300 having the extra field 1301.

It compares the extension identifier and discovers a match. The PVR updates a schema and adjusts its table, this may include removing the extension identifier from the value field.

A table 1401 is shown in Fig. 14 and comprises an AG-level field 1401. Referring to case B, a PiC queries the PVR for the AG level. The PVR has that field in the overflow field. To be sure both devices are talking about the same things the PVR sends the extension identifier. If they match, the data is sent from the overflow field. If they do not match, the answer is empty.

Fig. 15 shows a scheme describing a transmission of data between different devices.

According to this scheme, a device A adds fields in a block 1500. In a block 1510, the device A populates a record. In a block 1520, the record is sent to the device B, with an added extension identifier. In a block 1530, the device B stores the full content of the unknown fields in an overflow field. In a block 1540, the device B sends core fields if queried. In a block 1550, the device C requests extension by identifier. In a block 1560, the device B sends content extension if the extension identifier matches.

In the following, referring to Fig. 16, another scheme of a transmission of data between different devices will be explained. In a block 1600, a device A adds fields. In a block 1610, the device A populates a record. In a block 1620, the record is sent to the device B. In a block 1630, the device B stores column number and content of unknown fields in an overflow field. In a block 1640, the device B reconstitutes original record if queried. In a block 1650, a device C interprets records, and discards face column.

In the following, referring to Fig. 17 to Fig. 25, an exemplary embodiment of the invention related to transparent record reconstitution will be explained.

A PVR stores songs. Content analysis techniques are available on this box to extract keywords from audio for search purposes. These techniques may be used to index video but can also be applied to lyrics to locate specified songs. Also available is face recognition for identification and audio fingerprinting. Thus, the PVR can identify people that feature in the video clip connected to an audio track.

Next to common fields such as track name, album name, artist name, label, etc., the local metadata record for a song contains the five most common extracted keywords from the lyrics of the song, and the most prominent person of which the face was detected in the video clip.

A corresponding table 1700 is plotted in Fig. 17 and includes, in addition to already defined features, a keyword column 1701, a fingerprint ID column 1702 and a face column 1703. A song is transferred to a personal mobile media server (PiC). The PiC does not recognize the keyword and face fields. They are stored in an overflow field with their locations in the original record.

If a scheme fragment was sent, this would look like table 1800 of Fig. 18 including an overflow column 1801. If no schema fragment was sent, this would look like table 1900 of Fig. 19 including an overflow field 1901.

At a friend's house, the PiC may be connected to a multimedia server (eHub) there. The songs are transferred and the metadata record for that song is also transferred. The PiC uses the data in the overflow field and overflow order to reconstitute the original record. A corresponding table 2000 is shown in Fig. 20.

The eHub does know the keyword feature and audio fingerprints, but has no concept of the face detection. It happens not to use overflow fields, see table 2100 of Fig. 21. Thus, this feature can be used to carry metadata from one device to another device via an intermediate device that does not use or understand the data it is carrying. If it is desired to reconcile concurrent evolution of the core schema that occurred on different locations (devices) in a consistent manner, it might be necessary to have a rule to desire which field gets which column.

Fig. 22 illustrates a table 2200 including core information. Two extensions with respect to the core may be defined, as illustrated in Fig.

23 as table 2300 and in Fig. 24 as table 2400.

Table 2500 of Fig. 25 describes the result.

A simple thing to do is just ignore this, that is to say keep sending the original records and accepting that the extended fields are inconsistent, and let the application handle it. Other possibilities include:

1. having a variant marker in an extra field signaling the receiver that there are different variants of this record,

2. cutting the overflow field after all,

3. sending a separate table for each variant, 4. just include the overflow field as is.

A more comprehensive solution would be to include a creation time stamp in the fieldname of extensions and order the extensions on time.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be capable of designing many alternative embodiments without departing from the scope of the invention as defined by the appended claims. Furthermore, any of the embodiments described comprise implicit features, such as, an internal current supply, for example, a battery or an accumulator. In the claims, any reference signs placed in parentheses shall not be construed as limiting the claims. The word "comprising" and "comprises", and the like, does not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. The singular reference of an element does not exclude the plural reference of such elements and vice- versa. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The terms "data" and "content" have been used interchangeably through the text, but are to be understood as equivalents.

Claims

CLAIMS:

1. A device (100) for managing auxiliary data assigned to main data, wherein the device (100) comprises a classification unit (101) adapted to classify auxiliary data into known auxiliary data and into unknown auxiliary data; a storage unit (102, 103) adapted to store auxiliary data classified by the classification unit (101) as unknown auxiliary data; a management unit (104) adapted to manage a manner of storing the auxiliary data classified by the classification unit (101) as unknown auxiliary data based on a number of accesses to the auxiliary data classified by the classification unit (101) as unknown auxiliary data.

2. The device (100) according to claim 1, adapted to manage metadata as the auxiliary data.

3. The device (100) according to claim 1, adapted to manage auxiliary data assigned to the main data, the main data comprising at least one of the group consisting of audio content, image content, video content and multi-media content.

4. The device (100) according to claim 1, comprising a search unit (104) adapted to search the main data based on at least one user-defined criteria being related to the auxiliary data.

5. The device (100) according to claim 1, wherein the classification unit (101) is adapted to classify auxiliary data into known auxiliary data and into unknown auxiliary data based on whether a format of the auxiliary data is interpretable by the device (100).

6. The device (100) according to claim 1, wherein the storage unit (102, 103) is adapted to store auxiliary data classified by the classification unit (101) as known auxiliary data in a separate manner as compared to the auxiliary data classified by the classification unit (101) as unknown auxiliary data.

7. The device (100) according to claim 1, wherein the storage unit (102, 103) is adapted to store auxiliary data classified by the classification unit (101) as unknown auxiliary data without modifying a format of the unknown auxiliary data.

8. The device (100) according to claim 1, wherein the storage unit (102, 103) is adapted to store auxiliary data classified by the classification unit (101) as unknown auxiliary data in a separate portion of a relational table or in a separate table for overflow auxiliary data.

9. The device (100) according to claim 1, wherein the management unit (104) is adapted to manage a manner of storing the auxiliary data classified by the classification unit (101) as unknown auxiliary data based on an access frequency of the auxiliary data classified by the classification unit as unknown auxiliary data.

10. The device (100) according to claim 1, wherein the management unit (104) is adapted to modify a manner of storing auxiliary data classified by the classification unit (101) as unknown auxiliary data in case that the number of accesses to the auxiliary data classified by the classification unit (101) as unknown auxiliary data exceeds a predetermined threshold value.

11. The device (100) according to claims 4 and 10, wherein the search unit (104) is adapted to search in accordance with a search order, the search order being based on the manner of storing the auxiliary data classified by the classification unit (101) as unknown auxiliary data.

12. The device (100) according to claims 4 and 10, wherein the search unit (104) is adapted to search in accordance with a search order starting to search the auxiliary data classified by the classification unit (101) as known auxiliary data, continuing to search the auxiliary data stored in the modified manner, and finishing to search the auxiliary data classified by the classification unit (101) as unknown auxiliary data and not being stored in the modified manner.

13. The device (100) according to claim 1, comprising a user interface (105) adapted for a unidirectional or bidirectional communication of a user with the device (100).

14. The device (100) according to claim 1, comprising a data receipt interface (106) adapted for receiving main data and/or auxiliary data from a source device (120, 121) connected or connectable to the data interface (106).

15. The device (100) according to claim 1, comprising a data transmission interface (106) adapted for transmitting main data and/or auxiliary data to a destination device (120, 121) connected or connectable to the data interface (106).

16. The device (100) according to claim 1, comprising a class identification unit (104) adapted to identify a class of auxiliary data classified by the classification unit (101) as unknown auxiliary data.

17. The device (100) according to claim 14 and 16, wherein the class identification unit (104) is adapted to identify the class by requesting, from the source device (120, 121) having transmitted the unknown auxiliary data, transmission of a classification identifier for the unknown auxiliary data indicative of the class.

18. The device (100) according to claim 14 and 16, wherein the class identification unit (104) is adapted to identify the class based on a classification identifier attached to the unknown auxiliary data by the source device (120, 121) having transmitted the unknown auxiliary data, the classification identifier being indicative of the class.

19. The device (100) according to claim 16, wherein the management unit (104) is adapted to manage a manner of storing the auxiliary data classified by the classification unit (101) as unknown auxiliary data based on the identified class.

20. The device (100) according to claim 1 and 14, wherein the management unit (104) is adapted to manage the storing of auxiliary data classified by the classification unit (101) as unknown auxiliary data and of auxiliary data classified by the classification unit (101) as known auxiliary data by additionally storing order information indicative of an order according to which the auxiliary data has been provided from the source device (120, 121).

21. The device (100) according to claim 20, wherein the management unit (104) is adapted to manage transmission of stored auxiliary data to a destination device (120, 121) in a manner that the destination device (120, 121) receives the stored auxiliary data together with the order information so as to allow the destination device (120, 121) to store the transmitted stored auxiliary data in the order according to which the auxiliary data has been transmitted originally from the source device (120, 121) to the device (100).

22. The device (100) according to claim 1, realized as a consumer electronics device.

23. The device (100) according to claim 1, realized as at least one of the group consisting of an electronic hub; a set top box; a personal video recorder; a mobile personal server; a multimedia server; a digital video recording device; a network-enabled device; a conditional access system; a portable audio player; a portable video player; a mobile phone; a DVD player; a CD player; a hard disk based media player; an Internet radio device; a computer; a television; a public entertainment device; and an MP3 player.

24. A method of managing auxiliary data assigned to main data, the method comprising classifying auxiliary data into known auxiliary data and into unknown auxiliary data; storing auxiliary data which has been classified as unknown auxiliary data; managing a manner of storing the auxiliary data which has been classified as unknown auxiliary data based on a number of accesses to the auxiliary data which has been classified as unknown auxiliary data.

25. A computer-readable medium, in which a computer program of managing auxiliary data assigned to main data is stored, which computer program, when being executed by a processor (100), is adapted to control or carry out a method of classifying auxiliary data into known auxiliary data and into unknown auxiliary data; storing auxiliary data which has been classified as unknown auxiliary data; managing a manner of storing the auxiliary data which has been classified as unknown auxiliary data based on a number of accesses to the auxiliary data which has been classified as unknown auxiliary data.

26. A program element of managing auxiliary data assigned to main data, which program element, when being executed by a processor (100), is adapted to control or carry out a method of classifying auxiliary data into known auxiliary data and into unknown auxiliary data; storing auxiliary data which has been classified as unknown auxiliary data; managing a manner of storing the auxiliary data which has been classified as unknown auxiliary data based on a number of accesses to the auxiliary data which has been classified as unknown auxiliary data.