Method for transferring resource and method for providing information

The present invention relates to a resource transmission method and an information providing method. More specifically, the present invention relates to a technique-related data transmission method and information provision method that can easily provide information via an event in a digital rights management (DRM) interoperability environment.

In general, digital rights management (DRM) is a general resource protection technology that prevents the illegal copying and use of digital resources and allows only legally authorized users to use the digital resources. Is. DRM provides a comprehensive protection system during the production and distribution of digital resources. For example, DRM uses encryption technology to convert digital resources into data encrypted in packet form, making digital resources unusable without undergoing legal authentication procedures.

By exchanging information with a variety of resource service models, DRM is the foundation of reliable and legitimate resource services. Now, in practice, service providers use their own DRM to protect their own resources. For example, in the case of a sound source service that provides a sound source via online communication, the sound source is encrypted with a specific encryption pattern to prevent illegal copying, and therefore the sound source is an application provided by the corresponding service provider. Can only be regenerated by using.

However, due to the technical or political closure of DR, interoperability is generally not possible between different DRMs. Therefore, the resources provided by one service provider cannot be used by applications provided by other service providers. This has been pointed out as a serious problem that hinders the market development of legitimate content by actually limiting the general use of DRM resources.

Recently, in order to deal with the above problems, efforts have been made to provide a framework in which closed DRM structures are compatible with each other, and a typical example is a DRM interoperability system. A DRM interoperability system can be a system that controls different DRMs in the middle so that resources or licenses can be exchanged and used.

A DRM interoperability system is realized by defining system resources and forming an operation model that generates and manages the defined system resources. In particular, the key factors in the realization of DRM interoperability systems are considered to include reliable client authentication and management, efficient resource and license transmission, and efficient information management.

<p> The present invention provides a resource transmission method capable of transmitting a plurality of resources using a single transmission session in a DRM interoperability environment and receiving the transmission state of each resource via an event.</p><p> The present invention also provides an information providing method capable of providing information on the transmission state of each resource via a predetermined event when transmitting a plurality of resources in a DRM interoperability environment.</p><p> The present invention is to provide an information providing method capable of providing information related to a resource or a license to a specific entity via an event.</p>

<p> According to one aspect of the present invention, there is provided a resource transmission method for transmitting resources in a digital rights management (DRM) interoperability system. The resource transmission method includes a stage in which a resource is transmitted in a transmission session by using at least two handlers, and a stage in which an event message including information indicating the identification information of the transmission session and information indicating the transmission state of the resource is received from the handler. Has. In this case, the information representing the transmission state of the resource can include a resource index capable of identifying the resource and transmission state information of the resource corresponding to the resource index. Further, the resource may be at least one, and the event message may include at least one piece of information representing the transmission state of the resource.</p><p> Further, the stage of transmitting the resource includes a stage of receiving a message requesting transmission of the resource to a destination, a stage of forming a chain including the at least two handlers for executing the transmission, and a stage of forming a chain including the at least two handlers. It can have a step of transmitting a message requesting the operation of the handler to the handler and permitting transmission of the resource in the transmission session.</p><p> Further, the message requesting transmission of the resource to the destination includes transmission session information capable of identifying the transmission session, source information representing a source for transmitting the resource, and transmission by the resource. It can include destination information representing the destination to be transmitted.</p><p> Further, the at least two handlers can have a resource exporter that exports the resource requested for transmission and a resource importer that receives the resource transmitted from the resource exporter. Further, the at least two handlers are a resource exporter that exports the resource requested for transmission, and a resource that converts the source transmitted from the resource exporter into the resource format requested by the destination and transmits the converted resource. It can have a transformer and a resource importer that receives resources transmitted from the resource transformer.</p><p> In addition, a message requesting transmission of the resource to the destination is received from the client. In this case, the resource transmission method may further include a step of transmitting the event message to the client in response to the reception of the event message.</p><p> Further, the resource transmission method can further include a step of subscribing to the event by requesting the handler to subscribe to the event capable of receiving the event message. Further, the resource transmission method can further include a stage of collecting information from a plurality of handlers and a stage of determining whether or not to execute the requested transmission according to the collected information.</p><p> On the other hand, according to another aspect of the present invention, an information providing method is provided. The information providing method is security authentication by using a step of receiving a message from a control entity containing information that can identify a transmission session and information that can identify at least one resource, and a receiving entity specified by the received message. The control of an event message including a step of establishing a channel (SAC), a step of transmitting the at least one resource through the established SAC, and information indicating the identification information of the transmission session and the transmission state of the resource. It can have a stage of transmission to an entity. Further, the received message can be at least one of a resource export request message, a resource conversion request message, and a resource import request message.</p><p> Further, the information providing method determines the stage of receiving the request message requesting the subscription of a specific event capable of receiving the event message from the control entity and the validity of the request, and the request is valid. If so, it may further have a step of transmitting a response message to the control entity indicating that subscription to the event is allowed.</p><p> According to another aspect of the present invention, an information providing method is provided. The information providing method determines the stage of receiving a request message requesting a subscription for an event capable of receiving a predetermined event message from a specific entity, the validity of the request, and the case where the request is valid. , A response message indicating that the subscription of the event is permitted is transmitted to the control entity, and the event message can be transmitted to the specific entity. In this case, the event message can be either a resource transmission status event message containing information on the transmission status of each resource or an update license event message containing updated content of the neutral license.</p><p> Further, when the event message is the license event message, the event message includes the neutral license, and the neutral license is a change field information representing a change portion of the neutral license and a portion represented by the change field information. Can include change state information that indicates how was changed. The response message may also include a unique subscription identifier.</p>

