KR100279735B1 - Multimedia Content Delivery Method Using Metadata - Google Patents

Abstract

The present invention relates to a multimedia content delivery method using metadata for delivering high quality multimedia content to a user in non real time so that the user can utilize the multimedia content at a convenient time. The present invention comprises a service request step, a metadata delivery step and a multimedia content delivery step, wherein the service application step generates metadata containing user authentication, service selection, and service content delivery control information. The metadata delivery step delivers the metadata generated in the service application step. Content delivery step is to automatically deliver the multimedia content to the plurality of applicants at the same time using the IP multicasting technology when the content delivery time for the requested service.

Therefore, the service through the present invention can fully utilize the advantages of the existing base network and the next generation high-speed network, and unlike the conventional push service based on the client pull method, a pure push multimedia content delivery service. to be. It automatically delivers content at any time (e.g., when network usage is low) without user involvement, enabling service use at a convenient time, and also reduces the burden on servers and networks by utilizing IP multicast capabilities. Has an effect.

Description

Multimedia Content Delivery Method Using Metadata

The present invention relates to the field of on-demand multimedia content delivery service, and in particular, by using push technology, multimedia content is delivered to a user in a unicast or multicast manner in a non-real time in a low-efficiency time period of the network and stored in a cheap home storage device. A user relates to a method of utilizing multimedia content stored at a desired time.

Conventionally, the push information delivery service method using the pull method has become mainstream. In particular, each user gets necessary information from the server through end-to-end client-server connection, so when there are many users, the service response speed varies greatly depending on the server and network status. A cache server is used to solve this problem, but the majority of home users who are connected to the Internet through a low speed modem still have a lot of inconvenience. Due to such limitations of access speed and resources, on-demand information services are used to deliver relatively small information such as news, and are insufficient to deliver large-capacity or high-quality multimedia information such as magazines, movies, music, games, and software. Situation.

The problem of the prior art is that in order to accommodate a large number of users, first, a server or a large number of cache servers in proportion to the number of users is required. It takes a lot of time to deliver the same information to the user, and even if the capacity of the third server is sufficient, if there is a bottleneck in the network, the user feels slow regardless of the capacity of the server. This technology is not suitable for conveying information.

Three information delivery steps are performed for content delivery according to the method of the present invention. The first is a service application step, the second is a metadata delivery step, and the third is a multimedia content delivery step. In the service application step, there is a process of generating metadata containing user authentication, service selection, and service content delivery control information. The metadata delivery step is a step of delivering metadata generated in the service application step. The content delivery step is a step of automatically delivering multimedia content to a plurality of applicants at the same time using the IP multicasting technology when the content delivery time for the requested service.

Therefore, the present invention can accommodate a large number of users at the same time by using IP multicast technology, it is possible to adjust the capacity of the server irrespective of the number of users, and because the multicasting method is used to quickly and reliably share the same information to many users at the same time. It can transmit the information in the time zone which is the least efficient of the network, thus avoiding network congestion, and uses the cheap home storage device to store the transmitted information. Information can also be processed.

1 is an overall structure diagram of a storage-type push service system to which the present invention is applied.

2 is an overall information flow diagram for multimedia content delivery of the present invention.

3 is an information flow chart for a service application of the present invention.

4 is an information flow diagram of a metadata sender for transmitting the metadata of the present invention.

5 is an information flow diagram of a metadata receiver for receiving metadata of the present invention.

6 is an information flow diagram of a content sender for transmitting content of the present invention.

7 is an information flow diagram of a content receiver for receiving content of the present invention.

8 is a metadata form table in accordance with the present invention.

<Description of the code | symbol about the principal part of drawing>

1: Application Server 2: Content Server

3: transmission network 4: client

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram showing the overall structure of a storage-type push service system using the present invention. As shown in FIG. 1, the storage-type push service system is largely composed of four components, namely, an application server 1, a content server 2, a delivery network 3, and a client 4.

The application server 1 manages user authentication and service request menus, manages the creation and delivery of related metadata for service requests, the function of instructing the content server to start content delivery when the content is delivered, and manages the number of applicants for each service. Perform the operation.

The main purpose of the content server 2 is to deliver service content to multiple users simultaneously over an IP multicast network. Metadata is also unicast to the client via the content server.

The transport network 3 is a multicast IP network, and sub-IP links and physical protocols may vary from general LANs, ATM LANs, ATM over ADSL, etc., and these lower layers only need to support IP-multicast.

The client 4 provides a searcher function for initial screen configuration / management and service request, received metadata / service content management, user information management function, service execution, deletion, modification, content compression, etc. It has a function of starting a content receiver and a media player starting function when a predetermined time is received for delivery.

The content delivery method in the storage-type push service system configured as described above is as follows.

2 is a flowchart illustrating an overall information for delivering multimedia content. As shown in FIG. 2, three information flows, namely, a service requesting step in which a client connects to a server to apply for a service, a metadata delivery step in which a server connects a client applying for a service and delivers metadata; There is a content delivery step in which a client joins a multicast group and receives content from a server.

