KR102711122B1 - Media sdk for playing drm content and controlling method thereof - Google Patents

Abstract

The present invention provides a media SDK control method, characterized by including the steps of: receiving a URL for DRM content from a web application; requesting DRM content from a broadcasting center (CDN) based on the URL; receiving the DRM content; requesting authentication and decryption for the DRM content; and decrypting the DRM content.

Description

MEDIA SDK FOR PLAYING DRM CONTENT AND CONTROLLING METHOD THEREOF

The present invention relates to a media SDK for playing non-standard DRM content and a control method thereof.

In the case of media, DRM (Digital Right Management) technology is applied to protect copyright. When the broadcast center applies DRM encryption to media content and transmits it, the terminal that receives it goes through the DRM decryption process and exposes the general content to the user. This is applied and used in various fields such as not only media but also e-books, audio sources, document security, and screen capture.

Netflix, a recently popular OTT (over-the-top) media service, has applied a technology called multi-DRM to enable media playback on web browsers of various devices.

At this time, multi-DRM supports different DRMs for each browser, such as Chrome, Safari, Internet Explorer (IE)/Edge. Specifically, Microsoft's Internet Explorer and Edge browsers only support Microsoft's PlayReady DRM, and similarly, Google's Chrome supports Google's DRM, Widevine Modular DRM, and Apple's Safari supports Apple's DRM called FairPlay Streaming. At this time, Netflix encrypts content for each DRM and transmits DRM content appropriate for the device.

On the other hand, domestic companies (e.g. U+) usually provide media content through their own application services (mobile, IPTV), so they encrypt content using customized non-standard DRM and provide services by decrypting DRM in application services as well.

However, there is no problem with non-standard DRM methods when controlling web browsers and DRM decryption directly in applications such as mobile or IPTV, but there is a problem in that it is difficult to provide non-standard DRM content in vehicles when OEM or Tier 1 (vendor) in vehicles pursues standard DRM.

The present invention aims to provide a media SDK and a media SDK control method for playing non-standard DRM content in a vehicle environment oriented toward standard DRM content.

According to one aspect of the present invention, a media SDK control method is provided, characterized by including the steps of: receiving a URL for DRM content from a web application; requesting DRM content from a broadcasting center (CDN) based on the URL; receiving the DRM content; requesting authentication and decryption for the DRM content; and decrypting the DRM content.

In addition, it is characterized by further including a step of receiving the decrypted DRM content.

In addition, it is characterized by further including a step of transmitting the decrypted DRM content to a web engine.

In addition, it is characterized by further including a step of requesting playback of decrypted DRM content through a web browser player.

In addition, it is characterized by further including a step of requesting a DRM key of the DRM content from the DRM decryption library.

In addition, it is characterized by further including a step of receiving authentication of the DRM content and a DRM key from a DRM server.

Additionally, the local server receiving the DRM content is characterized by utilizing nodejs.

In addition, the method is characterized by further including a step of parsing the received DRM content; and a step of determining which decryption tool to use based on the parsed information.

In addition, the decryption tool is characterized in that it is included in the header of the parsed information.

In addition, the URL is characterized as being a path for downloading the DRM content.

According to one aspect of the present invention, a media SDK is provided, characterized by including: a local server which receives a URL for DRM content from a web application, requests DRM content from a broadcasting center (CDN) based on the URL, and receives the DRM content; a media delivery which receives the DRM content from the local server and requests authentication and decryption of the DRM content from the DRM decryption library; and a DRM decryption library which decrypts the DRM content.

In addition, the local server is characterized by receiving the decrypted DRM content from the media delivery.

In addition, the local server is characterized by transmitting the decrypted DRM content to a web engine.

In addition, the local server is characterized by requesting playback of the decrypted DRM content through a web browser player.

In addition, the media delivery is characterized by requesting the DRM decryption library for a DRM key of the DRM content.

In addition, the DRM decryption library is characterized by receiving authentication of the DRM content and a DRM key from a DRM server.

Additionally, the local server is characterized by utilizing nodejs.

In addition, the local server is characterized by parsing the received DRM content and determining which decryption tool to use based on the parsed information.

In addition, the decryption tool is characterized in that it is included in the header of the parsed information.

In addition, the URL is characterized as being a path for downloading the DRM content.

According to one embodiment of the present invention, there is an advantage in that non-standard DRM content can operate normally even in a vehicle that targets only standard DRM content by providing a media SDK capable of playing back non-standard DRM content.

In addition, according to one embodiment of the present invention, there is an advantage in that frequent alignment processes can be avoided each time according to the vehicle environment by providing the media SDK to the vehicle manufacturer or vehicle vendor.