<p> According to the present invention, when transmitting a plurality of resources using a single transmission session in a digital rights management (DRM) interoperability environment, it is possible to provide information on the transmission state of each resource in a specific event format. it can. In particular, since the transmission status information of each resource can be provided by using one event message, the information can be provided more efficiently. In addition, when a neutral license renewal event occurs, it is possible to provide information indicating where and how the neutral license has been changed, which can improve the convenience of license management.</p>

Preferred embodiments of the present invention will be described below with reference to the accompanying drawings so that the present invention can be easily practiced by those skilled in the art. In describing the illustrated preferred embodiments of the present invention, certain technical terms will be used for clarity. However, the present invention is not intended to be limited to the particular terms so selected, and each of the particular terms is a step or step that operates in a similar manner to achieve similar objectives. Includes all technically equivalent terms for an item.

FIG. 1 is a block diagram showing a schematic configuration of a DRM interoperability system in which different types of DRM are adapted to each other.

As shown in FIG. 1, the DRM interoperability system can have a client unit 10, an authentication and management unit 20, a processing control unit 40, a content processing unit 50, and a license processing unit 30.

Each of the above-mentioned parts can be composed of at least one or more entities. At this time, the entity can represent a module or device configured as software or hardware that performs a predetermined unique function. Each entity can be a set of one or more unit function modules that perform a given unit function. An entity is installed on a given device for data communication with another entity via a given interface. Also, even if the entities belong to the same part, the entities can be installed or embodied on different devices. The device can be different depending on the execution environment.

The client unit 10 can have a client. The client is an entity that provides various functions so that the user can use the DRM interoperability service in cooperation with the authentication and management unit 20 and the processing control unit 40. The client can be included in the user's device. A device having a client is referred to as a client device.

The client can request client authentication from the authentication and management unit 20. The authenticated client can request the processing control unit 40 to transmit data (for example, a resource or a license) to a desired destination by calling a predetermined entity of the processing control unit 40. In addition, the client can have typical functions of the client, for example, a function of using (or playing) resources, a user interface function, and the like. In this case, the client can be the end point of resource consumption.

The main function of the authentication and management unit 20 is to authenticate the client and manage the authentication information. To facilitate this function, the authentication and management unit 20 can use the concept of domain.

A domain is the basic unit of a DRM trust system and can represent the extent to which a DRM interoperability system is effectively applied. A domain can consist of a collection of authorized devices or systems. For example, a domain can contain a collection of authorized client devices. In this case, even if the client devices in the domain have different DRM resources, the client devices can share the resources with each other.

FIG. 2 is a block diagram showing the domain and the entities constituting the domain and the correlation between the entities. The description in Figure 2 focuses on the entities involved in client authentication and management.

With reference to Figure 2, the DRM interoperability system forms domain 5. Domain 5 can be configured to take into account the physical location of client device 12 where client 3 is installed. For example, a domain consists of authorized client devices 12 that reside in a particular physical area. On the other hand, the domain can consist only of logically authenticated client devices without considering the physical location of the client device 12.

In this description, as described above, the domain is configured by the client device 12 in the predetermined local area while considering the physical position of the client device 12, and the client device outside the predetermined local area in the network area is also a domain. You can subscribe to. However, this is an example of an embodiment. The present invention is not limited thereto.

A local environment is required to configure domain 5. At this time, the local environment represents an environment in which a physical network is prepared so that devices in a predetermined local area are interactive with each other, and the physical network is interactive with an external network. For example, the local environment can be a home network system.

The local area network described below is assumed to be the area where the local environment is formed. For example, the local area can be the home of a user with a home network system, a place where at least two devices can be connected through local networking, and so on. Furthermore, the network area is assumed to be the area of a wide area network (WAN) such as the wired / wireless Internet.

As shown in FIG. 2, the authentication and management unit 20 that authenticates and manages the client 3 can have a domain manager 22, a license manager 24, and a reference point controller 26.

Domain manager 22 is an entity that performs functions that manage domain 5. For example, the domain manager 22 registers various functions, such as the function of creating domain 5, the function of destroying domain 5, the function of associating a client with domain 5, the function of removing a client from domain 5, and the reference point controller 26. Can perform the function to do.

The domain manager 22 can be located anywhere in the local area or network area. For example, in the example shown in FIG. 2, the domain manager 22 is located in the network area. In this case, the domain manager 22 can interact with the reference point controller 26 and the client 3 via the Internet or the like. On the other hand, the domain manager 22 can be placed in the local area. In this case, the domain manager 22 is included in the device in the local area.

The license manager 24 manages the user's license information. For example, the license manager 24 can provide a login function for the user and perform typical online service manager functions for storing and managing license information. The license manager 24 can execute a function of generating a user name, a function of deleting a user name, a function of associating license information with a user name, a function of generating license information, a function of deleting license information, and the like.

The license manager 24 can be located in a network area, for example, on the service provider side. However, the location of the license manager 24 is not limited to the network area. Therefore, the license manager 24 can reside in the local area. That is, the domain manager 22 and the license manager 24 can be placed at any location in the local area or network area.

The reference point controller 26 checks whether a predetermined entity (for example, a client) exists in the local area, and provides the verified entity with credentials for verifying that the entity is located in the local area. .. Because of this function, the reference point controller 26 can determine the range of the local area. The range of the local area can be determined by using the physical distance, the number of hops, the reaction time, and the like.

