Media mediator system and method for managing contents of various formats

Provided is a system and method that may encode various formats of contents to a single format and thereby manage the contents, and may transform the contents to a format corresponding to a request of a third party or an end user to distribute the content. A media mediator system of managing various formats of contents may include: a service manager to receive a content and metadata of the content from a content provider; a metadata manager to register the content using the metadata, and to store the metadata of the registered content; a database manager to store and manage information associated with the content; and an encoding manager to schedule an encoding sequence of the content, and to sequentially encode the content based on a scheduling result.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of Korean Patent Application No. 10-2009-0082472, filed on Sep. 2, 2009, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention relates to a system and method that may encode various formats of contents to a single format and thereby manage the contents, and may transform the contents to a format corresponding to a request of a third party or an end user to distribute the contents.

2. Description of the Related Art

In a conventional content providing service using a network, when various content providers provide contents to a service provider using a different platform, the service provider may provide the contents to an end user using the same platform as the platform of the service provider.

However, when a content desired by the end user is provided by only another service provider using a platform not owned by the end user, the end user may need to purchase a device or a system using the corresponding platform, or abandon efforts to receive the content.

The service provider or the content provider may be limited to providing contents to only a number of end users using the corresponding platform, and thus may have limited revenues or limited advertising effect with respect to providing of contents.

Accordingly, there is a need for a system and method that may provide contents to all end users without restrictions on a type of a platform used by a service provider or a type of platform used by a content provider for a content creation.

SUMMARY

An aspect of the present invention provides a system and method that may upload contents from a plurality of service providers and content providers using different platforms, and transform the uploaded contents to a single platform to thereby provide all end users with the contents transformed to the single platform, and thus enable all the end users to receive a content provided by a service provider using a different platform.

Another aspect of the present invention also provides a system and method that may transform an uploaded content to a platform desired by another service provider and then provide the other service provider with the content transformed to the desired platform and thereby may easily increase a number of target users to receive the content.

Another aspect of the present invention also provides a system and method that may enable a system side to periodically verify and upload a content of a content provider, and thereby may enable the content provider to provide the content without a separate uploading process.

According to an aspect of the present invention, there is provided a media mediator system of managing various formats of contents, including: a service manager to receive a content and metadata of the content from a content provider; a metadata manager to register the content using the metadata, and to store the metadata of the registered content; a database manager to store and manage information associated with the content; and an encoding manager to schedule an encoding sequence of the content, and to sequentially encode the content based on a scheduling result.

According to another aspect of the present invention, there is provided a method of managing various formats of contents, the method including: setting, by an end user, a format of the content desired by the end user; receiving, by a service manager, a content and metadata of the content from a content provider; registering, by a metadata manager, the content and the metadata of the content to a database manager; encoding, by an encoding manager, the content; and providing, by the service manager, the encoded content to the end user.

According to embodiments of the present invention, it is possible to provide all end users with contents uploaded from a plurality of service providers and content providers using different platforms, and transformed to a single platform, and thus to enable all the end users to receive a content provided by a service provider using a different platform by uploading the contents, and transforming the uploaded contents to the single platform.

According to embodiments of the present invention, it is possible to easily increase a number of target users to receive a content by transforming an uploaded content to a platform desired by another service provider and then providing the other service provider with the content transformed to the desired platform.

According to embodiments of the present invention, it is possible to enable a content provider to provide a content without a separate uploading process by enabling a system side to periodically verify and upload the content of the content provider.

DETAILED DESCRIPTION

According to embodiments of the present invention, in a system of providing contents to end users over a network such as an Internet Protocol Television (IPTV), it is possible to provide the end users with contents created by content providers by automatically uploading the contents at predetermined intervals, and by transforming various formats of the uploaded contents to a single format.

In addition, when a third party desires to provide a content using a different format, an uploaded content may be transformed to the different format and be provided to the third party. Accordingly, it is possible to easily increase a content target scope.

FIG. 1is a diagram illustrating a relationship among users associated with a service release information platform110for an IPTV.

The service release information platform110for the IPTV may be commonly used by a content provider120to provide a content broadcasted by the IPTV, a service provider130to manage the content and to provide the content to an end user150, and a network provider140. The network provider140may provide a network to transmit the content provided by the service provider130to the IPTV owned by the end user150.