Figure 1 is a drawing explaining a standard DRM method for understanding the present invention.
FIG. 2 is a diagram explaining the operation method of a media SDK according to one embodiment of the present invention.
FIG. 3 is a configuration diagram illustrating a configuration module of a media SDK according to one embodiment of the present invention.
FIG. 4 is a flowchart illustrating a method for controlling a media SDK according to one embodiment of the present invention.

Hereinafter, the embodiments disclosed in this specification will be described in detail with reference to the attached drawings. Regardless of the drawing symbols, identical or similar components will be given the same reference numerals and redundant descriptions thereof will be omitted. The suffixes "module" and "part" used for components in the following description are given or used interchangeably only for the convenience of writing the specification, and do not in themselves have distinct meanings or roles.

In addition, when describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiments disclosed in this specification, the detailed description thereof will be omitted. In addition, the attached drawings are only intended to facilitate easy understanding of the embodiments disclosed in this specification, and the technical ideas disclosed in this specification are not limited by the attached drawings, and should be understood to include all modifications, equivalents, and substitutes included in the spirit and technical scope of the present invention.

Terms including ordinal numbers such as first, second, etc. may be used to describe various components, but the components are not limited by these terms. These terms are used only to distinguish one component from another. When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but there may also be other components in between.

On the other hand, when it is said that a component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

Singular expressions include plural expressions unless the context clearly indicates otherwise.

In this application, it should be understood that terms such as “comprises” or “has” are intended to specify the presence of a feature, number, step, operation, component, part or combination thereof described in the specification, but do not exclude in advance the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts or combinations thereof.

Figure 1 is a drawing explaining a standard DRM method for understanding the present invention.

Referring to FIG. 1, a web application (100) can receive encrypted DRM content from a broadcast center (CDN). Here, the broadcast center (CDN, content delivery network) refers to a system that stores and provides data in a network with multiple nodes to efficiently deliver content.

The web application (100) can transmit the received DRM content to EME (Encrypted Media Extensions, 110).

The EME interface (110) allows a user to use video content with DRM without installing a security program on a terminal. Accordingly, the EME interface (110) that receives the DRM content can decrypt the DRM content through the CDM interface (Contents Decryption Module, 120).

Here, the CDM interface (120) can communicate with a license server containing a decryption key for decrypting DRM content to obtain the decryption key and decrypt the video content.

At this time, various software companies provide CDM interfaces (120). This is because the CDM interfaces (120) that are supported by default differ depending on the web browser. For example, Widevine developed by Google supports Chrome, Android, Firefox, and Opera by default. In addition, Playready developed by Microsoft supports Internet Explorer (IE), Edge, and Smart TV by default. In addition, Fairplay developed by Apple supports Safari and IOS by default. Therefore, in order to use Widevine in Internet Explorer (IE), a plug-in must be installed.

In Figure 1, we will continue the explanation using Google's Widevine as an example.

The web application (100) can transmit DRM content to the vehicle browser, and the vehicle browser can transmit the DRM content to the Widevine Core, which performs DRM decryption of the content, through the EME interface (110). That is, the Widevine Core can be a decryption performer of the DRM content. At this time, the vehicle browser can communicate through the Widevine CDMi (Contents Description Module integration layer). Accordingly, the Widevine CDMI can transmit the DRM content to the Widevine Core. At this time, the Widevine Core can decrypt the DRM content.

Thereafter, the decrypted DRM content is transmitted through a process opposite to the above-described process, so that the web application (100) can play the DRM content in the vehicle browser.

However, Fig. 1 is a flow applied to standard DRM content, and the operations performed in Widevine, Playready, and Fairplay described above are not performed in the case of non-standard DRM content.

Therefore, in order to play non-standard DRM content in a vehicle browser, a media SDK for processing non-standard DRM content according to one embodiment of the present invention will be described below.

FIG. 2 is a diagram explaining the operation method of a media SDK according to one embodiment of the present invention.

At this time, SDK is a software development kit, which is a set of tools that can develop applications for a specific platform. Below, we will introduce an SDK applicable to web browser applications that can be played in a vehicle.

In addition, although the drawing of FIG. 2 illustrates a vehicle as an example, it is clear that the embodiments of the present invention can be applied to all devices that provide DRM content through a display.

Referring to FIG. 2, the infotainment web application can correspond to the web application described above in FIG. 1. That is, in order to use content such as mobile TV or professional baseball in the infotainment web application, a content download path (URL) can be transmitted to the media SDK. Here, the media SDK can perform the function of Widevine CDMi described above in FIG. 1. More specifically, when the media SDK receives a URL for downloading content from the infotainment web application, it can create a local server called nodejs and transmit the URL to the local server.