The reference point controller 26 confirms whether or not the client 3 is located in the local area according to the request of the client 3. Once the client 3 is verified to be properly located in the local area, the reference point controller 26 can provide domain credentials to verify that the client 3 is located in the local area. The domain credentials can be provided to the domain manager 22 when the client 3 requests the domain manager 22 to authenticate the client 3. Domain manager 22 reads the received domain credentials and verifies that client 3 is properly located in the local area. The domain manager 22 can then authenticate client 3. Of course, in addition to such a method, the client 3 can be authenticated by the domain manager 22 by receiving typical user information or authentication.

The reference point controller 26 can be placed in the local area. That is, the reference point controller 26 can be included in the device existing in the local area. In addition, the reference point controller 26 can be selected by a predetermined process when the domain is first configured. For example, the reference point controller 26 can be specified by the domain manager 22 or can be automatically selected by exchanging messages between devices located in the local area.

On the other hand, in the processing control unit 40, the client 3 authenticated to the domain 5 requests the processing control unit 40 to transmit data (that is, a resource or a license), and the processing control unit 40 can transmit the requested data. The resource processing unit 50 or the license processing unit 30 is controlled in this way.

FIG. 3 is a block diagram showing a detailed configuration of the processing control unit 40 and the resource processing unit 50 used for resource transmission. Figure 3 shows the entities involved in the resource transmission process.

Referring to FIG. 3, the processing control unit 40 has a resource processing controller 41 and a license processing controller 42. Since the license processing controller 42 is not related to the transmission of resources, a detailed description will be given later.

The resource processing controller 41 receives a request from the client 3 to transmit one or more resources to a specific destination. The resource processing controller 41 controls the resource processing unit 50 so that resources are transmitted according to the received resource transmission request. The content processing controller 41 can be present anywhere in the local area or network area, preferably in a device located within the local area.

The resource processing unit 50 transmits resources from the source to the destination under the control of the resource processing controller 41. The resource processing unit 50 has a plurality of resource handlers. A resource handler can have an entity that performs functions related to the transmission and processing of resources. The resource handler has a resource exporter 52, a resource transformer 51, and a resource importer 53.

The resource exporter 52 can perform a function of exporting the content requested to be transmitted by the resource processing controller 41 and transmitting the exported resource to the resource transformer 51 or the resource importer 53 in the form of a neutral resource. The neutral resource can be a clean resource that is not encrypted by using a predetermined DRM. The resource requested by the resource processing controller 41 can be an encrypted resource by using a predetermined DRM. The resource exporter 52 extracts the requested resource from the source, converts the resource into a neutral resource, and transmits the resulting resource. The resource exporter 52 can also receive the neutral resource decoded by the source and transmit the received neutral resource.

The resource transformer 51 receives the neutral resource transmitted from the resource exporter 52, converts the received neutral resource into a signal having the requested format, and transmits the signal to the resource importer 53. The requested format can be the format required by the destination. The resource transformer 51 participates in the transmission only when the format conversion of the neutral resource is required.

The resource importer 53 receives the neutral resource transmitted from the resource transformer 51 or the resource exporter 52, and provides the received neutral content to the destination. In this case, the resource importer 53 may provide the received neutral resource to the destination without encryption or after encrypting the neutral resource so as to have a format suitable for DRM applied to the destination. it can. In the former case, the destination uses the neutral resource provided by the resource importer 53 after encrypting the neutral resource by using its own features to match the DRM applied to the resource importer 53. be able to. In the latter case, since the neutral resource is provided in the encrypted state by the resource importer 53, the resource importer 53 can use the neutral resource without encryption.

FIG. 4 is a block diagram illustrating an example of arrangement of the resource processing controller 41 and the resource handlers 51 to 53.

As shown in FIG. 4, the resource exporter 52 can be included in the request device DV1 and the resource importer 53 can be included in the destination device DV2. Further, the resource processing controller 41 or the resource transformer 51 can be included in another device different from the request device DV1 and the destination device DV2.

The requesting device DV1 can be a client device that requests the transmission of resources. The requesting device DV1 can have a requesting client RC1 requesting the transmission of resources. A specific DRM can be installed on the requesting device DV1. When attempting to transmit a resource stored in the request device DV1, the request device DV1 acts as a destination.

The destination device DV2 can be the destination (eg, client device or specific system) to which the resources requested for transmission by the requesting client RC1 are transmitted. The destination device DV2 can have a destination client RC2. Destination DRM can be installed on destination device DV2. The destination DRM may be the same as or different from the DRM provided in the request device DV1.

The arrangement of the resource processing controller 41 and the resource handlers 51 to 53 is shown in FIG. 4 for illustration purposes only. Therefore, the resource processing controller 41 and the resource handlers 51 to 53 can be included in the same device, some of these elements can be included in the same device, or all of these elements can be included in separate devices. Can be done. For example, the resource processing controller 41 can be included in the request device DV1 or the destination device DV2, or the resource transformer 51 and the resource processing controller 41 can be included in the same device.

In this way, the resource processing controller 41, the resource exporter 52, the resource transformer 51, and the resource importer 53 are not limited to a specific device in terms of position, but are arranged at various positions. However, preferably, for security reasons, the resource exporter 52 can be included in the request device DV1 and the resource importer 53 can be included in the destination device DV2. Therefore, the present invention will be described below by using the configuration of FIG.