FIG. 2is a diagram illustrating an example of applying a system of managing various formats of contents (hereinafter, “contents managing system”) according to an embodiment of the present invention.FIG. 3is a diagram illustrating a comparison between a conventional service providing system310and a contents managing system320according to an embodiment of the present invention.

As shown inFIG. 2, in the contents managing system, a broker service provider230may collectively manage contents of content providers210maintained by service providers220, and may provide contents to an end user250over a network provided by a network provider240.

As shown inFIG. 3, in the conventional service providing system310, when various content providers311provide contents to service providers312,313, and314using different platforms, each of the service providers312,313, and314may provide contents to an end user using the same platform as a platform of a corresponding service provider.

For example, an end user using an Application Configuration Access Protocol (ACAP) platform may not receive a content provided using only an Association of Radio Industries and Businesses (ARIB) platform.

In the contents managing system320according to an embodiment of the present invention, a broker service provider230may upload contents from content providers210and service providers321,322, and323using different platforms, transform the contents to a single platform and then provide the contents to an end user250. Accordingly, the end user250may receive a content provided from a service provider using a platform different from a platform of the end user250.

InFIG. 3, the broker service provider230transforms a content to a web platform that is a most easily accessible environment, and then provides the content to the end user250.

Also, it is possible to transform an uploaded content to a platform desired by another service provider, and to thereby provide the uploaded content to the other service provider.

FIG. 4is a block diagram illustrating a configuration of a contents managing system according to an embodiment of the present invention.

As shown inFIG. 4, in the contents managing system, a broker service provider230may include an aggregator410, a media mediator420, a syndication portal430, and a media farm440.

The aggregator410may periodically verify whether an added content exists in a feed of a content provider, and upload the added content when the added content exists.

Here, the feed may denote a share-set folder for uploading in a content provider terminal210, or may denote an address accessible to a site based on address information provided from the syndication portal430or to a content provided from the content provider.

The aggregator410may verify whether the added content exists only with respect to a published content of the content provider.

A configuration of the aggregator410will be further described with reference toFIG. 5.

The media mediator420may register the uploaded content, encode the content, and provide the encoded content to an end user or a third party.

The media mediator420may exclusively access the content provider terminal210to receive the content and metadata of the content from the content provider, register the received content, encode the content, and provide the encoded content to the end user.

A configuration of the media mediator420will be further described with reference toFIGS. 6 through 10.

The syndication portal430may register a content provider desiring to provide a content in the contents managing system, and may transmit, to the content provider, a Universal Resource Locator (URL) for a feed and a content metadata format to be used for a content creation.

The syndication portal430may provide a content transformed to a format used by a third party to the third party that receives the content registered in the contents managing system to provide the received content to an end user using a platform different from a platform of the contents managing system. In this instance, a terminal of the third party receiving the content transformed to the format used by the third party may be referred to as a third party terminal470.

A configuration of the syndication portal430will be further described with reference toFIG. 11.

The media farm440may store the uploaded content, and may provide the stored content to the end user according to a control of the media mediator420.

The media farm440may include a web application server to provide an access site of the end user, a file transfer server to transfer a content to the end user, a window media server to execute the content on a website, and a content storage unit to store the content.

FIG. 5is a block diagram illustrating a configuration of the aggregator410ofFIG. 4.

As shown inFIG. 5, the aggregator410may include a feed listener510, a feed transmission unit520, an uploader530, a temporary content storage unit540, a content collector550, and a content transmission unit560.

The feed listener510may interpret a published format of a content from an original source of the content provider terminal210in order to receive the content from the content provider terminal210.

The feed transmission unit520may transmit metadata of the content to the media mediator420to be assigned with a unique identifier (ID) with respect to the content, may schedule uploading of the content, and may execute the uploader530to upload the content.

The uploader530may upload the content from a feed of the content provider terminal210and store the uploaded content in the temporary content storage unit540. The uploader530may use, for example, a direct upload Application Programming Interface (API).

The temporary content storage unit540may temporarily store the content until the content is transmitted to the media mediator420.

When contents are temporarily stored in the temporary content storage unit540by an operation of the aggregator410, the content collector550may collect at least one content stored in the temporary content storage unit540.

The content transmission unit560may transmit the collected at least one content to the media mediator420.