In one embodiment of the present invention, a local server of a media SDK can request a DRM content from a broadcast center based on a content URL received from an infotainment web application and receive the DRM content from the broadcast center. At this time, when the local server receives the DRM content, it can parse the DRM content and determine which decryption tool is used in the header portion. For example, when standard DRM content is parsed, information that the DRM content is decrypted using, for example, a Widevine tool is included in the header portion. On the other hand, in the case of non-standard DRM content, such information is not included in the header portion. Therefore, in the case of non-standard DRM content, decryption of the DRM content can be performed through the media SDK of the present invention.

Afterwards, the local server can pass the DRM content information to the media deliverer of the media SDK.

The media delivery can request the media decryption library for authentication and a DRM key of the DRM content, and request decryption of the DRM content. Accordingly, the media decryption library can request and receive authentication and a DRM key of the DRM content from the DRM server.

The DRM decryption library can decrypt the DRM content using the authentication information and DRM key of the received DRM content, and transmit the decrypted DRM content to the media deliverer.

MediaDelivery can deliver decrypted DRM content to a local server.

The local server can request decrypted DRM content to be played via a web browser player via a web engine or media framework.

Through the above-described method, even non-standard DRM content can be played through a web browser player like standard DRM content by using the media SDK.

FIG. 3 is a configuration diagram illustrating a configuration module of a media SDK according to one embodiment of the present invention.

Referring to FIG. 3, the media SDK (300) may include a local server (310), a media delivery (MediaDeliver, 320), and a DRM decryption library (DRM Decryption Lib, 330). However, the components illustrated in FIG. 3 are not essential for implementing the media SDK (300), and thus the media SDK (300) described in this specification may have more or fewer components than the components listed above. In addition, not all of the aforementioned components are illustrated in detail in the attached drawings, and only some important components may be illustrated in the attached drawings.

However, it will be understood by those skilled in the art that at least the components of FIG. 3 may be included in the media SDK (300) to implement its function as a media SDK (300), although not all are illustrated.

Media SDK (300) can support software that can be installed in a vehicle.

The local server (310) can receive a URL for DRM content from a web application. Here, the URL is characterized as a path for downloading the DRM content. In one embodiment of the present invention, the local server (310) can request DRM content from a broadcast center (CDN) based on the URL, and receive the DRM content from the broadcast center. The local server (310) can parse the received DRM content, and determine which decryption tool to use based on the parsed information. At this time, the decryption tool is characterized as being included in the header of the parsed information. Thereafter, the local server (310) can receive the decrypted DRM content from the media delivery (320). The local server (310) can transmit the decrypted DRM content to a web engine, and request it to be played through a web browser player. Here, the local server (310) can utilize nodejs.

The media delivery (320) can receive DRM content from the local server (310) and request authentication and decryption of the DRM content from the DRM decryption library (330). In addition, the media delivery (320) can request the DRM decryption library (330) for a DRM key of the DRM content.

The DRM decryption library (330) can receive authentication of DRM content and a DRM key from a DRM server.

Accordingly, the media SDK can receive and transmit only a URL from the web application to receive encrypted DRM content from the broadcast center. Thereafter, the encrypted DRM content can be decrypted and transmitted by the media SDK to the in-vehicle web browser application, and the web browser application can play the decrypted non-standard DRM content.

FIG. 4 is a flowchart illustrating a method for controlling a media SDK according to one embodiment of the present invention.

Referring to FIG. 4, in step (S410), a URL for DRM content can be received from a web application. Here, DRM content means content to which all technologies are applied that are used by publishers or copyright holders to control the use of digital materials or hardware they have distributed and restrict their use to only the intended purpose.

At step (S420), DRM content can be requested from a broadcast center (CDN) based on a URL. Here, the broadcast center (CDN, content delivery network) refers to a system that stores and provides data in a network with multiple nodes to efficiently deliver content.

At step (S430), DRM content can be received. At this time, the local server of the media SDK that receives the DRM content can utilize nodejs. Here, nodejs corresponds to a software platform used for developing scalable network applications (especially, server side).