FIG. 5 is a flow chart showing a process of transmitting resources by using the resource processing controller 41 and the resource handlers 51 to 53. Specifically, FIG. 5 shows an example of a process of transmitting a plurality of resources included in the request device DV1 to the destination device DV2 which is the destination.

Referring to FIG. 5, the request client RC1 transmits a resource transmission request message requesting the transmission of a plurality of resources to the resource processing controller 41, and the resource processing controller 41 receives the resource transmission request message (step S60).

In this case, the resource transmission request message can include a transmission session identifier (ID), resource chain information, source information, destination information, and the like. Optionally, the resource transmission request message can further include DRM system information of the destination to which the resource is received.

The resource chain information can be information that can identify a plurality of resources requested to be transmitted. Here, a resource chain means a set of resources composed of one or a plurality of resources. Since a plurality of resources are transmitted as an example of this explanation, it is assumed that the number of resources included in the resource chain is a plurality. However, the present invention is not limited to this. Therefore, if there is only one resource to be transmitted, the resource chain can contain only one resource. The resource chain information can include information that can identify each resource included in the resource chain requested to be transmitted.

The transmission session ID can be an identifier that can uniquely identify the transmission session. The transmission session ID is used to identify a transmission session when a particular operation is performed, for example, when the transmission of a resource is canceled or when an event message indicating a resource transmission state is transmitted.

The source information can be information that can identify where the plurality of resources requested for transmission are transmitted. The source information can include an identifier capable of identifying the source device or system (for example, the requesting device of the present embodiment), information on the file format of the resource requested to be transmitted, and the like.

The destination information can be information that can recognize the destination (for example, the destination device of the present embodiment) to which the requested plurality of resources are transmitted. The destination information can include a destination identifier that can identify the destination, information on the file format required for the destination, and the like. The file format information included in the destination information can be used when the format is converted by the resource transformer 51.

Upon receiving the resource transmission request message from the request client RC1, the resource processing controller 41 collects information on the resource handlers placed in the system (stages S61, S62, S63). For example, the resource processing controller 41 queries at least one resource exporter 52, resource importer 53, and resource transformer 51 for capabilities and receives a response from the corresponding entity. Therefore, it can recognize source, intermediate and destination device, system, and DRM capability information related to the transmission of resources.

When the information is collected, the resource processing controller 41 determines whether or not to transmit the requested resource based on the collected information. The resource processing controller 41 checks whether the requested resource can be transmitted by considering the required resource format, system policy, security authentication channel algorithm information that can be executed between entities, and the like. Can be done. For example, if the capacity of the collected resource transformer cannot support the conversion from the resource format to the required resource format, the resource cannot be transmitted. In contrast, resources can be transmitted when they can support the required format of the resource. The resource processing controller 41 can determine whether or not to transmit a resource by considering the above items.

When it is determined that the resource will be transmitted, the resource processing controller 41 forms a resource conversion chain composed of resource handlers 51 to 53 capable of effectively executing the requested process. For example, the resource processing controller 41 can effectively perform the requested resource conversion based on the collected information, such as resource handlers 51 to 53, such as resource exporter 52, resource transformer 51 (optional), and resources. The importer 53 is determined, and the resource handlers 51 to 53 are controlled so as to form a resource conversion chain.

The resource conversion chain may or may not include the resource transformer 51. The reason for this is that if the format of the requested resource is different from the format of the resource requested at the destination, the format of the transmitted resource must be converted by the resource transformer 51, while the format of the requested resource must be converted. This is because if the format is the same as the format of the resource required by the destination, it is not necessary to convert the format of the transmitted resource.

The conversion of the resource format can be called the codec conversion. For example, if the requested resource is compressed with MPEG-2 and the format of the resource that can be used at the destination is MPEG-4, the resource having the MPEG-2 format cannot be used at the destination. .. Therefore, it is necessary to convert the MPEG-2 resource to the MPEG-4 format by using the resource transformer 51. In this description, it is assumed that the requested resource format is different from the resource format requested at the destination and therefore a resource conversion is required. In this case, the resource conversion chain needs to have the resource transformer 51.

The resource processing controller 41 sends an operation control message to the resource handlers 51 to 53 included in the resource conversion chain (stages S67, S68, S69). For example, the resource processing controller 41 sends a resource export request message, a resource conversion request message, and a resource import request message to the resource exporter 52, the resource transformer 51, and the resource importer 53, respectively.

The resource export request message can include transmission session ID, resource chain information, receiver information, and the like. Receiver information means receiver information that can export and transmit resources. In the present description, since the resource conversion chain includes the resource transformer 51, the receiver information can be used as the identification information of the resource transformer 51. However, when the resource conversion chain does not include the resource transformer, the receiver information can be used as the identification information of the resource importer 53.

The resource conversion request message can include transmission session ID, resource chain information, transmitter information, receiver information, format information of the resource to be transmitted, information in the converted format, and the like. The transmitter information and the receiver information can be information that can identify an entity that sends a resource and an entity that receives a resource. That is, the transmitting unit information can be used as the identification information of the resource exporter 52, and the receiving unit information can be used as the identification information of the resource importer 53.

The resource import request message can include transmission session ID, resource chain information, transmitter information, and the like. The transmitter information can be information that can identify the transmitter that transmits the resource. In this description, the transmitter information can be used as the identification information of the resource transformer 51. However, if the resource transformer 51 does not exist in the resource chain, the transmitter information can be the information of the resource exporter 52. When requesting a resource import, the transmitter information can include receiver information (destination information) that ultimately receives the resource and destination DRM system information.