Describing an operation of the aggregator410in detail, when the feed listener510receives metadata of the content from the feed of the content provider terminal210, the feed transmission unit520may analyze the metadata to register an uploader ID for identifying the content provider providing the content, and may request the media mediator420for a content unique ID for identifying the content.

The feed transmission unit520may transmit the metadata to the media mediator420, and upload the content from the feed of the content provider terminal210to the uploader530, and may store the uploaded content in the temporary content storage unit540.

When the feed transmission unit520receives the content unique ID from the media mediator420, the content collector550may collect a corresponding content stored in the temporary content storage unit540, and the content transmission unit560may transmit the collected content to the media mediator420.

FIG. 6is a block diagram illustrating a configuration of the media mediator420ofFIG. 4.

As shown inFIG. 6, the media mediator420may include a service manager610, a metadata manager620, a database manager630, and an encoding manager640.

The serving manager610may receive a content from the aggregator410, and request another constituent component such as the metadata manager620, the database manager630, and the encoding manager640for operations associated with the content.

A configuration of the service manager610will be further described with reference toFIG. 7.

The metadata manager620may generate a unique ID from metadata of the content, register the unique ID to the syndication portal430, transmit the unique ID to the aggregator410, and transform the metadata to a schema suitable for a contents managing system, and store the transformed metadata.

A configuration of the metadata manager620will be further described with reference toFIG. 8.

The database manager630may store and manage information associated with the content.

A configuration of the database manager630will be further described with reference toFIG. 9.

The encoding manager640may schedule an encoding sequence of the content, and sequentially encode the content into a format corresponding to the contents managing system.

A configuration of the encoding manager640will be further described with reference toFIG. 10.

FIG. 7is a block diagram illustrating a configuration of the service manager610ofFIG. 6.

As shown inFIG. 7, the service manager610may include a register service unit710, a select service unit720, and an update service unit730.

The register service unit710may sequentially control configurations required during a process of registering a content uploaded from a feed. Also, the register service unit710may control a process of registering the content received from the content provider.

The select service unit720may sequentially control configurations required during a process of transforming metadata of the content to a format employed by the contents managing system, and using the transformed metadata in a service.

When a request for modifying the metadata of the content is received from the syndication portal430, the update service unit730may modify the metadata of the content stored in the database manager630.

FIG. 8is a block diagram illustrating a configuration of the metadata manager620ofFIG. 6.

As shown inFIG. 8, the metadata manager620may include an orchestrator810, a rule storage unit820, a rule manager830, a rule loader840, an editor850, a reverse rule manager860, and a reverse orchestrator870.

The orchestrator810may orchestrate metadata of a content based on a rule stored in the rule storage unit820.

The rule storage unit820may store a rule set by a content provider or a third party. The rule may include information associated with a particular standard and a format or a platform of the content used by the content provider or the third party, and a metadata format of the content.

The rule manager830may transmit a particular condition to the rule loader840according to a request of the syndication portion430so that the rule loader840may retrieve an edition target rule satisfying the particular condition, and may transmit the edition target rule to the editor850.

The rule loader840may retrieve, from the rule storage unit820, a rule satisfying the particular condition, and may transmit the retrieved rule to the rule manager830.

The editor850may execute a jamper to edit the edition target rule according to a request of the third party connected to the syndication portal430or to the media mediator420.

The reverse rule manager860may receive the edited rule from the editor850, and transmit the edited rule to the rule storage unit820and syndication portal430to store the edited rule.

The reverse orchestrator870may orchestrate metadata of the content based on the edited rule.

FIG. 9is a block diagram illustrating a configuration of the database manager630ofFIG. 6.

As shown inFIG. 9, the database manager630may include an inserter910, a metadata storage unit920, a formatter930, an encoding rule loader940, an updater950, a selector960, and a reverse formatter970.

The inserter910may receive orchestrated metadata of a content from the service manager610, store the orchestrated metadata of the content in the metadata storage unit920, and request the syndication portal430to register the content containing the orchestrated metadata.

The metadata storage unit920may store metadata of the content and information associated with the content.

Information associated with the content may include at least one of a Uniform Resource Identifier (URI) string for identifying the content, basic content information including a content title or a content creator, information associated with a marker indicated at a play point when the content corresponds to a media content, information regarding a content credit and a plurality of media link addresses. The metadata of the content may include an encoding rule to encode the content.