In the service application step, the user (client) first attempts to connect with the server system (S1), and when the connection setup is completed, log in to the server service system through the server user authentication procedure to navigate the service for service application (search). (S2). When a service is requested during a service navigation, the server generates new metadata related to the service (S3). When the user completes the service request, the user disconnects from the server system (S4).

In the metadata delivery step, the server attempts to connect with the client who applied for service (S5), and transmits the corresponding metadata when the connection setup is completed (S6). Then, the connection with the client is released (S7).

Finally, in the content delivery step, when the content delivery time comes, the clients join the corresponding multicast group (S8). When the content delivery time comes, the server delivers the content to the plurality of clients through the corresponding multicast address (S9). After the content reception is completed, the client leaves the corresponding multicast group (S10).

3 shows an information flow for a service application. As shown in FIG. 3, a user accesses an application server subscribed to a service through his client searcher (S21). The user authentication is checked in the access process (S22). If the authentication is successful, the service is registered in the application server (S23). If that fails, the authentication is attempted again. If the service is found by the service navigation (search), the process proceeds to the service application step (S24).

When the service application is determined, metadata for the specific service applied for is generated (S25). At this time, a key for releasing the encrypted content is dynamically generated at the time of generating metadata (S26). The value is a result of encrypting the de-encryption key of the content to be delivered with the public key of the service applicant. In order to manage the user's service request information and related metadata in the persistent state even when the server system is rebooted or in an error state, the metadata managed in the non-persistent object state is stored in the database (S27). Finally, the generated metadata is transmitted to the sender for delivery to the client (S28).

4 shows an information flow diagram of a metadata sender for delivering metadata. As shown in FIG. 4, when a user applies for a specific service, metadata for this purpose is generated and delivered to the user as described in FIG. 3 (S31). Attempt to establish a connection with the user (S32). When the connection is established, read the metadata stored in the database (S33). The read metadata is transmitted to the receiver (S34). If the transmission fails, it retries and repeats until the transmission is completed. When the transmission is completed, the sender releases the connection with the receiver (S35). In addition, the application server is notified that the transmission is completed so that the application server can take the appropriate action (S36).

5 shows a flowchart of an information metadata receiver for conveying metadata. As shown in FIG. 5, when a user applies for a specific service, metadata for this is generated and delivered to the user as described in FIG. 3 (S41). Attempting to establish a connection with the receiver responds to this setup request (S42). If it cannot accept the setup request, it sends a connection opposite response and waits until a normal connection setup request comes from the sender.

When the connection is established, the metadata is received through the established connection (S43). If the transfer fails, retry the transfer and repeat until the transfer is complete. When the transmission is completed, the sender releases the connection with the receiver (S44). The received metadata file is stored in the database of the receiver local system (S45). In addition, it informs the client application server that the transmission is completed so that appropriate actions can be taken (S46).

6 shows an information flow diagram of a content sender for delivering content. As shown in FIG. 6, when the service delivery time comes after the user applies for the service, the content sender prepares for content transmission (S51). First, it is checked whether the content transmission time has come (S52). If the delivery time is not reached, after a predetermined time, confirmation is attempted again. If the delivery time is reached, a multicast group for transmitting the specific service is generated (S53). If the group creation fails, retry is attempted, and if successful, the content to be transmitted is read from the content database (S54). The read content is transmitted by multicast to the user group (S55). If the transfer fails, retry the transfer. The scheme for retransmission is not included in the scope of the present invention, and it is assumed that such scheme exists. When the transmission is completed, the generated multicast group is released (S56), and the application server is notified of the completion of the content transmission (S57).

7 shows an information flow diagram of a metadata receiver for delivering content. As shown in FIG. 7, when the user receives a service request and the service reception time arrives, the content receiver prepares for content reception (S61). First, it is checked whether the content reception time is reached (S62). If the reception time has not reached, try again after a predetermined time, and if the reception time has passed, join the multicast group created for the specific service (S63). If the group join fails, retry and repeat until joining the group. If the join succeeds, it starts to receive the content (S64). If the content reception fails, the reception is attempted through retransmission and repeated until the reception is completed. When the reception is completed, the group is withdrawn from the joined multicast group (S65), and the received content is stored in the local database (S66). In addition, the client application server is notified of the completion of content transmission (S67).

8 illustrates a metadata format. As shown in FIG. 8, the metadata consists of 17 fields, and description of each field is as follows.

-ID is used to distinguish metadata uniquely. It is assigned from positive integer 1.

Type indicates the type of metadata, such as 1: "multi-push", 2: "uni-push", 3: "pull", 4: "broadcast", and so on.

-Address is the multicast address to which the client joins. Ipv4 (16Bytes) is the group address.

-Port is the port number of the multicast group to which the client will join, using numbers after 1024.

-DecryptionKey is a key for de-encrypting encrypted content. The decryption key (128 bytes) of the content is encrypted with the user's public key (512 bytes) and consists of 128 bytes.

ServerName is the name of the application server.

-ServiceName is a service name, such as movie name and subject name.