The transmission session ID included in the above operation control message (that is, resource export request message, resource conversion request message, and resource import request message) corresponds to the transmission session identifier included in the resource transmission request message previously received from the request client RC1. Information to be done. That is, the transmission session identifier included in the operation control message is substantially the same as the transmission session identifier included in the resource transmission request message.

The resource chain information included in the operation control message is information corresponding to the resource chain information included in the resource transmission request message received from the request client RC1. Therefore, since the resource chain information includes the identification information of the plurality of resources, the plurality of resources identified by the resource chain information can be transmitted within one transmission session identified by the transmission session ID.

Thus, when the resource exporter 52, the resource transformer 51, and the resource importer 53 receive the resource export request message, the resource conversion request message, and the resource import request message from the resource processing controller 41, the resource exporter 52 and the resource transformer 51 A security authentication channel (SAC) is established between the resource transformer 51 and the resource importer 53 (step S70). In this case, security methods used for the TCP / IP transport layer, such as transport layer security (TLS), can be used to establish SAC.

In response to the resource export request message, the resource exporter 52 establishes a SAC for the resource transformer 51 so that the requested resource can be safely transmitted to the receiver, that is, the resource transformer 51. In response to the resource conversion request, the resource transformer 51 transforms the resource transmitted from the resource exporter 52 and establishes a SAC for transmitting the resource to the resource importer 53. On the other hand, in response to the resource import request, the resource importer 53 can also establish a SAC for transmitting the resource transmitted from the resource transformer 51 to the destination device DV2 (that is, the end point of the resource transmission). This is even more useful when the resource importer 53 is installed on a different device than the destination device DV2.

Therefore, SAC is established along the route from the resource exporter 52 to the resource importer 53 via the resource transformer 51. Further, in order to provide the resource to the end point, the resource importer 53 can establish a SAC between the resource importer 53 and the end point. Each resource handler reports to the resource processing controller 41 that the SAC is fully established (stages S71, S72, S73).

When the establishment of SAC is completed, resources are transmitted from resource exporter 52 (stage S74). In this case, the combined resource handler pair (ie, resource exporter 52-resource transformer 51 and resource transformer 51-resource importer 53) supports multi-transmission protocols. The multi-transmission protocol allows multi-resource transmission in a single transmission session. The protocol can also support variable frame sizes. Therefore, a plurality of resources can be transmitted in a single transmission session.

FIG. 6 shows an example of a multi-transmission protocol.

As shown in Figure 6, multiple resources can be transmitted in the transmission of a single transmission session. The resource index is inserted in the header of each resource. The resource index can be a predetermined bit value (eg, 4 bits) that identifies each resource. A resource index is a factor used to distinguish each resource transmitted during a corresponding transmission session by associating it with the requested resource. Also, a resource separator is inserted at the end of each resource to identify the resource. For example, the resource separator can be configured with 4-bit 0.

Each resource can be divided into multiple frames according to its length. A frame size of a particular bit (eg, 4 bits) is inserted into the header of each frame, followed by a frame payload that carries the data. On the other hand, the end of transfer process (EOT) is inserted at the end of each session to indicate the end of transmission. The EOT can be a 4-bit 1.

Since the multi-transmission protocol is supported as described above, multiple resources can be transmitted in one transmission session corresponding to the transmission session ID provided by requesting client RC1. Such transmission is sequentially started from the resource exporter 52. That is, the resource exporter 52 sends a plurality of resources to the resource transformer 51 via the SAC (step S74). The resource transformer 51 receives the resource and transforms the resource so that it has the format required by the destination (step S75). After the resource format is converted, the resource transformer 51 transmits the converted resource to the resource importer 53 via SAC (step S76). After that, the resource importer 53 can receive the converted resource and provide the received resource to the destination device DV2.

The resource transmitted from the resource exporter 52 to the resource importer 53 via the resource transformer 51 can be set as a neutral resource. The resource exporter 52 can export a plurality of requested resources, convert the exported resources into neutral resources, and transmit the neutral resources. The resource exporter 52 can also export the pre-converted neutral resource and transmit the neutral resource. This process can be performed by considering the policies or export procedures determined by the DRM system used for the requested resources.

The resource importer 53 can transmit the received neutral resource to the destination device DV2 by considering the policy or import procedure determined by the DRM system used in the destination device DV2. For example, the received resource can be provided to the destination device DV2 after being encrypted to conform to the destination DRM. The received neutral resource can also be transmitted to the destination device DV2 without encryption.

On the other hand, the resource exporter 52, the resource transformer 51, and the resource importer 53 can report the resource transmission status to the resource processing controller 41. For this, the resource processing controller 41 needs to subscribe to specific events so that it can receive the resource transmission state (stages S64, S65, S66). A predetermined event is referred to as a resource transmission state event.

The resource processing controller 41 can request a subscription for a resource transmission status event before sending an operation control message. For example, the resource processing controller 41 requests the resource exporter 52, the resource transformer 51, and the resource importer 53 to subscribe to the resource transmission status event. The resource exporter 52, resource transformer 51, and resource importer 53 then check the validity of the request and, if the request is valid, send a response message that allows the event to be subscribed. However, if the request is not valid, the event subscription will be rejected. The response message can include a subscription identifier. Therefore, the resource processing controller 41 can subscribe to the resource transmission state event.