The formatter930may transform the orchestrated metadata to a method schema used in the metadata storage unit920. The method schema may include, for example, a Structured Query Language (SQL) query string.

The encoding rule loader940may extract the encoding rule from the stored metadata to provide the extracted encoding rule to the encoding manager640.

The updater950may update, to the metadata storage unit620, an access path to the encoded content and an access path to a thumbnail extracted from the content.

The selector960may retrieve metadata of the content from the metadata storage unit920according to a request of the service manager610, transmit the retrieved metadata to the reverse formatter970to transform the metadata, and may request the metadata manager620for reverse orchestrating of the metadata.

The reverse formatter970may transform the metadata of the content to an Extensible Markup Language (XML) format managed by the syndication portal430.

FIG. 10is a block diagram illustrating a configuration of the encoding manager640ofFIG. 6.

As shown inFIG. 10, the encoding manager640may include a receiver1010, a scheduler1020, an encoder1030, and a thumbnailer1040.

The receiver1010may periodically receive, from the syndication portal430, a content list uploaded by the aggregator410, and change content status information included in the received content list to “received”.

The content status information included in the content list may be stored in the syndication portal430.

When the media mediator420is exclusively used, the content status information may be stored in the database manager630. Accordingly, when the media mediator420is exclusively used and the content status information needs to be changed, the content status information stored in the database manager630may be changed instead of changing the content status information stored in the syndication portal430.

In this instance, the receiver1010may periodically verify a content list received from the content provider, stored in the database manager630, and may change, to “received”, content status information included in the verified content list.

The scheduler1020may periodically receive, from the syndication portal430, a list of contents that are in a “received” status, and receive, from the metadata manager620, a rule to encode the contents being in the received status, and transmit the encoded contents and the rule to the encoder1030to request the encoder103for encoding of the content being in the received status.

The scheduler1020may transmit, to the thumbnailer1040, the contents being in the received status to extract a thumbnail.

The scheduler1020may also transmit, to the updater950, an access path to the encoded contents and an access path to the extracted thumbnail.

The encoder1030may receive, from the scheduler1020, the contents being in the received status and the rule to encode the contents, and encode the contents based on the received rule. When encoding is completed, the encoder1030may change the content status information to “encoding complete”.

The thumbnailer1040may receive, from the scheduler1020, the contents being in the received status, and extract the thumbnail from the contents.

FIG. 11is a block diagram illustrating a configuration of the syndication portal430.

As shown inFIG. 11, the syndication portal430may include a system database1110, a service operator interface1120, a content provider interface1130, and a third party interface1140.

The system database1110may store content status information, feed information, content provider information, third party information, end user information receiving the content, and content use status information.

The content status information may include at least one of a URI string for identifying the content, basic content information including a content title and a content creator, information associated with a marker indicated at a play point when the content corresponds to a media content, information regarding a content credit, a plurality of media link addresses of the link, and a right to the content, and information associated with a content price or a contract.

The content provider information, the third party information, and the end user information may include at least one of an ID, a password, a name, a height, a language, and a subscribed date with respect to a target user, and ID information indicating which one the target user belongs among the content provider, the third party, and the end user.

The feed information may include at least one of an ID of a content provider owning a corresponding feed, ID information of the feed, initial address information of a metadata list of a content created by the content provider, and status information of the feed.

The system database1110may further store information associated with events having a possibility of occurring in the syndication portal430, information associated with an event solution scheme, and information associated with a type of the content provided for the end user and a provided time.

The service operator interface1120may manage content status information and content provider information, and may register the content provider, the third party, and the end user.

The service operator interface1120may identify an end user connected to the contents managing system, based on an ID of the end user, and may recommend a content suitable for the end user based on types of contents provided for the user and provided times.

The service operator interface1120may include a feed upload managing function of the content provider, and may utilize a block function by referring to the contents.

The service operator interface1120may manage information, alarms, and events occurring in a constituent component different from the syndication portal430.

The content provider interface1130may provide the content provider with an upload status, an issue status, and a use status with respect to a content desired by the content provider.

The third party interface1140may provide information associated with the content registered to the third party holding the third party terminal470, and may transform and provide a format of the registered content according to a request of the third party.