DeliveryStartTime is the content delivery start time, using ASN.1 Generalized Time and having three value types: 19851106210627.3, 19851106210627.3Z, 19851106210627.3-0500. This value is also used in the multicast group join phase, and joins the group using the value 5 minutes before the enhancement.

ServiceEndTime is in the same form as DeliveryStartTime above and specifies the service deadline. If this value is 0, it means infinity, and if it is past time than DeliveryStartTime, it is treated as infinity.

-DeliveryDuration is the expected delivery time of the content, and the format is hhmm, 0110 for 1 hour 10 minutes.

-DeliveryInterval means the repetition period of transmission. It is 0 and a positive integer (1 ~ 127). If 0, it is transmitted only once.

-DeliveryIntervalUnit represents the unit of DeliveryInterval above, and there are 1: "minute", 2: "time", 3: "day", 4: "week", 5: "month" and 6: "year".

CompressionType indicates what type of compression is used when the content is compressed, such as 1: none, 2: jar, 3: zip, 4: tar, 5: gzip, 6: compress, etc.

DLContentFormat represents a method of encoding content to be transmitted, 1: "MHEG-5", 2: "MHEG-6", 3: "HTML3.2", 4: "HTML4.0", 5: "MPEG-2" ", 6:" MPEG-1 ", 7:" AVI ", and so on.

DLContentName The name of the content to be transferred. If it is enclosed in jar etc, it will be the initial startup file name. For example, the first application object name in MHEG, eg startup.mhg.

ServiceOverview gives an overview of the service.

ServiceCategory is an indication of the service sector, including 1: Education, 2: News, 3: EPG, 4: undefined.

Since the present invention can accommodate a large number of users simultaneously using IP multicast technology, various types of clients such as PCs, network computers, HPCs (hand-held PCs), kiosk terminals, set-top boxes, web TVs, screen phones, etc. This technology is applicable, and especially in the situation where many Internet users are connected through low / medium speed modems, information is transmitted at a time when the network efficiency is lowest, so that a relatively high quality multimedia service can be provided at a low cost. It can be in many forms (e.g. video on demand, distance education on demand, personalized news / magazines, product listings, etc.).

Claims (6)

In the content delivery method of the storage-type push service system, After the client connects to the server and searches for the service through the authentication process, the server requests a service and generates new metadata. A metadata delivery step in which the server connects the client applying for the service and delivers the metadata, When the content delivery time is reached, clients join the multicast group, the server delivers the content to multiple clients through the multicast address, and the client that has received the content leaves the multicast group. Multimedia content delivery method using metadata, characterized in that to deliver the content by performing the delivery step. The method of claim 1, wherein the service application step, A user accessing an application server subscribed to a service through his client finder; Verifying user authentication when the server is connected; Searching for a service registered in the application server if the authentication is successful; Requesting a service when a user finds a desired service by the service search; When the service request is determined, the server generating metadata about the specific service to which the user applies; The server encrypts the reverse encryption key of the content to be delivered with the public key of the service applicant and dynamically generates a key for solving the encrypted content according to the result value at the time of generating the metadata; The server storing the metadata in a database to manage the metadata in a non-persistent object state; The server delivers the finally generated metadata to the sender for delivering to the client, the multimedia content delivery method using metadata. The method of claim 1, wherein the metadata sender of the metadata delivery step, When metadata delivery is initiated, attempting to establish a connection with a metadata receiver for metadata file transfer; When a connection is established, reading metadata stored in a database and transmitting the metadata to a receiver; Attempting retransmission when the transmission is unsuccessful and repeating the transmission until the transmission is completed, and when the transmission is completed, the sender disconnects from the receiver; And transmitting a notification to the application server of the completion of the transmission. The metadata receiver of claim 3, wherein Checking whether a connection establishment with a metadata receiver arrives for metadata transmission; In response to the setup request, if it is unable to accept the setup request, sending a connection establishment opposite response and waiting until a normal connection setup request comes from the sender; If the connection is established in response to the setting request, receiving metadata through the established connection; When reception is complete and the sender disconnects from the receiver, the receiver stores the received metadata file in a database of the receiver local system; And informing the client application server that the reception is completed. The method of claim 1, wherein the sender of the content delivery step, When the service delivery time comes after the user applies for the service, the content sender checking whether the content transmission time is reached; Attempting to check again after a predetermined time if the delivery time has not passed, and generating a multicast group for transmitting the specific service if the delivery time has passed; Retrying if the group creation fails, and reading the content to be transmitted from the content database if the group creation fails; Transmitting the read content to the user group in multicast; And releasing the multicast group generated when the transmission is completed, and notifying the application server of the completion of the content transmission. The method of claim 5, wherein the recipient of the content delivery step, Checking, by the content receiver, whether a content reception time has been reached; If the reception time has not reached, attempting to check again after a predetermined time has passed, and if the reception time has not reached, joining to the multicast group created for the specific service; If the group join fails, retry and repeat until the group is joined, and if the join succeeds, receiving content; When the reception is completed, the multimedia content delivery using metadata is performed, which is a step of leaving the joined multicast group, storing the received content in the receiver local database, and notifying the client application server of the completion of the content transmission. Way.