The resource processing controller 41 is an event joining entity, and the resource handlers 51 to 53 are event issuing entities. An event subscription entity can be an entity that subscribes to an event to receive information. The event issuing entity can be the entity that transmits the event message to the event joining entity.

When the resource transmission status event is subscribed, the resource processing controller 41 can receive the resource transmission status information event message including the resource transmission status information by the push or pull method. In the push method, the resource handler automatically pushes an event message (including resource transmission status information) every time the resource transmission status changes. Therefore, the transmission state of the resource can be automatically provided to the resource processing controller 41. In the pull method, the resource processing controller 41 retrieves event messages from the resource handler when needed.

When requesting a subscription for a resource transmission status event, the resource processing controller 41 provides the corresponding resource handler with information about whether the resource transmission status information is received by the push method or the pull method. In this description, as an example, it will be described that the resource processing controller 41 receives the resource transmission status information event message by the push method.

The resource processing controller 41 that subscribes to the resource transmission status event can receive an event message including transmission status information of the resource transmitted from each resource handler in a specific transmission session. In particular, when a plurality of resources are transmitted in a particular transmission session, the event message can include information representing the transmission state of each of the plurality of resources.

FIG. 7 shows an example of the configuration of the event message including the resource transmission status information. When multiple resources are transmitted in a single transmission session, the transmission status information for each resource is included in the event message as shown in Figure 7.

Referring to FIG. 7, the event message including the resource transmission status information is simply referred to as CTSE. The CTSE includes a transmission session identifier (also simply referred to as TSI) and multiple transmission state reports (also simply referred to as TSR).

The TSI is information for identifying the corresponding transmission session, and is information corresponding to the transmission session identifier included in the resource transmission request message received from the request client DV1 or the operation control message transmitted by the resource processing controller 41. In other words, the TSI included in the CTSE is substantially the same information as the transmission session ID included in the resource transmission request message or the operation control message.

Each TSR is information representing the transmission state of each resource. The TSR contains a resource index that can identify a particular resource among multiple resources. As described above, the resource index is a factor that can identify each resource transmitted in a specific transmission session by associating with each resource requested to be transmitted.

The TSR also includes transmission status information for each resource. The transmission status information may include a Started element indicating the start of resource transmission, a Completed element indicating the completion of resource transmission, a Transfer-Error element indicating a resource transmission error, a Progress element indicating the continuation of resource transmission, and the like. it can.

Therefore, when a plurality of resources are transmitted through a resource conversion chain composed of a resource exporter 52, a resource transformer 51, and a resource importer 53, the resource processing controller 41 uses information on the transmission status of each resource. Can be received. As will be described later, such behavior can be applied to licenses as well. In the case of a license, the operation can be performed by the license processing controller 42.

Table 1 shows the structure of the above event message including resource transmission status information in schema form.

<tables num="1"><img file="JP2010510568A_D0001.tif" /></tables>

See Table 1, the event message containing resource transmission status information, ie resource-transfer-status-event-type, has TIS (ie transfer-session-idendtifier) and TSR (ie transfer-status-type). Including. The transfer-status-type can be expressed in the schema form shown in Table 2 below.

<tables num="2"><img file="JP2010510568A_D0002.tif" /></tables>

Referring to Table 2, the TSR (ie, transfer-status-type) can include a resource-index that identifies the resource and a transfer-status that is the transmission status information of the resource.

The resource processing controller 41 can also transmit a specific event message to a specific client, for example, the request client RC1 in response to the received event message including the resource transmission status information. In this case, the request client RC1 needs to request the resource processing controller 41 to subscribe to the resource transmission status event in order to receive the resource transmission status information. For example, the request client RC1 can request the resource processing controller 41 to subscribe to the resource transmission status event at the time of the resource transmission request in order to subscribe to the event. In this case, the request client RC1 becomes the event subscription entity, and the resource processing controller 41 becomes the event issuing entity.

In this way, the request client RC1 can recognize the transmission state of each resource requested to be transmitted. When the request client RC1 has a user interface function, the request client RC1 can provide information on the resource transmission status in numerical or graphic form. In particular, when a plurality of resources are transmitted in one transmission session, the user can recognize the transmission state of each resource, so that the transmission state of the requested resource can be recognized in sequence.

On the other hand, the authenticated client can request the processing control unit to transmit the license. For example, there is a first client device with the first DRM installed and a second client device with the second DRM installed, and the user can use the first DRM resource stored in the first client device in order to use the first DRM resource. When attempting to transmit to a two-client device, the first client can transmit the resource to the destination (ie, the second client device) by using the resource transmission process. In this case, if the second client device intends to use the transmitted resource, an issue conforming to the second DRM is required. Therefore, the first client needs to request the transmission of the license.

FIG. 8 is a block diagram showing a system configuration related to license transmission.

As shown in FIG. 8, the processing control unit 40 has a resource processing controller 41 and a license processing controller 42. The resource processing controller 41 has been described earlier. The resource processing controller 41 and the license processing controller 42 can be provided anywhere in the local area or network area. The resource processing controller 41 and the license processing controller 42 can be arranged in separate areas. For example, the resource processing controller 41 can be placed on a specific device in the local area, and the license processing controller 42 can be placed on the service provider side of the network area. The resource processing controller 41 and the license processing controller 42 are not particularly limited in position.

The license processing controller 42 receives the license transmission request from the client 3. Upon receiving the license transmission request, the license processing controller 42 collects information on the entities contained in the system in order to determine the entities involved in the transmission or whether transmission is possible. The chain through which the licenses are then transmitted can then be formed under the control of the license processing controller 42.