FIG. 12is a flowchart illustrating a method of managing various formats of contents according to an embodiment of the present invention.

In operation S1210, the syndication portal430may register a content provider desiring to provide a content according to a request of the content provider.

In this instance, the syndication portal430may transmit, to the content provider, a URL for a feed and a metadata format to be used for content creation.

The content provider registration process will be further described with reference to FIG.13.

In operation S1220, the aggregator410may periodically inspect a feed of each of registered content providers.

In operation S1230, the aggregator410may verify whether an added content exists in the inspected feed. When the added content does not exist in operation S1230, the aggregator410may repeat operation S1220.

Conversely, when the added content exists in operation S1230, the aggregator410may upload the added content from the feed, and request the media mediator420to register the added content in operation S1240.

The content verifying and uploading process corresponding to operations S1220through S1240will be further described with reference toFIG. 14.

In operation S1250, the media mediator420may register the requested added content.

The content registration process will be further described with reference toFIG. 15.

In operation S1260, the media mediator420may encode the registered added content to a format suitable for the contents managing system.

The encoding process will be further described with reference toFIG. 16.

In operation S1270, the media mediator420may provide the encoded content to an end user or a third party.

In this instance, the media mediator420may transform the encoded content to a format set by the end user or the third party, and thereby provide the transformed content.

The format setting process will be further described with reference toFIG. 17, and the encoded content changing and providing process will be further described with reference toFIG. 18.

FIG. 13is a diagram illustrating a process of registering a content provider according to an embodiment of the present invention.

When the syndication portal430receives a subscription request signal from the content provider terminal210in operation1310, the syndication portal430may generate an ID and a password of the content provider based on the subscription request signal, and may store the ID and the password in the media farm440in operation1320. In this instance, the syndication portion430may generate subscription information including the ID and the password of the content provider, and information associated with the content provider.

The syndication portal430may receive the subscription request signal from the content provider terminal210via a webpage provided from the service operator interface1120. The syndication portal430may generate the subscription information using a service layer containing the system database1110and the service operator interface1120.

In operation1330, the syndication portal430may generate a key corresponding to the ID and the password of the content provider. In operation1340, the syndication portal430may transmit the ID and the password of the content provider and the key to request an execution of a log-in process.

In this instance, the syndication portal430may generate a corresponding key based on the ID of the content provider and a current time, and may store the generated key in the system database1110. When a particular situation occurs while generating the key, the syndication portal430may process the particular situation by transmitting and receiving information to and from the system database1110.

When the content provider attempts to log in the content in operation1350, the syndication portal430may compare an ID and a password received from the content provider terminal210with the ID and the password stored in the system database1110, and verify the information in operation1360, and may provide the content provider with a main page to utilize the service operator interface1120or the content provider interface1130in operation1380.

In this instance, the syndication portal430may verify information changed in the system database110and update the information in operation1370, and then may provide the content provider with the main page.

FIG. 14is a diagram illustrating a process of verifying and uploading a content according to an embodiment of the present invention.

In operation1410, a content may be prepared in a feed of the content provider terminal210. In this state, when the aggregator410attempts content polling with respect to address information of the feed, the aggregator410may detect the content in operation1420.

In operation1430, the aggregator410may upload metadata of the content from the feed of the content provider terminal210. The aggregator410may analyze the uploaded metadata to obtain address information of the content and content information in operation1440.

In operation1450, the aggregator410may register, to the media mediator420, an uploader ID for identifying the content provider providing the content, and may request the media mediator420for a content unique ID for identifying the content.

In operation1455, the aggregator410may transmit uploaded metadata to the media mediator420.

In operation1460, the media mediator420may receive the metadata to register the content.

In operation1470, the aggregator410may upload the content from the feed of the content provider terminal210.

In operation1480, the media mediator420may transmit, to the aggregator410, the content unique ID generated during a content registration process.

In operation1490, the aggregator410receiving the content unique ID may transmit the content to the media mediator420, periodically perform polling with respect to the feed of the content provider terminal210, and transmit collected contents to the media mediator420.

FIG. 15is a diagram illustrating a process of registering a content according to an embodiment of the present invention.