In step (S440), authentication and decryption of DRM content can be requested. At this time, the media delivery can request the DRM decryption library for the DRM key of the DRM content. To this end, the DRM decryption library can request the DRM server for the authentication and DRM key of the DRM content, and can receive the authentication and DRM key of the DRM content from the DRM server. Here, the DRM server performs a task of verifying authentication information from the agent (the DRM decryption library in step (S440)). In some cases, authentication is performed using the agent's identifier (ID) and password, and in other cases, authentication is performed using internal information of the corresponding terminal (e.g., MAC address, etc.). When authentication information is received using various authentication methods, the DRM server can retrieve the corresponding value from the internal authentication DB server, verify it, and if authentication is passed, retrieve policy information and transmit it to the agent.

In step (S450), the DRM content can be decrypted. At this time, the DRM decryption library can decrypt the DRM content using the authentication information and DRM key received from the DRM server. The DRM decryption library can transmit the decrypted DRM content to the media delivery. The media delivery can transmit the decrypted DRM content to the local server, and the local server can transmit the decrypted DRM content to the web engine.

At step (S460), decrypted DRM content can be received. The web engine can receive the decrypted DRM content and transmit it to the media framework. The media framework can transmit the received decrypted DRM content to the web browser player.

Finally, at step (S470), the decrypted DRM content can be played through a web browser player.

The above-described present invention can be implemented as a computer-readable code on a medium in which a program is recorded. The computer-readable medium includes all types of recording devices that store data that can be read by a computer system. Examples of the computer-readable medium include a hard disk drive (HDD), a solid state disk (SSD), a silicon disk drive (SDD), a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and also includes those implemented in the form of a carrier wave (e.g., transmission via the Internet).

Although the data processing device and method according to the embodiments of the present invention have been described in specific embodiments, these are merely examples, and the present invention is not limited thereto, and should be interpreted to have the widest scope according to the basic idea disclosed in this specification. Those skilled in the art may implement embodiments that are not specified by combining or replacing the disclosed embodiments, but this also does not exceed the scope of the present invention. In addition, those skilled in the art may easily change or modify the disclosed embodiments based on this specification, and it is clear that such changes or modifications also fall within the scope of the present invention.

300: Media SDK
310: Local server
320: MediaDeliver
330: DRM Decryption Lib

Claims (20)

Step of receiving a URL for DRM content from a web application;
A step of requesting DRM content from a broadcasting center (CDN) based on the above URL;
A step of receiving the above DRM content;
A step of parsing the above DRM content;
A step of obtaining decryption tool related information related to which decryption tool is used based on the above parsed information;
A step of requesting authentication and decryption of the DRM content based on the information related to the decryption tool; and
A media SDK control method, characterized by including a step of decrypting the above DRM content. In the first paragraph,
A media SDK control method, characterized in that it further comprises a step of receiving the decrypted DRM content. In the second paragraph,
A media SDK control method, characterized in that it further comprises a step of transmitting the decrypted DRM content to a web engine. In the third paragraph,
A media SDK control method, characterized in that it further includes a step of requesting playback of the decrypted DRM content through a web browser player. In the first paragraph,
A media SDK control method, characterized in that it further comprises a step of requesting a DRM key of the above DRM content. In paragraph 5,
A media SDK control method, characterized in that it further comprises a step of authenticating the DRM content and receiving the DRM key from a DRM server. In the first paragraph,
A media SDK control method, characterized in that the local server receiving the above DRM content utilizes nodejs. delete In paragraph 1,
A media SDK control method, characterized in that the information related to the decryption tool is included in the header of the parsed information. In the first paragraph,
A media SDK control method, characterized in that the above URL is a path for downloading the DRM content. A local server which receives a URL for DRM content from a web application, requests DRM content from a broadcasting center (CDN) based on the URL, receives the DRM content, parses the DRM content, and obtains decryption tool related information related to which decryption tool is used based on the parsed information;
A media delivery device that receives the DRM content from the local server and requests authentication and decryption of the DRM content based on information related to the decryption tool; and
A media SDK, characterized by including a DRM decryption library for decrypting the above DRM content. In Article 11,
The above local server is
A media SDK characterized by receiving the decrypted DRM content from the media delivery. In Article 12,
The above local server is
A media SDK characterized by transmitting the decrypted DRM content to a web engine. In Article 13,
The above local server is
A media SDK characterized by requesting playback of the decrypted DRM content through a web browser player. In Article 11,
The above media delivery
A media SDK characterized by requesting a DRM key of the DRM content from the DRM decryption library. In Article 15,
A media SDK, characterized in that the above DRM decryption library receives authentication of the DRM content and the DRM key from a DRM server. In Article 11,
The above local server is a media SDK that utilizes nodejs. delete In Article 11,
A media SDK, characterized in that the information related to the decryption tool is included in the header of the parsed information. In Article 11,
A media SDK, characterized in that the above URL is a path for downloading the DRM content.