In addition to the license processing controller 42, the license processing element 32 of the license registry 25 and the license processing unit 30 can be involved in the transmission of the license. Entities involved in the transmission of licenses can be located anywhere in the network area or local area. In some cases, a security authentication channel (SAC) can be established between specific entities for license information transmitted while ensuring security.

The license processing controller 42 may request the license registry 25 to transmit one or more neutral licenses in order to receive one or more neutral licenses. The neutral license can represent interoperable neutral license information that can be used to extract various DRM license information. A neutral license can be generated by using the corresponding DRM license by the license manager 24 when the user purchases a given DRM resource, and then the neutral license can be stored in the license registry 25. The license registry 25 can reside in the license manager 24, domain manager 22 or reference point controller 26. In some cases, the license registry 25 can reside on the client device 12. An entity that provides a neutral license during license transmission can be considered a license handler that performs the functions of the exporter.

A neutral license can include one or more resource chain information, manager information, principal information that can use the license, one or more usage model information, and the like. The use model information can be information that describes the usage authority for the resource.

The license processing controller 42 generates a new neutral license that is actually transmitted by using the provided neutral license. Various information such as the relationship between the resource and the principal entity that uses the resource, the destination, the mapping relationship of the principal entity that uses the resource, and the resource mapping relationship can be considered.

The neutral license generated by the license processing controller 42 is transmitted to the license processor 32 of the license processing unit 30. The license processor 32 is an entity that transmits the neutral license received from the license processing controller 42 to the receiving unit 900 of the destination native DRM. In this case, the license processor 32 converts the received neutral license into a license conforming to the destination DRM according to the method specified by the destination DRM, and provides the converted license to the native DRM receiver 900. be able to. License Shoriko 32, the neutral license Neite destination without performing conversion may be provided to the I Bed DRM receiver 900. In the latter case, the license conversion is performed by the destination DRM system itself. The license processor 32 and the native DRM receiver 900 execute the functions of the license converter and the functions of the license receiver, respectively.

The entity involved in the transmission of the license can send a license transmission status event message indicating the progress status of the license transmission and processing to the license processing controller 42. To this end, the license processing controller 42 needs to subscribe to the license transmission status event by requesting the relevant entity to provide the license transmission status event. The license processing controller 42 can provide the client 12 with information corresponding to the received license transmission status event message.

Upon receiving the license transmission status event message, the license processing controller 42 can transmit the event message corresponding to the license transmission status event message to the client 3. For this purpose, the client 3 needs to request the license processing controller 42 to transmit the license transmission status event message in order to subscribe to the license transmission status event.

On the other hand, the neutral license needs to change the content according to the use of the resource or the change of the environment in which the resource is used. For example, if the user can play the resource 5 times and the user has played the resource twice so far, the neutral license usage model information also has the resource play permission by considering that the resource has been played twice. Is updated to 3 times. Also, if a user sends a five-playable resource stored on a particular client device to another client device and allows the corresponding client to have two of the five play permissions, the client You need to update the device's resource replay permissions to replay three times. Neutral license information updates can be performed via renewal license events.

FIG. 9 is a flow diagram illustrating the process of executing a renewal license event between the license registry and the client.

Referring to Figure 9, client 3 requests a subscription for the renewal license event from license registry 25 (step S31). After receiving the request, License Registry 25 determines the validity of the subscription request. If the subscription is valid, the license registry 25 sends a response message permitting registration (step S32). Here, if the subscription request is not valid, the event subscription can be refused. The response message can include a subscriber identifier. The client 12 then acts as the event subscription entity and the license registry 25 acts as the event issuing entity (step S33).

Then, when the neutral license information is changed, the license registry 25 transmits a renewal license event message containing the change information to the client 12. The client 12 then reads the transmitted renewal license event message and recognizes that the neutral license information has changed. The client 12 can then update the license information.

FIG. 10 shows an example of the configuration of the renewal license event message.

Seen in Figure 10, the renewal license event message ULE contains a neutral license KT. Neutral License KT includes change field information FD and change state information UT to indicate what part of the neutral license has changed and how.

The change field information FD indicates which part of the neutral license KT has been changed. Examples of field information that can be specified in the modified field information FD can include manager information, principal information, resource identification information, and usage model information. The attribute name is assigned to the change field information FD of the neutral license KT. For example, the modified field information FD can have an attribute name of'field'.

The change status information UT indicates how the part represented by the change field information FD is changed in the neutral license IT. Examples of modified states that can be represented by the modified state information UT include Added information, Removed information, Modified-Old information, and Modified-New information. be able to. A specific attribute name can be assigned to the change status information UT of the neutral license KT. For example, the change status information UT can have an attribute name of'Update'.

For example, regarding the renewal license event message, a specific neutral license is included in the renewal license event message, and the part having the attribute name of'field'contained in the neutral license represents'Usage Model', and the attribute name of'Update' If the part with has represents'Modified-New', the neutral license represents the neutral license obtained after the usage model has been updated. In this case, if you define that the neutral licensed usage model has the right to play the resource 5 times, even if the usage model can now play the resource 5 times, the resource has been played more than 5 times before. Can be estimated.

In this way, the client 12 receives the transmitted renewal license event message from the license registry 25, so that the client 12 can recognize that the neutral license has been renewed. In FIG. 10, the client 12 acts as an event-subscribing entity and the license registry 25 acts as an event-issuing entity. However, this is only an example, and the present invention is not limited thereto. Therefore, renewal license events can be run between license registries.