When the aggregator410transmits the content, uploaded in operation S1250, to the service manager610of the media mediator420(1510), the register service unit710of the service manager610may request the orchestrator810of the metadata manager620to transform metadata of the content (1520). In this instance, the orchestrator810may transform a format of the metadata to a format used in the contents managing system, for example, to a cans_rss format.

The orchestrator810may retrieve, from the rule storage unit820according to a request of the register service unit710, a rule to transform metadata of the content provider providing the content (1525). The orchestrator810may orchestrate the metadata of the content based on the retrieved rule (1530).

Specifically, the orchestrator810may orchestrate an XML of the metadata to an XML format used in a web-base IPTV middleware, and may transmit the orchestrated metadata to the register service unit710.

The register service unit710may transmit the orchestrated metadata to the inserter910of the database manager630to request a content registration (1540).

The inserter910may transmit the orchestrated metadata to the formatter930to transform the orchestrated metadata to a method schema used in the metadata storage unit920(1545).

The inserter910may transmit the content containing the orchestrated metadata to the syndication portal430to register the content (1550). The inserter910may store the orchestrated metadata in the metadata storage unit920(1555).

When the inserter910transmits, to the register service unit710, a content list managing registered contents (1560), the register service unit710may return the received content list to the aggregator410(1570).

FIG. 16is diagram illustrating an encoding process according to an embodiment of the present invention.

The encoding manager640may share contents with the media farm440using a network file system. The encoder1030and the thumbnailer1040may access contents stored in the media farm440without restrictions.

The receiver1010may periodically receive, from the syndication portal430, a list of contents uploaded by the aggregator410, and may change content status information included in the content list to “received” (1610).

The scheduler1020may periodically receive, from the syndication portal430, a list of contents being in a received status to determine an encoding sequence, and change content status information of a content to be encoded to “encoding” (1620).

The scheduler1020may request the encoding rule loader940for an encoding rule, and the encoding rule loader940may extract, from content metadata, an encoding rule corresponding to the content being in the received status, and may provide the extracted encoding rule to the scheduler1020(1630).

The scheduler1020may transmit the content being in the received status and the encoding rule to the encoder1030to request an encoding (1640).

In this instance, the encoder1030may encode the received content being in the received status, based on the encoding rule. When encoding is completed, the encoder1030may transmit the encoded content to the scheduler1020. Also, the encoder1030may provide an encoding progress rate to the syndication portal430periodically during the encoding process (1650).

For example, the encoder1030may encode the content being in the received status using FFMpeg.

The scheduler1020may transmit the content being in the received status to the thumbnailer1040to request the thumbnailer1040for extracting a thumbnail (1660).

In this instance, the thumbnailer1040may extract the thumbnail from the content being in the received status using FFMpeg, and transmit the extracted thumbnail to the scheduler1020.

The scheduler1020may transmit, to the updater950, an access path to the encoded content and an access path to the extracted thumbnail (1670).

The updater950may update, to the metadata storage unit920, the access path to the encoded content and the access path to the extracted thumbnail (1680).

FIG. 17is a diagram illustrating a process of setting, by an end user or a third party, a format according to an embodiment of the present invention.

When the syndication portal430approaches the rule manager830of the media mediator620to request a format setting according to a request of a content provider (1710), the rule manager830may transmit a particular condition to the rule loader840according to a request of the syndication portal430so that the rule loader840may retrieve a rule to be edited, satisfying the particular condition (1720).

The rule loader840may retrieve, from the rule storage unit820, a rule satisfying the particular condition (1730), and may transmit the retrieved rule to the rule manager830(1740).

The rule manager830may transmit, to the editor850, the rule received from the rule loader840(1750).

The editor850may edit the rule according to the request of the end user or the third party connected to the syndication portal430. When the edition is completed, the editor850may transmit the edited rule to the reverse rule manager860(1760).

For example, the editor850may edit the rule using a jamper.

The reverse rule manager860may store the edited rule in the rule storage unit820(1770), and transmit the edited rule to the syndication portal430for a registration (1780). Through this, it is possible to terminate a setting process of a corresponding tool.

FIG. 18is a diagram illustrating a process of changing and providing an encoded content according to an embodiment of the present invention.

When the syndication portal430receives, from an end user or a third party, a request for a content satisfying a particular condition, the syndication portal430may request the select service unit720of the service manager610for information associated with the content (1810).