As described above, the license registry can be included in the license manager, domain manager, reference point controller and client device. That is, a plurality of license registries can be provided in the DRM interoperability system. Therefore, if there is a change in the neutral license information stored in a particular license registry because multiple license registries share the neutral license information, the corresponding change state is changed to the other license registry to update the information. Need to be supplied to. For example, if the two license registers are included in the service provider's license manager and the user's client device, respectively, the neutral license renewal information can be exchanged after the two license registers subscribe to the renewal license event.

When implementing a DRM interoperability system for the first time, policy information can be provided from other entities to a particular entity. For example, when the domain manager is located in the local area, the domain manager needs to receive the policy information from a predetermined entity installed on the service provider side. In this case, a predetermined entity can be a policy provider. A policy provider is an entity that provides policy information according to the request of a specific entity, and the policy provider can be placed in a network area, for example, on the service provider side. For example, the policy provider can be placed in the license manager in the form of a unit function module.

The policy provider can provide policy information in response to a request from a particular entity (eg, a domain manager) or a particular event.

Figure 11 shows an example of the process by which a policy provider provides policy information to a domain manager via a request / response.

Referring to FIG. 11, when the domain manager 72 is placed in the local area, the policy provider 70 recognizes the domain manager 72 and requests the configuration information to evaluate the components contained in the domain manager 72 (step S80). ). The domain manager 72 can include a plurality of unit function modules, for example, the authenticator 76, the principal manager 75, and the like. Then, in response to the configuration information request, the domain manager 72 transmits the configuration information of the domain 72 configuration information (eg, authenticator 76 and principal manager 75) to the policy provider 70 (step S81).

Upon receiving the configuration information, the policy provider 70 reads the provided configuration information and selects the unit function module for which the policy information value needs to be set. According to the request from the selected unit function module (step S82), the policy provider 70 transmits the policy information to the corresponding unit function module (eg, authenticator 76 in FIG. 11) (step S83). Also, if there is a policy request from domain manager 72 (stage S84), policy provider 70 transmits policy information to domain manager 72 in response to the request (stage S85).

On the other hand, the policy provider 70 can also provide policy information by using the update change event as described below.

Figure 12 shows an example of the process by which a policy provider provides policy information via an event.

Referring to FIG. 12, when a device with domain manager 72 is placed in the local area, domain manager 72 requests policy provider 70 to subscribe to the update change event. The update change event can be an event that transmits the changed policy information by using an event message when the policy information is changed. Following the subscription request from Domain Manager 72, Policy Provider 70 grants the subscription by determining the validity of the event subscription request. Therefore, domain manager 72 subscribes to update change events (step S90). In this case, the domain manager 72 acts as the subscription entity for the update change event, and the policy provider 70 acts as the issuing entity for the update change event.

Meanwhile, Policy Provider 70 requests domain manager 72 to subscribe to the configuration change vent. A configuration change vent means an event in which configuration information is transmitted by using an event message when the configuration information of an event issuing entity (for example, information of a unit function module, etc.) is changed. Domain Manager 72 determines the validity of the event subscription request from Policy Provider 70 and grants the subscription. Policy Provider 70 then subscribes to the reconfiguration vent (Stage S91). In this case, the policy provider 70 acts as the joining entity for the reconfiguration vent, and the domain manager 72 acts as the issuing entity for the reconfiguration vent.

The domain manager 72 then transmits the configuration information of the domain manager 72 itself (eg, the information of the authenticator 76 and the principal manager 75) to the policy provider via the configuration change vent message (step S92). Policy provider 70 analyzes the received configuration change vent message, determines the policy information that corresponds to the modified configuration information, and requires domain manager 72 or policy information for an update change event message that contains the corresponding policy information. It is transmitted to the unit function module (for example, the authenticator 76 in FIG. 12).

The present invention has been illustrated and described in particular with reference to typical embodiments of the invention, but without departing from the scope of the invention as defined by the appended claims. It will be appreciated by those skilled in the art that various changes can be made.

<figref num="1">FIG. 5 is a block diagram of a digital rights management (DRM) interoperability system for realizing a resource transmission method or the like according to an embodiment of the present invention.</figref><figref num="2">It is a block diagram which shows the domain, the entity which constitutes a domain, and the correlation between the entity.</figref><figref num="3">It is a block diagram which shows the detailed structure of the processing control unit and the resource processing unit used for resource transmission.</figref><figref num="4">It is a block diagram which shows the example of arrangement of a resource processing controller and a resource handler.</figref><figref num="5">It is a flow chart which shows the process of transmitting a resource by using a resource processing controller and a resource handler.</figref><figref num="6">It is a figure explaining the example of a multi-transmission protocol.</figref><figref num="7">It is a figure which shows an example of the structure of the event message including the resource transmission state information.</figref><figref num="8">It is a block diagram which shows the structure of the system related to the transmission of a license.</figref><figref num="9">It is a flow chart which shows the process which executes the update license event between a license registry and a client.</figref><figref num="10">It is a figure which shows an example of the structure of the renewal license event message.</figref><figref num="11">It is a figure which shows an example of the process which a policy provider provides policy information to a domain manager through a request / response operation.</figref><figref num="12">It is a figure which shows an example of the process which a policy provider provides policy information through an event.</figref>

Code description

DV1 request device DV2 destination device RC1 request client RC2 destination client 41 Resource transmission controller 51 Resource Transformer 52 Resource Exporter 53 Resource Importer