The select service unit720may request the selector960of the database manager630for content information (1820). The selector960may retrieve the content information from the metadata storage unit920(1830).

The selector960may transmit the content information to the reverse formatter970to transform the content information to an XML format managed by the syndication portal430(1840), and may request the reserve rule manager860of the metadata manager620for a reverse transformation (1850).

In this instance, the metadata transformed to the XML format by the reverse formatter970may be transmitted as metadata of the content to the third party terminal470according to a request of the third party.

For example, the reverse formatter970may transform the content information to an XML format used over an IPTV middleware.

The reverse rule manager860may retrieve, from the rule storage unit820according to a reverse transformation request, the rule edited by the end user or the third party (1860), and may transmit the edited rule to the select service unit720via the selector960(1870,1880).

The select service unit720may transmit the edited rule to the syndication rule430(1890). The syndication portal430may request the encoding manager640to encode the content using the edited rule, and to transform the content to a format suitable for the end user or the third party. When the content transformed to the suitable format is transmitted from the encoding manager640, the syndication portal430may provide the transformed content to the end user or the third party.

FIG. 19is a diagram illustrating a process of managing, by the syndication portal430, a feed according to an embodiment of the present invention.

When the syndication portal430receives a feed list request signal from the content provider terminal210in operation1910, the syndication portal430may load feeds, stored in the system database1110, according to the feed list request signal to obtain a feed list in operation1920. In operation1930, the syndication portal430may provide a content provider with the feed list and a main page so that the content provider may utilize the service operator interface1120or the content provider interface1130.

When the syndication portal430receives a feed update request signal from the content provider terminal210in operation1940, the syndication portal430may generate a feed based on the feed update request signal to add the feed to the system database1110in operation1950, or may delete the feed from the system database1110in operation1960.

In operation1970, the syndication portal430may provide the content provider with a feed update result and the main page, so that the content provider may utilize the service operator interface1120or the content provider interface1130.

FIG. 20is a diagram illustrating a process of setting or modifying a metadata format of a content in a contents managing system according to an embodiment of the present invention.

When the syndication portal430receives, from the content provider terminal210, a rule generation signal to generate a rule, or a rule modification signal to modify a rule stored in the rule storage unit820in operation2010, the syndication portal430may verify user information stored in the system database1110according to the rule generation signal or the rule modification signal in operation2020.

In this instance, the rule generation signal may denote a signal indicating generation of a rule with respect to a metadata format of the content provider. The rule modification signal may denote a signal indicating modifying of a rule with respect to the metadata format of the content provider. The user information may correspond to subscription information of the content provider.

When the content provider is authenticated using user information stored in the system database1110in operation2030, the syndication portal430may request the orchestrator810for an access address to modify the rule in operation2040.

The syndication portal430may receive the access address from the orchestrator810in operation2050, and transfer the received access address to the content provider terminal210in operation2060.

When the orchestrator810receives, from the content provider terminal210, information associated with a rule to be generated or a portion of the rule to be modified in operation2070, data may be exchanged between the content provider terminal210and the rule storage unit820according toFIG. 17to thereby set a format in operation2080and2085.

The orchestrator810may transmit, to the content provider terminal210, a rule generation complete signal or a rule modification complete signal in operation2090to indicate the format is set according toFIG. 17. The rule generation complete signal or the rule modification complete signal may be differently transmitted depending on which one the syndication portal430receives between the rule generation signal and the rule modification signal.

When a third party desires to modify a rule of the third party using the third party terminal470, the syndication portal430may replace the orchestrator810with the reverse orchestrator870to thereby perform operations shown inFIG. 20, and thereby modify the rule of the third party.

As described above, according to embodiments of the present invention, it is possible to provide all end users with contents uploaded from a plurality of service providers and content providers using different platforms, and transformed to a single platform, and thus to enable all the end users to receive a content provided by a service provider using a different platform by uploading the contents, and transforming the uploaded contents to the single platform.

Also, according to embodiments of the present invention, it is possible to easily increase a number of target users to receive a content by transforming an uploaded content to a platform desired by another service provider and then providing the other service provider with the content transformed to the desired platform.

Also, according to embodiments of the present invention, it is possible to enable a content provider to provide a content without a separate uploading process by enabling a system side to periodically verify and upload the content of the content provider.