RU2408150C2 - Method of managing data transmission, method of managing transmission of information content, method of acquiring information on processing information content and system for transmitting information content - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: management of data transmission in interoperable data medium is based on receiving a request for transmitting data from a client, gathering information on objects which must participate in data transmission, building a circuit which includes at least two objects using the gathered information on objects, transmitting the set of data over the circuit and receiving an event message for displaying the transmission state of data transmitted from at least one of the objects included in the circuit. Consequently, data transmission can be managed so that the set of data can be transmitted during a single session and the state of data transmission can be received as an event message.

EFFECT: high information content of data transmission.

20 cl, 49 dwg

Description

FIELD OF THE INVENTION

The present invention relates to a method for managing data transmission, a method for controlling the transmission of information, a method for acquiring information about processing information content and a system for transmitting elements of information content, and more particularly, to a method for controlling data transmission capable of efficient data transmission in an interoperable DRM environment , a method for controlling the transmission of information content elements, a method for acquiring information about processing information content desire, and a system for transmitting elements of information content related to this.

State of the art

In general, unlike analog information content, since digital information content can be copied without loss of information an unlimited number of times, digital information content can easily be subject to illegal copying and use. That is why, in order to provide a service for the transfer of digital information content, the technology of protecting information content must be supported, which can ensure stable protection of digital information content from illegal copying and use.

Digital Rights Management (DRM) is a common technology for protecting digital information content, capable of permitting the use of digital information content only to a legally registered user. Although DRM technically includes security technology, watermarking technology, anti-tamper technology, etc., DRM more accurately reflects the structure, not the technology.

DRM focuses on the complete prevention of illegal copying and use of information content. In DRM, digital content is converted into encrypted data in the form of a packet using encryption technology. Accordingly, even if the digital information content was accidentally obtained by a specific user, the digital information content cannot be used without a legal authentication process.

Most legal content services provided over a wired / wireless network, such as the Internet or a mobile network, can only be performed with DRM devices that support the DRM used by the service provider or provider of the relevant content. This is due to the technical and tactical closure properties of DRM.

On the other hand, the technical and tactical properties of DRM's confidentiality are preferred in order to protect the legality of the content. However, this is a problem limiting the user in the use of information content. The reason is that in order for a user to use digital content provided by a plurality of service providers, DRM devices or software using DRM where the used one is used by the service provider DRM must be included individually. In this case, the user must separately conclude a contract, make payment, perform authentication, etc.

The aforementioned problem worsens the flexibility of the distribution structure of the elements of digital information content. And finally, the problem causes the limitation of services for the transfer of digital information content.

Recently, this is intended to represent a structure in which closed DRM structures are compatible with each other. To enable different types of DRM to be compatible with each other, an interoperable DRM system is required that acts as an intermediary between closed DRMs. An interoperable DRM system can be implemented by defining system resources, as well as proposing a model of an operation that generates and manages certain system resources. In addition, in order to support an interoperable DRM system, various scenarios should be proposed that use certain system resources, as well as operation models.

Disclosure of the technical problem of the invention

The present invention provides a data transfer control method in which, in response to a client request for data transfer, a circuit is formed and used to transmit a plurality of information content elements.

The present invention also provides a method for controlling the transmission of content elements, in which a secure authentication channel is installed, capable of transmitting a plurality of content elements in a compatible DRM environment, and also a plurality of content elements can be efficiently transmitted in one session.

The present invention also provides a method of acquiring information about processing information content, in which a procedure for transmitting information content in a compatible DRM environment is acquired during the event.

The present invention also provides a system for transmitting content items in which a plurality of content items are transmitted to the destination system in one session in response to a client request.

Technical solution

According to an aspect of the present invention, a method for controlling data transmission in an interoperable data medium is provided, the method including the steps of: receiving a data transfer request from a client, collecting information about objects to be involved in data transmission, forming a chain including at least two objects, using the collected information about the objects, transmitting a plurality of data along the chain, as well as receiving an event message to display the status of the data transmission transmitted from at least her least one of the objects included in the chain. At this stage, the data may be either informational content or a license.

In the aforementioned aspect of the present invention, the step of receiving a data transmission request may include the step of receiving a transmission session identifier as well as a plurality of data identifiers, in addition, a plurality of data may correspond to a plurality of data identifiers.

In addition, the step of collecting information about objects that should participate in data transmission may include the steps of: requesting objects for information about objects, including information about functional characteristics, receiving information about objects received in response to a request, and also determining at least one piece of information about source devices, intermediary devices, destination devices, systems, and DRMs using received information about objects.

In addition, these at least two constituents of the object chain may include: an exporter, which exports a lot of data from the source, and also transfers the exported data, a converter that converts the set of data transmitted from the exporter into data having the format requested by the addressee, and also transmits the converted data, and the importer, which receives the data set transmitted from the converter, also provides the received data to the addressee.

On the other hand, these at least two constituent chains of an object may include: an exporter, which exports a lot of data from the source, and also transfers the exported data, and an importer, which receives a lot of data transmitted from the exporter, and also provides the received data to the addressee.

In addition, the step of forming the chain may include the steps of: transmitting a control message to at least two objects included in the chain, and establishing a secure authentication channel between the objects receiving the control message. At this stage of the transmission of the control message, information about the destination DRM can be provided to at least one entity.

In addition, the data transmission control method may further include the steps of: requesting at least one of the objects included in the chain to subscribe to a predetermined event capable of receiving an event message and receiving permission to subscribe to a predetermined event, at least one object that requests a predetermined event.

In addition, an event message for displaying a data transfer status may include at least either an event message for displaying a data transfer start, or an event message for displaying a data transfer in a chain, or an event message for displaying a data transfer end .

According to another aspect of the present invention, there is provided a method for controlling the transmission of content in an interoperable DRM system, the method comprising the steps of: determining content processors for transmitting a plurality of content items corresponding to a plurality of content identifiers when receiving a request message for transmitting information content to a predetermined destination, including a transmission session identifier and a plurality of identifiers of information content, and establishing a secure authentication channel for transmitting a plurality of elements of information content to a predetermined addressee by controlling certain information processing processors, as well as managing certain information processing processors so that a plurality of information content elements are transmitted to the addressee via an established secure channel authentication, by establishing one about the transmission session corresponding to the transmission session identifier.

In the aforementioned aspect of the present invention, the step of determining content handlers may include the steps of: collecting information about the content handlers included in the system, determining whether a transmission corresponding to a received request message for transmitting content should be performed based on the collected information, as well as definitions of information content processors for transferring between information processors included in the system neigh, when determining that the transmission is to be performed.

In addition, when defining content processors, if the format of the plurality of content items corresponding to the plurality of content identifiers is different from the format of the content required by a predetermined addressee, then a content processor configured to convert may be included in certain content processors format of information content.

In addition, the method for controlling the transmission of information content may further include the steps of: subscribing to a predetermined event by querying at least one of the specified content handlers to subscribe to a predefined event, and receiving an event message to display the transmission status each content item, from at least one content processor that is subscribed to a predefined being, after the transmission of many elements of information content to the addressee through the established secure authentication channel.

According to another aspect of the present invention, there is provided a method for acquiring information about processing information in an interoperable DRM system, the method comprising the steps of: determining information processors to transmit a plurality of content elements to a desired recipient by collecting information about information processors when received from a client message requesting the transmission of information content, and receiving an event message to display status ence processing each of the items of content transmitted from at least one of the determined handlers information content, after transmitting a plurality of content elements using certain information content handlers.

In the aforementioned aspect of the present invention, a method of acquiring information about the processing of information content may further include the steps of: requesting at least one of the information processors to subscribe to a predetermined event, and receiving a response message to display at least one a content handler requesting a predefined event is allowed to subscribe to the predefined event. At this stage, the step of requesting at least one of the content handlers to subscribe to a predetermined event may include the step of determining whether an event message has been received to display the status of the transmission of content transmitted by the push method (pushing or by subscription) or “pull” (push or request).

According to another aspect of the present invention, there is provided a system for transmitting content elements in an interoperable DRM system, including: a plurality of content processors and a control object that defines at least two content processors for transmitting a plurality of content elements, corresponding to a plurality of information content identifiers of a plurality of information content processors upon receipt from a client The messages with a request to transmit the content to a predetermined destination, comprising a plurality of content identifiers, and manages defined by at least two processors to transmit the information content sent the plurality of content items in a single session. At this stage, at least one of the at least two content processors transmits an event message to display the transmission status of each content item transmitted to the addressee to the control entity.

As described above, according to the present invention, various types of data transmission of an interoperable DRM system can be provided. In particular, since it is possible to control the transmission of a plurality of data so that a plurality of data is transmitted to the destination system in one session, it is possible to increase the transmission efficiency and adopt a data transmission state as an event message.

Brief Description of the Drawings

The above and other features and advantages of the present invention will become more apparent through a detailed description of illustrative embodiments of the present invention, made with reference to the accompanying drawings, in which:

1 is a block diagram illustrating a general representation (model) and basic functions of an interoperable DRM system according to an illustrative embodiment of the present invention;

2 is a block diagram illustrating a schematic structure of an interoperable DRM system according to an illustrative embodiment of the present invention;

Figure 3 illustrates an example in which a client requests a processing control node to transmit information content;

Figure 4 depicts an example in which a client requests a processing control node to transfer a license;

5 is a block diagram illustrating a domain, the objects that make up the domain, and the relationship between the objects;

6 depicts an example DPDU data packet format needed to select a reference point controller;

7 is a flowchart illustrating procedures for automatically selecting a reference point controller using DPDU;

Fig. 8 is a flowchart illustrating a method for selecting a reference point controller according to Example 1-2;

Fig. 9 is a flowchart illustrating a procedure for selecting a suitable candidate for a reference point controller according to Example 2-1;

Figure 10 depicts a block diagram illustrating a reference point controller, as well as connections between suitable candidates for a reference point controller for transmitting an information signal;

11 is a block diagram illustrating an example in which a conventional domain device and conventional suitable domain devices transmit an information signal;

12 is a block diagram illustrating a general view of the reference point intermediary controller;

13 is a flowchart illustrating a registration procedure of a reference point controller;

Fig. 14 depicts an example structure for managing unique information of a conventional device;

15 is a flowchart illustrating an authentication procedure of a conventional device;

Fig. 16 depicts an example of the structure of an interoperable DRM system for managing user information using a conventional device;

17 is a flowchart illustrating a procedure for registering a conventional device in a domain;

Fig. 18 is a block diagram illustrating the structures of a processing control unit and a content processing unit;

19 is an example illustrating the locations of a content processing controller and content handlers;

20 is an example illustrating other locations of a content processing controller and content handlers;

21 is a flowchart illustrating a procedure for transmitting content using a content processing controller and content handlers;

22 is an example illustrating a multiple transmission protocol;

23 is a flowchart illustrating a system structure for a content transfer procedure according to Example 3-2;

24 is a flowchart illustrating a procedure for transmitting content according to Example 3-2;

25 depicts a primary content conversion chain for transmitting one or more content items to a first destination device;

FIG. 26 illustrates a secondary content conversion chain for transmitting one or more content items to a second destination device; FIG.

27 is a flowchart illustrating a system structure for a content transfer procedure according to Example 3-3;

28 is a flowchart illustrating a procedure for transmitting content according to Example 3-3;

Fig. 29 depicts an example of a primary content transformation chain formed using a content processing controller;

30 depicts an example of a secondary content conversion chain formed using a content processing controller;

Fig. 31 is a block diagram illustrating a system for transmitting content according to Example 3-4;

32 is a flowchart illustrating a procedure for transmitting content according to Example 3-4;

Fig. 33 depicts an example of a primary content transformation chain formed using a content processing controller;

Fig. 34 depicts an example of structures of a first secondary content conversion chain, a second secondary content conversion chain, and a third secondary content conversion circuit introduced by the content processing controller;

Fig. 35 is a block diagram illustrating a structure of a system associated with a license transfer;

Fig. 36 depicts an example illustrating the functional modules of a block included in an object, as well as their functions;

Fig. 37 is an example illustrating a procedure for transmitting an event between two authenticated entities;

Fig. 38 is a flowchart illustrating a domain management method according to Example 4-1;

Fig. 39 is a flowchart illustrating a domain management method according to Example 4-2;

40 is a block diagram illustrating a system structure of an environment in which various types of DRM are compatible with each other;

Fig. 41 is a block diagram illustrating a detailed structure of a DRM region;

Fig. 42 is a block diagram illustrating the structure of an interoperable DRM system;

Fig. 43 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-1;

Fig. 44 is a functional flowchart illustrating a method of processing content using an interoperable DRM system according to Example 5-2;

Fig. 45 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-3;

Fig. 46 is a functional flowchart illustrating a method for processing content using an interoperable DRM system according to Example 5-4;

Fig. 47 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-5;

Fig. 48 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-6;

Fig. 49 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-7.

Reference Numbers:

10: Client node

20: Authentication and Management Node

30: License Processing Node

40: Processing control node

41: Content Processing Controller

50: Content Processing Node

51: Content Converter

52: Content Exporter

53: Content Importer

Preferred Embodiment

Next, with reference to the attached drawings, preferred embodiments of the present invention will be described in detail. In addition, certain technical terms are used to clearly describe illustrative embodiments with reference to the accompanying drawings. However, the present invention is not limited to certain specific technical terms, and each specific technical term includes all technical synonyms that function in a similar manner to achieve such an entity.

1 is a block diagram illustrating a general representation (model) and basic functions of an interoperable DRM system according to an illustrative embodiment of the present invention.

As shown in FIG. 1, the interoperable DRM system 1000 serves to provide services with interoperability between different DRM areas. The interoperable DRM system 1000 may perform a data interoperability control function f1, a data interoperability function f2, a state display function f3, a domain control function f4 f4, and the like.

The data interoperability control function f1 is used to control data interoperability so that the data is compatible with each other. At this point, the data may display content or a license. In particular, the data interoperability management function f1 includes an information content interoperability management function f1a and a license interoperability management function f2b.

The data interoperability function f2 may be a function of providing information content or license interoperability under the control of the data interoperability control function f1. For example, according to the data interoperability function f2, the data of system A or device A located in the DRM area A, for example, information content or a license can be transferred to system B or device B located in the DRM area B. Information content or license of system B or a device B located in the DRM region B can be transferred to a system A or a device A located in the DRM region A. In particular, the data interoperability function f2 may include the content interoperability function f2a and function f2b license interoperability.

The state display function f3 may be a state display function of the interoperable DRM system 100. For example, the state display function f3 may include event functions, for example, the channel forming function f3a of the event transmission function f3b, the event function f3c, associated with the conversion, etc.

The domain management function f4 may be a domain management function for authentication and client management. The domain management function f4 may include a registration point / control function f4a of the reference point controller, a conventional device control function f4b, and the like.

Next will be described in detail the structure and operation of the system to perform the above functions.

System structure and operation

2 is a block diagram illustrating a schematic structure of an interoperable DRM system in which various types of DRM are compatible with each other.

As shown in FIG. 2, an interoperable DRM system may include a client node 10, an authentication and control node 20, a processing control node 40, a content processing unit 50, and a license processing unit 30.

The above nodes can be formed from one or more objects. At this stage, objects can be modules or devices formed as software or hardware that perform predetermined unique functions. Each object can consist of a group of one or more functional modules of a block that perform predefined block functions. The object is installed in a predefined device for transmitting data to another object via a predefined interface. In addition, even if the objects belong to one node, the object can be installed or implemented in various devices. Devices may vary depending on runtime environments.

Next, the functions of the objects included in each node, operations on the interaction between the objects, as well as the characteristic structure and functions of each node will be described.

1. Function and operation of the client node

Client node 10 may include a client. A client is an entity that provides various functions so that a user can use the DRM interoperability service in conjunction with an authentication and control node 20 and a processing control node 40.

A client may be included in a user device. A device that includes a client is called a client device.

The client can be authenticated by requesting the authentication and control node 20 to authenticate the client. An authenticated client may request the processing control node 40 to transmit predetermined data, for example, predetermined information content or license, to the desired destination by calling a predetermined object. In this case, the destination can be a device or software system where DRM is installed that is different from DRM applied to predefined content or licenses, for example, another client device of the domain.

Figures 3 and 4 depict examples in which an authenticated client requests a processing control node 40 to transmit data. Figure 3 depicts an example in which the client requests the processing control node 40 to transmit information content. 4 depicts an example in which a client requests a processing control node 40 to transfer a license.

As described in FIG. 3, the client requests the content processing controller 41 of the processing control unit 40 to transmit the content. Then, the content processing controller 41 controls the content processing unit 50 so that the desired content is transmitted to the desired destination. At this stage, the content format and DRM of the desired content may be different from that required by the addressee of the content and DRM format. The content processing unit 50 processes the content so that the content satisfies the conditions required by the addressee, and also transfers the processed information content to the addressee. Transfer and processing procedures will be described below with reference to FIGS. 18-34.

In addition, as shown in FIG. 4, the client requests the license processing controller 42 of the processing control node 40 to transfer the license. Then, the license processing controller 42 controls the license processing unit 30 so that the desired license is transferred to the desired destination. At this stage, the format of the required license may differ from the format required by the addressee of the license. The license processing unit 30 processes various properties so that the conditions required by the addressee are satisfied, and also transfers the result of the processing to the addressee. Procedures for processing and transferring a license will be described below with reference to FIG. 35.

On the other hand, the client may include the usual functions of the client, for example, a function of using (or reproducing) information content, a user interface function, and the like. In this case, the client may be the endpoint for the consumption of information content.

The client must be authenticated as a legal client, and also be managed by the management and authentication node 20. For the smooth execution of the above process, an interoperable DRM system can introduce the concept of a domain.

The domain is the main unit of the trust structure of DRM technology, and also displays the zone to which the interoperable DRM system is actually applied. A domain can be configured with a group of authorized devices or systems. For example, a domain may include a group of authorized client devices. In this case, although the client devices of the domain include various DRM content items, they can share content items.

2. Function and operation of the authentication and control node

5 is a block diagram illustrating a domain, objects constituting a domain, and a relationship between objects. 5 illustrates objects related to authentication and client management.

5, an interoperable DRM system generates a domain 5. Domain 5 can be formed taking into account the physical location of the client device 12. In particular, domain 5 is formed using authorized client devices 3 located in a predefined physical area. Alternatively, domain 5 can be formed exclusively using logically authenticated client devices, without regard to the physical location of client device 12.

In the present invention, as described above, although the domain is formed using client devices 3 located in a predetermined local area taking into account the physical locations of the client devices 3, a case is illustrated in which client devices outside the predefined local areas in the network area also subscribe to the domain. Despite this, this is an example of an embodiment. The present invention is not limited to them.

For the formation of domain 5 requires a local environment. At this stage, the local environment displays the environment in which the physical network is prepared taking into account that devices located in a predefined local area can interact with each other, and the physical network in it can interact with an external network.

As an example, to represent the local environment, there is a home network system. In general, home devices, various sensors, security system devices and the like located in the home network system can communicate with each other over a wired / wireless local area network, and can also communicate with an external network such as the Internet, using a communication node, for example, a home gateway. A local environment may be formed using two or more cooperating network devices, in addition to a home network system.

The next local area is supposed to be the area in which the aforementioned local environment is prepared. A plurality of client devices 3 may be present in the local area. Client 3 included in client device 12 can be authenticated as a legal client by requesting the authentication and management node 20 to authenticate client 3. A device including the authenticated client 3 is client device 12. Various DRM content elements may be used between client devices 3 in a licensed area.

Accordingly, the user sets his home zone in the local area and forms a domain using devices that include various DRMs in the home zone. Then the content elements are distributed between the devices and used.

In this case, the client located in the external network area, in addition to the clients 12 located in the local area, can also be provided with the service using authentication. In this case, this is necessary to distinguish the state of a client that is authenticated on the network from the state of a client 3 that is authenticated in the local area, as well as for separate state management. For this state, authenticated clients can be classified into remote state and local state, and can also be managed.

5, the authentication and management node 20 used to authenticate and manage client 3 includes a domain manager 22, a license manager 24, and a reference point controller 26.

The domain manager 22 is configured to manage domain 5. For example, the domain manager 22 can perform the functions of forming domain 5, deleting domain 5, connecting clients to domain 5, removing clients from domain 5, registering controller 26 reference points, and the like.

The domain manager 22 may be located at any location on a local or network area. For example, in the example shown in FIG. 5, the domain manager 22 is in a network area. In this case, the domain manager 22 may interact with the reference point controller 26 and the client 3. Alternatively, the domain manager 22 may be located in a local area. In this case, the domain manager is included in the device located in the local area for interaction with the reference point controller and the client.

The license manager 24 is configured to manage user license information. For example, the license manager 24 may provide the registration function for the user, as well as the function of a regular interactive services manager, which stores and manages the license information. The license manager 24 may perform the functions of creating user names, deleting user names, associating license information with user names, creating license information, deleting license information, and the like.

The license manager 24 may be located in a network area, for example, on a service provider's server. In addition, the license manager 24 may reside in a network area, such as a service provider's server. Alternatively, the license manager 24 may reside in a local area. That is, the domain manager 22 and the license manager 24 can be located at any location in the local or network area.

An anchor point controller 26 checks whether a predetermined object is in the local area, and also provides credentials that confirm that the object is in the local area to the checked object. For this, the reference point controller 26 may determine the area of the local area. At this stage, the zone of the local area can be determined using the physical distance, the number of jumps, response time (response), etc.

The reference point controller 26 checks whether the client 3 is in the local area, according to the request of the client 3. If it is determined that the client 3 is in the local area, the reference point controller 26 can provide domain credentials that confirm that the client 3 is in the local area. Domain credentials can be provided to the domain manager 22 when client 3 requests the domain manager 22 to authenticate client 3. Domain manager 22 confirms that client 3 is in the local area and also authenticates client 3.

In addition, based on the domain credentials, the domain manager 22 determines what state (remote or local) client 3 has. The domain manager 22 can limit the number of clients that access the domain manager 22 and have a remote state by determining the status of client 3 to prevent accessing multiple clients to the domain over the network, as well as to increase security.

The reference point controller 26 may be located in a local area. In particular, the reference point controller 26 may be defined as a device located in a local area. Although it is advantageous for the reference point controller 26 to be defined as a device, such as a television set top box, desktop computer and the like, which has many computing resources and is also stationary, the reference point controller 26 can be determined as a highly mobile device.

The reference point controller 26 may be selected according to a predetermined procedure after the initial formation of the domain. In particular, after the initial formation of domain 5, a device is selected to perform the function of a reference point controller for determining the zone of a local area. The selected device must be defined as the controller 26 reference points. At this stage, a specific reference point controller 26 is registered with the domain manager 22. Client 3 can then request the domain manager 22 about the reference point controller 26.

Selection of control points

There are three ways to select an anchor point controller.

In the first method, devices in need of a domain subscription exchange device information with each other, and also compare device information according to a predefined algorithm so that the most suitable device is selected as the reference point controller. The selected reference point controller must inform the domain manager that the device is selected as the reference point controller. Then the device must be registered in the domain.

In the second method, devices that need to be registered in the domain transmit information about the device to the domain manager, and also, based on the transmitted device information, the domain management object selects the reference point controller.

In a third method, the reference point controller is selected using predetermined information. At this stage, predefined information can be set by the administrator or user. Alternatively, predetermined information may include arbitrarily determined information. For example, if an administrator or user enters predefined information into a domain manager, then the domain manager can select the reference point controller based on the predefined information. Alternatively, a reference point controller can be installed by allowing an administrator or user to directly select a device to use as a reference point controller.

Three of the above methods will be described in detail below. For ease of understanding, the first aforementioned method for selecting a reference point controller is called Example 1-1. The second way to select the reference point controller is called Example 1-2. The third way to select the reference point controller is called Example 1-3.

Example 1-1

Before describing the selection procedure for the GCP controller, the format of the domain payload data block (DPDU) is determined. DPDU is a standard data format for transmitting device information to each device after selecting a reference point.

6 depicts an example DPDU data packet format needed to select a reference point controller.

6, a DPDU is generated using domain headers and domain payloads.

The domain header includes an identifier of the device’s functional characteristics (hereinafter abbreviated DC-ID), a domain identifier (hereinafter abbreviated D-ID) and a device object identifier (hereinafter abbreviated DE-ID).

DC-ID is information used to identify a value that determines the functional characteristic of a device. At this stage, the value defining the functional characteristic may be information for displaying the functional characteristic of the device relating to a predefined element, for example, the residual amount of energy, hardware specifications, network connection speed, network functional characteristics, going beyond, system stability, computing resources , consumption of resources, etc. An arbitrary value can be assigned by the DC-ID, according to a standard predefined by the administrator, or it can be generated by the corresponding device before or after the device enters the domain. DC-ID is the standard for selecting the most suitable device after selecting a reference point controller.

D-ID is the information used to classify domains according to device environments and properties. As described above, the domain may be a domain classified according to the classification standard of physical domains, or it may be a domain classified using a logical authentication service. Accordingly, the D-ID is information that classifies domains according to physical domains, or is information that classifies domains according to logical services.

DE-ID is information used to identify individual devices belonging to a domain.

On the other hand, a domain payload is an area for recording general data and error checking information. At this stage, the general data displays information about the device and DRM reliability system. In addition, error checking information may display error checking information of the DPDU.

As described above, the DPDU includes information to distinguish the functional characteristics of various domain-subscribed devices. Accordingly, devices located in the domain exchange DPDUs with each other, and also compare their functional characteristics with each other. Accordingly, a suitable device may be selected, and a suitable device may also be determined as a reference point controller. Next, the above processes will be described in detail.

7 is a flowchart illustrating a procedure for automatically selecting a reference point controller when using a DPDU.

In Fig. 7, at the beginning of the procedure, for subscribing to a domain, devices (for example, client devices) set the X-values of the DC-ID, the Y-values of the D-ID and the Z-values of the DE-ID identifier (step S1).

At this stage, the DC-ID sets the values assigned according to a predefined standard or generated in the respective devices. These two cases will be described separately below.

1. A case in which DC-ID values are assigned by an administrator according to a predefined standard.

The administrator determines the functional information of each device using a predetermined control device, converts the functional information into a value defining a functional characteristic according to a predefined standard, and assigns a value defining a functional characteristic to the DC-ID value of the device. At this point, the control device may be a predefined device located in a domain, a device located in another communication location, or a predefined system located in a network area (for example, a domain manager).

For example, after determining the DC-ID value based on the residual amount of energy, the administrator checks the residual amount of battery energy of each device in the domain, and the remaining amount of battery energy is displayed as numbers, according to a predefined standard, after which the devices are assigned DC-ID values. Then, the DC-ID values of the devices are determined, that is, the DC-ID of the device A = 4, the DC-ID of the device B = 8, and the DC-ID of the device C = 2.

2. A case in which DC-ID values are generated by corresponding devices.

Each device determines the information on the functional characteristics, the information on the functional characteristics is converted into a value defining the functional characteristic according to previously stored information, after which a value defining the functional characteristic is assigned to the DC-ID value.

For example, after determining the DC-ID values based on the residual amount of energy, the device checks the remaining amount of battery energy, the remaining amount of battery energy being displayed as numbers according to the previously saved display table of the remaining amount of battery energy, and then the DC-ID values are generated. Then, the DC-ID values of the devices are determined, that is, the DC-ID value of the device is A = 4, the DC-ID of the device is B = 8, and the DC-ID of the device is C = 2. At this stage, the table for displaying the remaining amount of battery energy can be received from the manager device as well as saved. Alternatively, a table displaying the residual energy of the battery can be stored during the manufacture of the product.

Example 1-1 assumes that since the battery capacity is large, the DC-ID value is set small. In this case, since the DC-ID value becomes small, the device has high functional characteristics. However, the present invention is not limited to this. Alternatively, it can be assumed that since the battery capacity is small, the DC-ID value is set to small.

In addition, the functional characteristics of the device can be formed on the basis of hardware specifications, network connection speed, network functional characteristics, going beyond the limits, system stability, computing resources, resource consumption, etc., in addition to the residual amount of energy. The DC-ID value can be not only a prime number, but also various types of information.

On the other hand, the D-ID is set as a unique amount or information data for displaying the domain to which the device subscribes. In addition, the DE-ID value of each device is initialized as codes to distinguish the devices from each other. The D-ID and DE-ID values can be assigned by the administrator, or can be generated by the corresponding device.

As described above, after the installation of the DC-ID and D-ID for each device, the device sequentially or simultaneously transmits to the neighboring devices a DPDU including the set information (step S2).

The device can then receive the DPDU transmitted from another device (step S3). After the predefined device has received the DPDU, the corresponding device extracts the DC-ID value V included in the domain header of the received DPDU (step S4), and compares the extracted DC-ID value with the device DC-ID identifier X value (step S5) . On the other hand, if the DPDU has not been received, it is determined whether the set time T1 has expired (step S12). V represents the DC-ID value of the DPDU, which is received from another device. In a device that transmits DPDU, the DC-ID value may be X.

Regarding the result of comparing the DC-ID values, if the DC-ID value of the device is less than the received DC-ID value, the device deletes the received DC-ID value (step S6). In this case, the reason is that the device that receives the DC-ID has a higher energy capacity, which is a functional characteristic, compared with the device that transmits the DC-ID.

On the other hand, with respect to the result of comparing the DC-ID values, if the DC-ID value of the device is greater than the received DC-ID value, the device extracts the D-ID information W included in the domain header of the received DPDU (step S7) and checks if it is identical whether the extracted information W of the device information Y D-ID (step S8). An anchor point controller can be sequentially selected in the same domain by checking received D-ID information. W represents the D-ID value of the DPDU received from another device. In a device that transmits DPDU, the DC-ID value may be Y.

Regarding the result of the D-ID check, if the received D-ID of the device is identical to the D-ID of the device, the device stops transmitting the DPDU (step S9). The reason is that a device that has a large capacity is in the same domain. This may indicate that the device cannot select the reference point controller.

On the other hand, regarding the verification result, if the received D-ID is different from the D-ID of the device, then the device regards the received DPDU as a DPDU received from a device located in another domain, and subsequently transmits the DPDU. At this stage, the device transmits the DPDU to another device, and also checks whether the set time T2 has expired (step S10).

At this stage, if the DPDU was not received after the set time T2 has elapsed, or if the DPDU, in which the DC-ID is less than the DC-ID of the device, and the D-ID identical to the D-ID of the device has not been received, the device has The highest functional characteristics in the domain. Accordingly, the device is selected as the reference point controller, which is a representative in the domain (step S11). The device selected as the reference point controller informs the domain manager that the device is selected as the reference point controller. The device registers as a reference point controller. Herein, a registration procedure will be described with reference to FIG. 13.

Software that can act as a reference point controller can be installed on a device that is selected as a reference point controller. Software is pre-installed, in the off state. After selecting a device as a reference point controller, software is activated and installed according to the command of the domain manager. Alternatively, a domain manager or other device may download software to the selected device that can act as a reference point controller. It is assumed that the domain devices that participate in the selection of the reference point controller satisfy the basic conditions for performing the function of the reference point controller. At this stage, the basic conditions may indicate that disabled software is included in the specifications of either hardware or software, where the function of the reference point controller can be performed.

As described above, according to Example 1-1, related to the selection of the reference point controller, the device with the highest functional characteristics can be selected as the reference point controller by exchanging DPDU data packets between the devices. The above description is an example. Setting functional characteristics using DC-ID, comparing functional characteristics, etc. may be changed without departing from the essence and scope of the present invention.

Example l-2

Next, Example 1-2 will be described, which is another example of a method for selecting an anchor point controller.

In the method for selecting the reference point controller of Example 1-2, devices (for example, client devices) that need to be registered in the domain transmit the device information to the domain manager and also, based on the transmitted device information, the domain manager selects the reference controller points. At this stage, information about the device may include information about the domain to which the device is subscribed, information about the functional characteristics of the device, device identification information, and the like. For example, device information may be DPDU.

Fig. 8 is a flowchart illustrating a method for selecting a reference point controller according to Example 1-2.

In Fig. 8, at the beginning of the procedure, for subscribing to a domain, the devices set the X-values of the DC-ID, the Y-values of the D-ID and the Z-values of the DE-ID identifier (step S20). At this stage, the DC-ID sets the values assigned according to a predefined standard or generated by the corresponding devices.

For example, if the standard DC-ID value is the specification of a central processing unit (CPU) located in the device, then the DC-ID value of each device is assigned by the administrator. Alternatively, the DC-ID value of each device is set as the generated value defining the functional characteristic. For example, the DC-ID value of the device A = 4, the DC-ID value of the device B = 2, the DC-ID value of the device C = 3, and the DC-ID value of the device D = 8.

At this stage, since the specifications of the CPU are wide, the DC-ID value is assumed to be small. In particular, as the DC-ID value becomes small, the device has high functional characteristics. However, the present invention is not limited to this. Alternatively, it can be assumed that the DC-ID value becomes small because the battery capacity is small. In addition, according to runtime environments, information about other hardware other than the central processor, energy information, and the like, can be applied to the functional characteristics of the device in various types.

D-ID is set as a unique quantity or information data to display the domain to which the device subscribes. In addition, the DE-ID value of each device is initialized as codes to distinguish the devices from each other. The D-ID and DE-ID values can be assigned by the administrator or generated by the corresponding device.

As described above, after the installation of the DC-ID and D-ID for each device is completed, the device transmits a DPDU to the domain manager including the set information (step S21). DPDU can be transmitted within a predetermined time. For a predetermined time, the domain manager maintains a wait state. After a predetermined time has elapsed, the domain manager no longer receives DPDUs.

The domain manager compares with each other the DC-ID values included in the domain header received from DPDU devices (step S22), and also retrieves the device having the lowest DC-ID value, that is, the device having the highest functional characteristics (step S23). After removing the device having the highest functional characteristics, the domain manager checks the device D-ID (step S24) and also checks whether the D-ID is identical to the identifier (ID) of the newly formed domain. If the D-ID is identical to the identifier (ID) of the newly formed domain, then the device is selected as the reference point controller (step S25). As described in Example 1-1, the function of the reference point controller can be installed in the device selected as the reference point controller.

Regarding the result of the D-ID check, if the D-ID of the device is not identical to the newly generated domain ID, then the DC-ID values of the devices, with the exception of the corresponding device, are compared with each other, after which the device with the highest functional characteristics is searched. The device with the highest functional characteristics, can be selected as a controller of reference points.

On the other hand, in the above example 1-2, the reference point controller is selected based on the functional characteristics of each device. Alternatively, the reference point controller may be selected based on the degree of correspondence with the reference information, the creation of the user, and the like, in addition to the functional characteristics.

For example, if devices that need to be registered in the domain transmit device information to the domain manager, including device hardware specifications, then the domain manager can select the most suitable devices by comparing the transmitted device information with the predefined specification information. In addition, the domain manager can select the device as the reference point controller, according to the device information that was previously determined by the user from the device information transmitted from each device.

Example 1-3

In the method for selecting the reference point controller, according to Example 1-3, the reference point controller is selected based on the installation information that is pre-installed by the administrator or user, or is set arbitrarily. For example, if an administrator or user enters installation information into a domain manager, then, based on the installation information, the domain manager can select the reference point controller. Alternatively, the administrator or user can directly select the device that the user will use as a reference point controller, as well as install a reference point controller. Accordingly, in Example 1-3, the device desired by the administrator or user, or any other device, is selected as the reference point controller.

Using examples 1-1 to 1-3, a method for selecting an anchor point controller was described that defines the zone of the local area after the initial formation of the domain. After selecting the reference point controller, the zone of the local area in which the client subscribes to the domain in the local state can be determined by the reference point controller.

Alternatively, a domain manager or license manager can be located at any location in a local area or in an external network area. If the domain manager or license manager is located on an external network, secure communications that reliably interact with the domain must be supported.

In contrast, since the reference point controller is an object that defines the zone and environment of the local area in the local area, the reference point controller must be in the local area, unlike the domain manager or license manager. At this stage, the reference point controller periodically and continuously exchanges information signals with the domain manager to confirm that the reference point controller is operating in normal mode.

If the domain manager has not received the information signal from the reference point controller for a predetermined time, this means that the reference point controller is not working in normal mode. In particular, the reference point controller may not be suitable. Alternatively, the pivot point controller may be inappropriate due to the entry of the pivot point controller into an external area that is not connected.

In this case, client devices located in the local area that subscribe to the domain can unusually use content elements. In fact, since the reference point controller can be installed in a mobile phone, personal digital device (PDA) and the like, the reference point controller can enter an external area that is not connected. In this case, the control point controller may not work properly.

Accordingly, in the present invention, a preparation method is disclosed to prevent malfunctioning of the reference point controller. Initially, the concept of a suitable candidate for the reference point controller is introduced. A suitable candidate for a reference point controller displays a device that replaces the reference point controller in cases where the reference point controller does not work correctly. A suitable candidate for the reference point controller can be selected after the initial formation of the domain or selected, according to the domain manager, after the formation of the domain.

Selection and operation of a suitable candidate for a reference point controller

There are four ways to select a suitable candidate for a reference point controller.

In the first method, devices located in the domain, with the exception of the current reference point controller, exchange information about the device with each other. Information about the device is compared among themselves on the basis of a predefined algorithm, for example, the algorithm described in example 1-1, after which a suitable candidate for the reference point controller is selected. For example, devices exchange among themselves (information about) functional characteristics. The device with the highest functional characteristics is selected as a suitable candidate for the reference point controller. The selected suitable candidate for the reference point controller informs the domain manager that the device is selected as the suitable candidate for the reference point controller.

In the second method, devices located in the domain transmit information about the device to the domain manager (for example, DPDU, which includes functional characteristics), and the domain manager selects a suitable candidate for the reference point controller based on the device information, similar to choosing the reference point controller according to the above example 1-2.

In the third method, devices located in the domain transmit information about the device to the reference point controller, and then, based on the device information, the reference point controller selects a suitable candidate for the reference point controller. In this case, after selecting the reference point controller, the reference point controller must transmit information about the selected suitable candidate for the reference point controller to the domain manager.

In the fourth method, a suitable candidate for the reference point controller is selected based on predefined information. At this stage, predefined information can be set by the administrator or user. Alternatively, the predetermined information may include arbitrary set information.

Four of the above methods will be described in detail below. For ease of understanding, the first aforementioned method of selecting a suitable candidate for the reference point controller is called Example 2-1. The second way to select a suitable candidate for the reference point controller is called Example 2-2. The third way to select a suitable candidate for the reference point controller is called Example 2-3. A fourth method for selecting a suitable candidate for the reference point controller is called Example 2-4.

Example 2-1

Fig. 9 is a flowchart illustrating a procedure for selecting a suitable candidate for a reference point controller according to Example 2-1. Figure 9 illustrates the procedure for automatically selecting a reference point controller using the functional characteristics of the device.

The procedure for selecting a suitable candidate for the control points controller, according to example 2-1, can begin after the procedure for selecting the control points controller after the domain has been formed. Alternatively, the procedure for selecting a suitable candidate for the reference point controller, according to example 2-1, can begin, according to the command to launch an object, for example, a domain manager, at any time after the formation of the domain.

As shown in FIG. 9, after the start of the procedure, those in the device domain, with the exception of the reference point controller, set the device information (step S30).

Information about the device may include information about the functional characteristics, domain information, identification information of the device, and the like. In this case, information about the functional characteristics may include information about the residual amount of energy of the device, hardware specifications, network connection speeds going beyond system stability, etc. In addition, the performance information may be a number, similar to the DC-ID value. Alternatively, information on functional characteristics may be various types of information.

After the installation of device information (information about functional characteristics, domain information, device identification information) for each device is completed, the device converts the installed information into regular packets, for example, the device places the installed information in DPDU, and sequentially or simultaneously transfers the DPDU to another device ( step S31).

Then, each device receives a normal packet transmitted from another device (step S32), compares the information on the functional characteristics included in the received packet with the functional characteristics of the device (step S33), and then refuses to choose one device (the device that transmits the packet or the device that receives the packet) (step S34).

For example, a device that receives a packet compares information about the functional characteristics of the received packet with information about the functional characteristics of the device. If the functional characteristics in the information on the functional characteristics of the received packet are higher than the functional characteristics of the device, then the device stops transmitting the DPDU. That is, the device that receives the packet cannot select a suitable candidate for the reference point controller. At this stage, a procedure can also be performed to check whether the device that transmits the packet is in the same domain as the device that receives the packet based on information about the received packet. On the other hand, if the functional characteristics in the functional information of the received packet are lower than the functional characteristics of the device that receives the packet, then the packet is deleted. That is, the device that transmits the packet cannot select a suitable candidate for the reference point controller.

In conclusion, after performing the above procedure, only the device having the highest functional characteristics remains (step S35). Then, the remaining device is selected as a suitable candidate for the reference point controller (step S36). The selected device informs the domain manager that the device is selected as a suitable candidate for the reference point controller.

The domain manager manages information about the selected suitable candidate for the reference point controller. If an error occurs in the GCP controller, a suitable candidate for the GCP controller can be used as a new GCP controller.

On the other hand, in order of priority, a plurality of suitable candidates for the reference point controller can be registered in the domain manager. In particular, the procedure for selecting the first suitable candidate for the reference point controller is performed, after which the first suitable candidate for the reference point controller is registered. The procedure for selecting the second suitable candidate for the reference point controller is carried out, after which the second suitable candidate for the reference point controller is registered. The above procedures are performed repeatedly, in connection with which the desired number of suitable applicants for the reference point controller can be registered.

After registering a plurality of suitable candidates for the reference point controller, the reference point controller can be replaced in order of priority. At this stage, the registered set of suitable candidates for the control points controller should periodically confirm that suitable candidates for the control points control work normally. The confirmation procedure will be described in detail later.

Example 2-2

In the method of selecting a suitable candidate for the reference point controller, according to Example 2-2, the devices located in the domain of the device transmit information about the device to the domain manager, and then, based on the transmitted device information, the domain manager selects the suitable candidate for the reference point controller.

The method is similar to the method of selecting the control points, according to example 1-2. In Example 1-2, to subscribe to a domain, devices transmit device information to the domain manager, after which, based on the transmitted device information, the domain manager selects the most suitable device and also registers the selected device as a reference point controller.

In Example 2-2, the devices in the domain of the device, with the exception of the reference points controller, transmit device information to the domain manager, after which, based on the transmitted device information, the domain manager selects the most suitable device and also registers the selected device as a suitable applicant to the reference point controller.

At this stage, device information may include functional information that displays the functional characteristics of the device according to a predefined standard. A domain manager can register devices by prioritizing devices based on functional characteristics information transmitted by devices in a downward sequence of functional characteristics.

For example, a domain manager can select and register many suitable candidates for a reference point controller in the following sequence: the first suitable candidate for a reference point controller, which can replace the reference point controller first, the second suitable candidate for a reference point controller and the third suitable candidate for a controller reference points, according to information about the functional characteristics of each device. After registering a plurality of suitable candidates for the reference point controller, suitable candidates for the reference point controller replace the reference points controller in the order of assigned priorities.

On the other hand, the procedure for selecting a suitable candidate for the reference point controller can be performed after selecting the reference point controller. Suitable candidates for the GCP controller can be selected after completing the selection of the GCP controller described in Example 1-2, according to the runtimes. That is, the first suitable candidate for the reference point controller, the second suitable candidate for the reference point controller, etc., is selected after selecting the reference point controller. For example, to subscribe to a domain, after the domain is formed, the devices transmit information about the functional characteristics to the domain manager, after which, based on the transferred information about the functional characteristics, the domain manager can select the reference points controller, the first suitable candidate for the reference points controller, the second suitable candidate to the control point controller, etc.

Example 2-3

In the method of selecting a suitable candidate for a reference point controller, according to Example 2-3, the devices located in the domain transmit information about the device to the domain manager, and then, based on the transmitted information about the device, the reference point controller selects suitable candidates for the reference point controller.

The method for selecting a suitable candidate for a reference point controller, according to example 2-3, is essentially the same as the method for selecting a suitable candidate for a reference point controller, according to example 2-2, except that the reference point controller selects suitable candidates for a reference point controller .

Information about the device transmitted to the reference point controller may include information on the functional characteristics displaying the functional characteristics of the device. An anchor point controller can register devices by prioritizing devices based on functional characteristics information transmitted by devices in a downward sequence of functional characteristics. For example, the GCP controller can select and register many suitable candidates for the GCP controller in the following sequence: the first suitable candidate for the GCP controller, which can replace the GCP controller first, the second suitable candidate for the GCP controller and the third suitable candidate for reference point controller, according to information about the functional characteristics of each device. After registering a plurality of suitable candidates for a reference point controller, suitable candidates for a reference point controller can replace the reference point controller in priority order.

On the other hand, after selecting the reference point controller, the reference point controller registers the selected suitable candidate for the reference point controller in the domain manager. In addition, even after selecting a plurality of controllers of reference points in order of priority, the reference point controller transmits a selection history to the domain manager. Accordingly, in the case where the reference point controller is unsuitable or enters an area that has not been connected for a long time, a suitable candidate for the reference point controller replaces the reference point controller. Therefore, the service is usually provided.

Example 2-4

In the method of selecting the reference point controller, according to Example 2-4, a suitable candidate for the reference point controller is selected based on the installation information that is pre-set by the administrator or user or is set arbitrarily. For example, if an administrator or user enters installation information into a domain manager or reference point controller, then, based on the installation information, the domain manager or reference point controller can select the reference point controller.

The installation information may include information about a plurality of suitable applicants for the reference point controller to which the priorities are assigned. In particular, the domain manager or the reference point controller may select a plurality of suitable applicants for the reference point controller in the priority order included in the installation information. For example, device A is selected and registered as the first suitable candidate for the reference point controller, and device B is selected and registered as the second suitable candidate for the reference point controller. Then, if an error occurs in the GCP, the first suitable candidate for the GCP can replace the GCP. If an error occurs in the first suitable candidate for the reference point controller, the second suitable candidate for the reference point controller can replace the first suitable candidate for the reference point controller.

In the case when the domain manager selects suitable applicants for the reference point controller, after the formation of the domain, the domain manager selects the reference point controller, and at the same time appoints suitable applicants for the reference point controller in a predefined priority order. Then, if the reference point controller is inappropriate, then it is possible to deal with the error flexibly and quickly. On the other hand, in the case where the reference point controller selects suitable candidates for the reference point controller, after selecting the reference point controller, the reference point controller can, based on the installation information, appoint suitable candidates for the reference point controller to replace the reference point controller.

On the other hand, the administrator or user can directly select the device that will be used as a suitable candidate for the reference point controller without using a domain manager or reference point controller. In this case, the selected suitable candidate for the reference point controller must inform the domain manager that the device has been selected as the suitable candidate for the reference point controller.

Using examples 2-1 to 2-4, a method for selecting suitable reference point controllers has been described. In the case in which the reference point controller is already selected, even if an error occurs in the reference point controller, a suitable candidate for the reference point controller can replace the reference point controller. In addition, the stability and flexibility of providing services in a domain can be achieved by establishing a set of suitable applicants for the reference point controller in a predetermined priority order.

Suitable candidates for the reference point controller can have the following functions.

1. Function of the reference point controller: for example, measuring spatial proximity to a predefined device, issuing domain credentials, etc. The function of the reference point controller has been described before.

2. The function of receiving and transmitting an information signal: a suitable candidate for a reference point controller should transmit an information signal to inform that a suitable candidate for a reference point controller is working normally with a reference point controller, etc., via a predefined interface.

3. The function of establishing the conditions of unacceptability: the function of establishing conditions for distinguishing the unacceptability of an information signal. For example, a restriction on the waiting period, an account limit, a zone restriction, etc. can be set.

4. The function of informing the domain manager: the function of supporting the data structure and interface for interacting with the domain manager.

5. Download function: support function for the interface for downloading an object (software) from a domain manager or a predefined service terminal.

On the other hand, the reference point controller must periodically confirm that the reference point controller works normally with the domain manager or other devices. In addition, eligible applicants for an anchor point controller must periodically confirm that eligible applicants for an anchor point controller work normally with a domain manager or other devices. The reason is that a suitable candidate for a reference point controller may not replace the reference point controller when an error occurs in a suitable candidate for a reference point controller.

Figure 10 depicts a block diagram illustrating a reference point controller, as well as connections between suitable applicants for a reference point controller for transmitting an information signal.

As shown in FIG. 10, certain routes a, b and c for transmitting the information signal are formed between the reference point controller 70 and suitable candidates 71 and 72 to the reference points controller located in domain 6. Routes a, b and c for transmitting the information signal are routes for transmitting an information signal to confirm whether the device is operating normally.

For example, along the routes a, b, and c for transmitting an information signal, the reference point controller 70 transmits the information signal to the first reference point controller 71, and a suitable candidate 70 sends the information signal to the second reference point controller 72 to the reference point controller 72. In addition, the second suitable candidate 72 for the reference point controller transmits an information signal to the reference point controller 70. At this stage, the first suitable candidate 71 for the reference point controller designates the primary suitable candidate for the reference point controller, and the second suitable candidate 72 for the reference point controller indicates the secondary suitable candidate for the reference point controller.

In routes a, b and c for the transmission of an information signal, means or a channel for the safe transmission of information must be provided. Various encryption methods can be used to form the means or channel for the secure transmission of information. For example, a public key method, a key pre-distribution method, a method in which a domain manager transmits key information to devices, and the like can be used. Alternatively, the content transfer controller may transmit key information if secure authentication channels are formed between the content exporter, the content converter, and the content importer.

The transmission signal is periodically transmitted along routes a, b and c to transmit an information signal. The transmission signal is used to confirm that a suitable candidate for the reference point controller or reference point controller is operating normally. The transmission signal may include domain information, device identification information, system information, latency information, and the like.

In this case, the information about the waiting period refers to the deadline for determining whether the information signal was received normally.

For example, if an information signal was not received from the reference point controller 70 during the deadline, then the first suitable candidate 71 for the reference point controller determines that an error has occurred in the first reference point controller 70. The first suitable candidate 71 for the reference point controller informs the domain manager that an error has occurred in the reference point controller 70, and also that the first suitable candidate 71 for the reference point controller replaces the reference point controller 70. After that, the first suitable candidate 71 for the reference point controller performs the function of the reference point controller 70.

At this stage, the first suitable candidate 71 for the reference point controller can receive from the domain manager 60 or another terminal information and tools necessary to perform the function of the reference point controller. For example, the first suitable candidate 71 for the reference point controller can download and install software to perform the function of the reference point controller, or it can activate the disabled software installed in it.

In another example, if the reference point controller 70 has not received an information signal from the second suitable candidate 72 for the reference points controller during the deadline, the reference point controller 70 determines that an error has occurred in the second suitable candidate 72 for the reference points controller, and also informs the dispatcher 60 of the domain that an error occurred in the second suitable candidate 72 for the reference point controller. Then, a suitable candidate for a reference point controller having a priority lower than the priority of a second suitable candidate for a reference point controller, for example, a third suitable candidate for a reference point controller (not shown), can replace the second suitable candidate 72 for a reference point controller. Priorities can be reinstated using the above procedures (examples 2-1 to 2-4) of selecting suitable candidates for the reference point controller.

On the other hand, in the example shown in FIG. 10, by transmitting an information signal between the reference point controller 70 and suitable candidates 71 and 72 to the reference point controller, it is determined whether an error has occurred in the device. The present invention is not limited to this. As shown in FIG. 11, the reference point controller 70, as well as suitable applicants 71 and 72 to the reference point controller, can directly transmit an information signal to the domain manager 60 along the routes e, f, and c. In another example, the reference point controller 70 may directly transmit the information signal to the domain manager 60, and suitable applicants 71 and 72 to the reference point controller may transmit the information signal to each other along a predetermined route. That is, the routes for transmitting the information signal can be changed in various ways according to runtime environments.

As described above, the reference point controller 70 and suitable applicants 71 and 72 for the reference point controller periodically confirm that they operate normally using the information signal. Depending on whether an information signal has been received, the reference point controller 70 can be replaced, and the priorities of suitable applicants 71 and 72 to the reference point controller can also be restored.

On the other hand, the zone of the local area defined by one controller of control points is physically or logically limited for tactical reasons, etc. However, the user may wish to use the content delivery service in a wider zone than the currently installed zone. Accordingly, a method is required in which the work area can be expanded, along with support for restricting the area of the local area.

In the present invention, the concept of a reference point intermediary controller is introduced. The reference point intermediary controller is a device that acts as a reference point controller, instead of a reference point controller. The reference point intermediary controller is necessary in cases of domain expansion or temporary exiting of the reference point controller.

Selection and operation of reference point intermediary controller

Fin. 12 is a block diagram illustrating a general view of the reference point intermediary controller. 12 illustrates an example in which domain A ′ is added to domain A.

As shown in FIG. 12, the zone and environment of the local area where the device can subscribe to the domain 86 are determined by the reference point controller 82. When expanding the workspace or in cases where the reference point controller 82 temporarily moves outside the local area, an extended domain must be formed that has powers similar to those of domain A, for example, domain 96 A '.

The zone and environment of the local area where the device can subscribe to the 96 A 'domain can be determined by the intermediary controller 92 reference points. An intermediary controller 92 reference points performs the function of a reference point controller in the 96 A ′ domain. That is, the intermediary controller 92 reference points is a reference point in the domain 96 A '. The user can accept the service for transmitting information content from the domain 96 A ', in addition to the domain 86, using client devices 84 and 94.

The reference point intermediary controller 92 can be easily selected using the procedures described in the above examples of selecting the reference point controller, as well as suitable candidates for the reference point controller. Methods for selecting a proxy controller 92 reference points will be described below.

In the first method for subscribing to domain 96 A ′, devices exchange device information with each other. Information about the device is compared with each other, according to a predefined algorithm, for example, the algorithm described in example 1-1. An intermediary controller 92 reference points is selected based on device information. For example, (information on) functional characteristics are exchanged between devices. The device with the highest functional characteristics is selected as the intermediary controller 92 reference points. The selected reference point intermediary 92 informs the domain manager 80 that the device has been selected as the reference point intermediary 92.

In the second method, similarly to the concept of selecting the reference point controller, according to Example 1-2, for subscribing to domain A ', the devices transmit information about the device to the domain manager (for example, DPDU, which includes information about the functional characteristics), and then based on the information About the device, the domain manager 80 selects the intermediary controller 92 reference points.

In the third method, the intermediary controller 92 reference points is selected on the basis of installation information that is pre-installed by the administrator or user, or is set arbitrarily.

On the other hand, after selecting the intermediary controller 92 reference points, a suitable applicant can be selected to prepare an exception for the occurrence of an error in the controller-intermediary 92 reference points. That is, a suitable applicant is selected that replaces the intermediary controller 92 reference points in the event of an error in the intermediary controller 92 reference points. A suitable candidate for a reference point intermediary controller can be easily selected using the above procedures for selecting suitable candidates for a reference point controller.

Methods for selecting a suitable candidate for the intermediary controller 92 reference points will be described below.

In the first method, for subscribing to a domain 96 A ', the devices exchange device information with each other. Information about the device is compared with each other, according to a predefined algorithm, for example, the algorithm described in example 1-1. An intermediary controller 92 reference points and a suitable candidate for an intermediary controller 92 reference points are selected based on information about the device. For example, (information on) functional characteristics are exchanged between devices. The device with the highest functional characteristics is selected as the intermediary controller 92 reference points. Then, a suitable candidate for the reference point intermediary controller is selected by exchanging functional characteristics between devices, with the exception of the reference point intermediary controller 92. There are priorities for eligible applicants for a reference point intermediary controller. In addition, the selected reference point intermediary controller 92 and the selected suitable candidate for the reference point intermediary controller 92 should inform the domain manager 80 that the devices have been selected as the reference point intermediary controller 92 and a suitable candidate for the reference point intermediary controller 92 points.

In the second method, similarly to the concept of selecting the reference point controller, according to Example 1-2, for subscribing to domain A, the devices transmit information about the device to the domain manager (for example, DPDU, which includes information about functional characteristics), and then based on information about the device, the domain manager 80 selects the intermediary controller 92 reference points and a suitable candidate for the intermediary controller 92 reference points. At this stage, there may be priorities for eligible applicants for an intermediary controller 92 reference points.

In the third method, the controller-intermediary 92 reference points and suitable applicants for the controller-intermediary 92 reference points are selected according to priorities. At this stage, predefined information can be set by the administrator or user. Alternatively, the predetermined information may include arbitrarily set information.

On the other hand, the reference point intermediary controller 92 must inform the reference point controller 82 that the reference point intermediary controller 92 continuously and stably provides a service. An intermediary controller 92 reference points periodically exchanges a predetermined information signal with a reference point controller 82. If the information signal has not been transmitted within a predetermined period of time, this means that the intermediary controller 92 reference points does not work normally. Accordingly, the 96 A ′ domain cannot be supported.

The domain reference information may include domain reference information, device identification information, latency information, unique system information, and the like.

The information signal should be transmitted via a wired or wireless transmission route in which means or a channel for the safe transmission of information are provided. Various encryption methods can be used to form the means or channel for the secure transmission of information. For example, a public key method, a key pre-distribution method, a method in which a domain manager transmits key information to devices, and the like can be used. In addition, an information signal can be continuously transmitted between the reference point controller and the domain manager, as well as between the reference point intermediary controller and the domain manager, and among other things, between the reference point controller and the reference point intermediary controller.

On the other hand, if the 96 A 'domain is not supported, then it must be deleted. In this case, the domain 96 A ′ can be deleted using an information signal. For example, the reference point controller 82 or the domain manager 80 stops transmitting the information signal to the intermediary reference point controller 92 or transmits a deletion signal. Then, since the intermediary reference point controller 92 does not operate normally, the reference point intermediary controller 92 is deleted. Accordingly, domain A ′ is automatically deleted.

Checkpoint controller registration

Next, a procedure for registering a new reference point controller will be described. The registration procedure of the GCP controller can be performed after the formation of a new domain or after replacing the GCP controller.

13 is a flowchart illustrating a registration procedure of a reference point controller.

13, the domain manager receives an authentication request for a reference point controller from a device registering as a new reference point controller. At this stage, a device registering as a new reference point controller can be one device selected from the above procedure for selecting a reference point controller, a suitable candidate for a reference point controller to replace an existing reference point controller, and a reference point intermediary controller.

After the domain manager accepts the authentication request for the reference point controller, the domain manager removes the membership from the reference point controller. At this stage, the reference point controller's membership is formed by the domain manager after the registration of the reference point controller. The reference point controller's accessory can display information to confirm that the corresponding object is a reference point controller.

The domain manager generates and stores a unique new reference point controller accessory, and also transfers the generated reference point controller accessory to the device, which requests the domain manager to provide a new reference point controller accessory. At this stage, the domain manager saves and manages the affiliation of the reference point controller and the domain in pairs.

A device that accepts an anchor point controller accessory retains an anchor point controller membership. The device registers as a reference point controller. The stored accessory of the reference point controller can be used as authentication information of the element in cases where the newly registered reference point controller provides the domain manager with various types of information or requests the domain manager to provide various types of information or when the client is already authenticated. In addition, reference point controller ownership is periodically maintained during support for the reference point controller.

Client Authentication Method

Next, a method for authenticating a client will be described. In Fig. 5, when a client 3 subscribes to domain 5, the domain manager 22 generates a client’s affiliation that is unique to client 3. The assigned client’s affiliation 3 is constantly stored as long as the client is a member of domain 5. When client 3 leaves the domain 5, the domain manager 22 maintains the client’s ownership for a predetermined period of time, after which it removes the client’s ownership. At this stage, even if client 3 leaves domain 5, the information content that was used before the timeout period will continue to be used for a predetermined period of time. A predefined time period can be selectively applied by the supplier policy.

The client must confirm that the client usually subscribes to domain 5 for a predefined object so that client 3, subscribing to domain 5, uses the service. To do this, client 3 requests the domain manager 22 for authentication of client 3. If client 3 requests the domain manager 22 for authentication of client 3, then client 3 must provide the domain manager 22 with full or automatic credentials.

The full credentials are encrypted information, including the client’s membership assigned to the client 3, as well as the full domain credentials. At this stage, the full domain credentials are generated by the domain manager 22, after the formation of the domain 5. The domain manager 22 applies the generated domain credentials to various transactions for managing the domain, after the formation of the domain 5.

Automatic credentials are encrypted information, including the affiliation of the reference point controller, as well as the affiliation of the client. The automatic credentials may be domain credentials provided by the reference point controller 26. The reference point controller membership is formed by the domain manager 22 after registering the reference point controller 26 in the domain 5. The reference point controller ownership is constantly maintained as the reference point controller 26 is supported. Automatic credentials are information indicating whether the client 3 is present in the local area, which is guaranteed by the reference point controller 26. Accordingly, client 3 in a local state can use automatic credentials.

If client 3 requests the domain manager 22 to authenticate client 3, then domain manager 22 determines whether the credentials presented are valid. If it is determined that client 3 is not subscribed to domain 5, then domain manager 22 generates an error. Alternatively, if client 3 typically subscribes to domain 5, then domain manager 22 authenticates client 3. Client 3 can use information content within the allowed zone.

The domain manager 22 determines that client 3 has a remote or local state based on whether the credentials provided by client 3 are complete or automatic, and also controls client 3. As described above, the remote state can be displayed when client 3 accesses domain 5 in a network area outside the local area. For example, client 3 gains access to domain 5 over the Internet. On the other hand, the local state can be displayed when the client 3 is in the local area. The reference point controller 26 can check the client 3 in a local state by measuring the number of jumps. Client 3 can be registered in domain 5 as a member using a predefined procedure.

Registration, authentication and management of a conventional device

A regular device, in addition to a client device, can also access a domain. At this stage, a conventional device may be a device in which an object operating as a client in a domain is not installed. In particular, a device having only certain client functions, or a device that does not include a client, is called a conventional device.

To provide services to a typical device in a domain, the client node includes an adapter to provide the regular device with access to the system, i.e., an interface object. The interface object must provide various functions in order for a regular device to perform a function equivalent to a client device.

The above interface object is called a virtual client. A virtual client is an object necessary for a regular device to communicate with the system. A virtual client provides services to a typical device like a client device in conjunction with a regular device. In general, the domain manager considers the access of the virtual client and the regular device to the domain as the access of one client to the domain. One or more conventional devices may be associated with a virtual client.

A virtual client or domain manager can manage the unique information of a conventional device. In addition, a virtual client or domain manager also manages user information using a regular device.

14 depicts an example structure for managing unique information of a conventional device.

As shown in FIG. 14, if the conventional device 210 requests a virtual client 220, which is accessed using the conventional device 210, then unique information “DV-info” about the conventional device is transmitted to the virtual client. At this stage, the unique DV-info information about a conventional device may be unique information, such as a media access control address, disk volume identifier, and the like, which is unique to conventional device 210.

Unique DV-info information about a conventional device can be transmitted to virtual client 220 in conjunction with a request for access request message when conventional device 210 requests a virtual client that is being accessed. Alternatively, the virtual client 220 may retrieve unique DV-info information about the conventional device from the conventional device 210 when the conventional device 210 requests the virtual client 220 to be accessed.

Virtual client 220 can store and manage unique DV-info information about a conventional device provided by conventional device 210. At this stage, as shown in FIG. 14, unique DV-info information about a conventional device can be managed, as well as can be saved in the form of an information table 222 taking into account the identifier "LD-info" of the device. In this case, the identifier “LD-info” of the device is a globally unique identification information for identifying a conventional device 210. The identifier “LD-info” of the device can be assigned by the domain manager 240.

The domain manager 240 stores and manages the “LD-info” identifier of the device, as well as unique “DV-info” information about the regular device corresponding to the “LD-info” identifier of the device for each domain. For example, as depicted in FIG. 14, a domain manager 240 can store and manage a domain D-ID, a device LD-info identifier, and DV-info unique information about a regular device corresponding to a domain D-ID and ID LD-info ”of the device, in the form of an information table 242. At this stage, the domain D-ID is information for identifying a domain that is accessed through a conventional device 210. The domain D-ID can also be information for identifying a domain 200, in which the virtual client 220 is included.

If the domain manager 124 controls the device-LD-info ’and the unique DV-info information about the regular device corresponding to the device-LD-info’, then the domain manager 240 can protect the ordinary device 210 from double requesting another domain to authenticate the regular devices 210. This will become apparent by the authentication method of a conventional device, which will be described below.

15 is a flowchart illustrating an authentication procedure of a conventional device.

14 and 15, if the predefined conventional device 210 requests the virtual client 220 to be accessed (step S41), then the virtual client 220 receives unique DV-info information about the conventional device from the conventional device 210 (step S42) . Then, the virtual client 220 searches in the information table 222 stored therein (step S43), and determines whether unique information about the conventional device is present, which is similar to the unique DV-info information about the conventional device that the virtual client 220 requests, accessed (step S44). That is, it is determined whether the conventional device 210 has been previously registered.

At this stage, if unique information about the regular device, similar to the unique DV-info information about the ordinary device that the virtual client 220 requests to access, is present, then since the conventional device 210 is already registered with the virtual client 220, the virtual client requests the domain manager 240 to authenticate the device's “LD-info” identifier (step S46). Upon request of the domain manager 240 to authenticate the device LD LD-info ’identifier, the ру LD-info’ identifier of the device and unique DV-info information about the conventional device may be transmitted to the domain manager 240.

On the other hand, if it is determined that unique information about the regular device, similar to the unique information “DV-info” about the regular device that the virtual client 220 requests to access, is not present, then the virtual client 220 receives the new identifier “LD- info ”of the device from the domain manager 240 and stores the new identifier“ LD-info ”of the device in the information table 222 (step S45). Accordingly, the unique “DV-info” information about the conventional device and the newly assigned device identifier “LD-info” are likewise stored in the information table 222. That is, the conventional device 210 is registered as a new device.

To register a conventional device, a virtual client 220 or domain manager 240 analyzes unique information about the conventional device 210, and also analyzes whether the conventional device 210 is a device that can be registered. At this stage, a device that can be registered may be a technically and tactically authorized device. For example, a service provider, another organization, a domain manager, etc. manages the list of types of a conventional device that can access a domain. After registering a new regular device, the virtual client or domain manager examines the list of types of the conventional device and then assigns device identifiers only to allowed devices. This will be described in detail with reference to FIG.

After storing the “LD-info” identifier of the device, the virtual client 220 requests the domain manager 240 to authenticate the “LD-info” identifier of the device (step S46).

Then, the domain manager 240 authenticates the identifier “LD-info” of the device, taking into account the unique information “DV-info” of the conventional device corresponding to the identifier “LD-info” of the device, in response to an authentication request. In particular, the domain manager 240 searches the information table managed by the domain manager 240 (step S47), and then determines whether the conventional device 210 is gaining access to another domain (step S48). For example, the domain manager 240 determines whether unique information about a conventional device is currently authenticated, similar to unique information about a conventional device.

If it is determined that the conventional device 210 does not gain access to another domain, then the virtual client 220 is informed that the device’s “LD-info” identifier is allowed to access the domain (step S50). That is, the conventional device 210 is allowed to access the domain. Accordingly, the conventional device 210 can access the domain 200, as well as use information content.

On the other hand, if it is determined that the conventional device 210 is gaining access to another domain, this means that the conventional device has the intention of gaining dual access to the domains. The virtual client 220 is informed of the determination result (step S49). That is, the conventional device 210 is denied access to the domain. Accordingly, the conventional device 210 cannot access the domain 200.

As described above, the virtual client 220 and the domain manager 240 store and manage unique information about the conventional device 210. For example, the virtual client 220 and the domain manager 240 store and manage the certificate of a conventional device. Therefore, the conventional device 210 can be protected from double access to the domain 200. Accordingly, the conventional device 210 can be protected from illegal sharing of information content.

On the other hand, the virtual client and the domain manager can manage information about a user who uses a conventional device, in addition to unique information about a conventional device. In this case, the number of conventional devices that can be used by the user may be limited.

Fig. 16 depicts an example of the structure of an interoperable DRM system for managing user information that uses a conventional device.

As shown in FIG. 16, if the conventional device 251 accesses the virtual client 260 to request a domain authentication of the conventional device 251, unique DV-info information about the conventional device, as well as the U-info information of the user of the conventional device 251 virtual client 260. At this stage, the U-info information of the user of the conventional device 251 may be unique information to identify a user who uses the conventional device 251, for example, information of the abone identification module nt, user certificate information or information that is explicitly entered by the user, for example, an identifier (ID), password, etc. It may correspond to user information about entering the system (about registration). As described above, the unique DV-info information about a conventional device can be unique information, such as a media access control address, disk volume identifier (ID), etc., which is unique to a conventional device 210 That is, unique information about a conventional device displays information including physical or logical information.

User U-info and unique DV-info information about a conventional device can be transmitted to virtual client 260 in conjunction with an access request message when conventional device 251 requests a virtual client 260 to be accessed. Alternatively, the virtual client 260 may retrieve the user U-info and unique DV-info information about the conventional device from the conventional device 251 when the conventional device 251 requests the virtual client 260 to be accessed.

The virtual client 260 stores and manages the unique DV-info information about the conventional device and the user U-info information. At this stage, as shown in FIG. 16, the unique “DV-info” information about the conventional device and the user “U-info” information can be managed, and it can also be saved as an information table 262, taking into account the identifier “LD-info” »Device provided by the domain manager 270.

The domain manager 270 stores and manages the device’s LD-info identifier, unique DV-info information about the regular device, and user information for each domain. In general, as shown in FIG. 16, a domain manager 270 can store and manage a domain D-ID, a device LD-info identifier, unique DV-info information about a conventional device, and user U-info information in the form of an information table 272.

After transmitting the authentication request to the predefined conventional device 251 from the virtual client 260, the domain manager 270 can apply the U-info information of the user of the conventional device 251 to authenticate access permission by searching for the U-info of the user of the conventional device 251 in the information table 272 dispatchers of 270 domains. In addition, the management of the conventional device 251 by the domain manager 260 can be applied to the regular client device.

For example, the number of conventional devices 251 is retrieved by searching the user's U-info information in the information table 272. The number of conventional devices 251 is compared with a predetermined limit number. If the number of conventional devices 251 is less than a predetermined limit number, then authentication is performed. If the number of conventional devices 251 is equal to or greater than a predetermined limit number, then authentication is not permitted. Accordingly, the total number of conventional user devices may be limited. At this stage, the limit will depend on the policy of the service provider or the size of the payments made by the user.

As described above, after authentication of the conventional device 251, by searching for unique DV-info information about the conventional device, a procedure can also be performed to determine whether dual domain access is obtained. That is, during the authentication procedure, it is checked whether dual access to the domain is obtained, and also, by using unique information about the regular device and the user’s “U-info” information, a limit quantity is set for the user. On the other hand, it can be periodically checked whether dual access to the domain is obtained, and the number of conventional devices for each user can be periodically limited, according to a predetermined period.

17 is a flowchart illustrating a procedure for registering a conventional device in a domain.

17, if the new conventional device requests a virtual client to be accessed about a domain subscription (step S51), then unique information about the conventional device is transmitted to the virtual client. Then, using the unique information about the conventional device, the virtual client determines that the virtual client is a new conventional device and also searches for a list of conventional devices that can be registered (step S52). The list of conventional devices that can be registered includes device objects that can be tactically and technically provided using the service. The list can be pre-saved by the virtual client. Alternatively, the list may be provided by a domain manager, a service provider's server, or another system.

The virtual client searches for a list based on unique information about the conventional device, and also determines whether the conventional device can be registered (step S53). For example, it is determined whether unique information about a conventional device is listed. At this stage, if unique information about the regular device is listed, the virtual client asks the domain manager to register the regular device. Then, the domain manager generates a unique device identifier and transmits a unique device identifier to the virtual client (step S54). Alternatively, if unique information about the conventional device is not listed, the virtual client does not allow registration of the conventional device and transmits information to the conventional device whether the conventional device can be registered (step S55).

With reference to FIGS. 5-17, operations that can be performed by an authentication and control node, for example, a function of a client node, a procedure for selecting a reference point controller, a procedure for selecting suitable candidates for a reference point controller, a procedure for replacing a reference point controller using a suitable applicant, have been described to the reference point controller when an error occurs in the reference point controller, the procedure for expanding a domain using the reference point intermediary controller, the procedure for selecting and using odyaschego applicant controller proxy control points, the registration procedure of the controller of control points, customer authentication procedure, registration procedure, authentication and conventional control device, etc.

3. Functions and operations of the processing control unit and the content processing unit

After the domain is formed by the authentication and control node, an authenticated client or a conventional device (connected to a virtual client) in the domain can use an interoperable DRM service. At this stage, a conventional device and a virtual client connected by honey can be considered as one client. Accordingly, the next client may include a client formed by connecting a conventional device to a virtual client, in addition to the client defined in the description of FIG. 2.

An authenticated client may request a predetermined destination device to transmit one or more content items. At this point, the destination device displays a device or system in which the client needs to transfer predefined information content, for example, another client device, a predefined web server or system.

A request for transmitting content may be received by the processing control unit. The processing control unit controls the content processing unit for transmitting information content in response to a request for transmitting information content. The content processing unit transmits one or more content items requested by the destination device under the control of the processing control unit.

Next, a procedure for transmitting information content using the processing control unit and the content processing unit will be described in detail. In the following description, four methods of transmitting content in an interoperable DRM system will be illustrated. For ease of understanding, the first method is called example 3-1. The second method is called example 3-2. The third method is called example 3-3. The fourth method is called example 3-4.

Example 3-1

18 is a block diagram illustrating the structures of a processing control unit and a content processing unit. Fig. 18 illustrates objects associated with a content transfer procedure.

As shown in FIG. 18, the processing control unit 40 includes a content processing controller 41 and a license processing controller 42. In this case, since the license processing controller 42 is not associated with the transmission of information content, a detailed description will be offered later.

The content processing controller 41 serves to request the content processing unit 50 to transmit the content according to the request for transmitting the content from the client, as well as to control the transmission of the content. The content processing controller 41 may be located at any location in a local or network area. Preferably, the content processing controller 41 is included in a predetermined device that subscribes to a domain in a local area.

The content processing unit 50 includes a plurality of content processors. The content processor may display an object that performs a function related to the transmission and processing of the content. The content processor includes an content exporter 52, a content converter 51, and a content importer 53.

The content exporter 52 performs the function of transmitting the content to the content converter 51 or the content importer 53 in the form of a neutral content by exporting the content requested by the content processing controller 41. At this stage, neutral content may display pure content that is not encrypted using a predefined DRM. In addition, the content requested by the content processing controller 41 may be content that is encrypted using a predetermined DRM. The content exporter 52 decrypts the requested content, converts the decrypted content to a neutral content, and transmits the converted content. Alternatively, the content exporter 52 may receive pre-decrypted neutral content, as well as transmit the received content.

The content converter 51 is for receiving neutral content transmitted from the content exporter 52, converting the neutral content to content with the desired format, and also for transmitting to the importer 53 content of the content with the desired format. At this point, the required format displays the format required by the destination DV2 device. The content converter 51 participates in the transmission only in those cases where a conversion of the neutral content format is necessary.

The content importer 53 is for receiving neutral content transmitted from the content converter 51 or from the content importer 52. In addition, the content importer 53 may transmit the received neutral content to the destination device DV2. Alternatively, the content importer 53 may encrypt the received neutral content in the content with a format suitable for DRM applied to the destination device DV2, as well as transmit the encrypted content to the destination device DV2. At this stage, in the previous case, the destination device DV2 encrypts the neutral content transmitted from the content importer 53 into the content with a format suitable for DRM applied to the destination device DV2, and also uses the content. In the latter case, since the content encrypted by the content importer 53 is transmitted, the destination device DV2 can use the transmitted content.

19 and 20 are examples illustrating the locations of the content processing controller 41 and the content handlers.

As shown in FIGS. 19 and 20, the content processing controller 41 and the content handlers, that is, the content exporter 52, the content converter 51 and the content importer 53, are located at different locations according to execution environments.

First, in FIG. 12, content exporter 52 may be included in the requesting device DV1. Content importer 53 may be included in the destination device DV2. In addition, the content processing controller 41 or the content converter 51 may be included in other devices separate from the requesting device DV1 and the destination device DV2.

In this case, the requesting device DV1 as well as the destination device DV2 must be determined.

The requesting device DV1 displays a client device that requests transmission of information content. The requesting client RC1 may be included in the requesting device DV1. In addition, a predefined DRM may be installed in the requesting device DV1. That is, the requesting device DV1 may use content to which a predefined DRM is applied.

As described above, the destination device DV2 displays a client device or a predefined system to which the content requested by the requesting client RC1 has been transmitted. The RC2 destination client can be included in the DV2 destination device. In addition, the DRM destination can be set in the destination device DV2. That is, the destination device DV2 can use the content to which the DRM destination is applied.

20, the content processing controller 41 and the content exporter 52 are included in the requesting device DV1, and the content importer 53 is included in the destination device DV2. In addition, the content converter 51 is separately included in another device.

As described above, the content processing controller 41 is the content exporter 52, the content converter 51 and the content importer 53 may be located at different locations. For security reasons, it may be advantageous for the content exporter 52 to be included in the requesting device DV1, and the content importer 53 to be included in the destination device DV2.

Accordingly, the present invention will now be described using the structure depicted in FIG. 19. However, the present invention is not limited to this. That is, the content processing controller 41 and the content processors may be included in one device according to runtimes. Optionally, the content processing controller 41 and the content processors may be included in one device according to runtime environments. Optionally, the content processing controller 41 and the content processors may be included in separate devices according to runtime environments.

Next, a procedure for transmitting information content based on the above system will be described in detail.

21 is a flowchart illustrating a procedure for transmitting content using the content processing controller 41 and the content handlers. FIG. 21 illustrates an example of a procedure for transmitting one or more content items included in a requesting device DV1 to a destination device DV2, which is a destination.

As shown in FIG. 21, in order to transmit content, the requesting client RC1, the content processing controller 41, a plurality of content processors, for example, the content exporter 52, the content converter 51 and the content importer 53, must interact with each other.

First of all, the requesting client RC1 transmits a content transfer request message for a request to transmit one or more content items to the content processing controller 41 (step S60).

At this stage, the message requesting the transmission of information content includes an identifier for the transmission session, information content identifier, source information, destination information, and the like. In addition, the information of the destination DRM system that receives the information content may alternatively be included in the message requesting the transmission of information content.

The content identifier may display information for identifying the requested content. If there are many requested elements of information content, then there may be many identifiers of information content to identify elements of information content.

Transmission Session Identifier displays an identifier for uniquely identifying a transmission session. A transmission session identifier can be used to identify sessions after performing a predetermined operation, for example, after canceling the transmission of information content or after updating the transmission status of the information content.

Information about the source is used to determine where the requested informational content came from. The source information may include an identifier for identifying a source device or a source system, for example, a requesting device DV1, format information of a requested content file, and the like.

The destination information includes information for identifying the destination device DV2, which is the destination to which the requested information content is transmitted. The recipient information may include a recipient identifier for identifying the recipient, information about a file format desired by the recipient, and the like. Information about the file format included in the recipient information can be transmitted after the file format is converted by the content converter 51.

The content transfer controller 41 may use the information included in the content transfer message as follows. At this point, the content transfer controller 41 may use information received from the requesting client RC1. Alternatively, the content transfer controller 41 may generate separate information in accordance with the information received from the requesting client RC1, and also use the generated information. For example, the content transfer controller 41 may use transmission session identifiers as well as a plurality of data identifiers received from the requesting client RC1. Alternatively, the content transfer controller 41 may use the generated transfer session identifiers as well as a plurality of data identifiers suitable for the session.

When receiving a message requesting the transmission of information content, the content processing controller 41 collects information about the content processors, checks whether the content can be transmitted, and also determines the content processor to convert the content, that is, the content processor to form the transformation chain information content (steps S61 to S63).

For example, the content processing controller 41 requests one or more exporters 52, the content importer 53, and the content converter 51 about the functional characteristics, and also receives a response from the corresponding entity. Accordingly, the functional characteristics of sources, intermediaries, and destination devices, systems, and DRMs can be determined.

After collecting the information, the content processing controller 41, based on the collected information, determines whether the requested content should be transmitted. That is, it is checked whether the content handlers normally transmit the requested content. In this case, one can take into account the format of the requested information content, system policy, and information about the algorithm of the secure authentication channel, which can be performed among objects. For example, if the content converter 51 does not support the conversion of content to content with the desired format based on the collected functional characteristics of the content converter 51, then the transmission of content is not possible. If the content converter 51 supports the conversion of content to content with the desired format, then the transmission of content is possible. The content processing controller 41 determines whether the content has been transmitted, taking into account the above factors.

If it is determined that the content has been transmitted, the content processing controller 41 determines the content handlers, for example, the content exporter 52, the content converter 51 and the content importer 53, which can efficiently perform the conversion of the requested content, and also controls the content handlers content to form a chain of transformation of information content, including specific content handlers. That is, certain information content processors are controlled to form a transformation chain of information content.

In determining the content processors included in the content conversion chain, the content transfer controller may include a content converter 51, and may also not include a content converter 51. If the format of the requested content is different from the format of the content required by the addressee, then the format of the transmitted content must be converted. However, if the format of the requested information content is similar to the format of the information content required by the addressee, then the format of the transmitted information content is not converted.

Accordingly, if the format of the requested content is different from the format required by the addressee, the content processing controller 41 includes a content converter 51 in the content conversion circuit. If the format of the requested content is similar to the format required by the addressee, then the content processing controller 41 does not include the content converter 51 in the content conversion chain. In this case, the transformation of the content format may display the conversion of the codec.

For example, if the requested content is compressed using MPEG-2 compression, and if the format of the content in the addressee is MPEG-4, then content with the MPEG-2 format is not available, and therefore the MPEG-2 format must be converted to MPEG-4 using content converter 51.

Example 3-1 describes the case where the content should be transformed, since the format of the requested content is different from the format required by the addressee. In this case, the content conversion chain should include a content converter 51.

Then, the content processing controller 41 sends a request to export the content, a request to convert the content, and a request to import the content to the content exporter 42, the content converter 51 and the content importer 53, respectively (steps S67-S69). The aforementioned requests are performed by transmitting a control message to request information processors to perform the required operations for information processors.

The control message for the export request for information content may include a transmission session identifier, information content identifier, receiver information, and the like. Information about the receiver may display information about the receiver to which the content exporter 52 exports and transmits the content. Example 3-1 describes a case where the information content conversion circuit includes an information content converter 51, and therefore, receiver information may display identification information of the content converter 51. However, if the content conversion chain does not include the content converter 51, then the receiver information may display the identifier information of the content importer 53.

In addition, the control message for the information content conversion request may include a transmission session identifier, information identifier of the content, transmitter information, information about the receiver, information about the format of the transmitted information content, information about the converted format, and the like. At this stage, information about the transmitter and information about the receiver can display information for identifying an object that transmits information content, as well as an object that receives information content. That is, information about the transmitter is used to identify the content exporter 52, which is the transmitter, and receiver information is used to identify the content importer 53, which is the receiver.

A control message for a request to import information content may include a transmission session identifier, information identifier of the content, information about the transmitter, and the like. Transmitter information may display information for identifying a transmitter that transmits information content. Example 3-1 describes a case where a content converter 51 is present, and in this regard, source information may display identification information of a content converter 51. If the content converter 51 is not included in the content conversion chain, then the content exporter 52 becomes a transmitter. After a request to receive information content, information about the receiver, which as a result receives information content, may include information about the addressee and information about the DRM system of the addressee.

In addition, after a request for export, conversion and import of information content, the content identifier included in the control message is compared with the content identifier requested when the client requests the transfer of information content. After a client requests to transfer a plurality of elements of information content, the identifier of the requested information content, if the information content is requested to be transmitted, is similar to the identifier of the information content included in the information request for exporting the information content, information request for converting the information content and information request for importing the information content .

As described above, if the content exporter 52, the content converter 51 and the content importer 53 respectively receive a request to export content, a request to convert content and a request to import content from the content processing controller 41, then between content exporter 52 and content converter 51, and between content converter 51 At the same time, secure authentication channels (SACs) are established and content importer 53 (step S70). At this point, a security method, such as transport layer security, which applies to the TCP / IP transport layer, can be applied to SAC channels.

The content exporter 52 establishes a SAC channel with the content converter 51 to safely transmit the requested content to the content converter 51, which is the receiver, in response to a request to export the content. In addition, the content converter 51 converts the content transmitted from the content exporter 52, and sets up an SAC channel for transmitting the converted content to the content importer 53 in response to a request to convert the content. On the other hand, the content importer 53 may establish a SAC channel for transmitting the content transmitted from the content converter 51 to the destination device DV2, that is, the end point in transmitting the content, in response to a request to import the content. It is more advantageous when the content importer is installed in a device other than the destination device.

Accordingly, a SAC channel is established that forms a path from the content exporter 52 to the content importer 53 through the content converter 51. In addition, from the content importer to the endpoint, an SAC channel can be established through which the content importer 53 transmits the content to the final endpoint. Each content processor may inform the content processing controller 41 of the establishment of SAC channels (steps S71-S73).

After the establishment of SAC channels, content begins to be transmitted from the content exporter 52. At this stage, pairs of related content processors (i.e., content exporter 52 - content converter 51 and content converter 51 - content importer 53) support a multiple transmission protocol. The multiple transmission protocol serves to provide multiple elements of information content with the possibility of transmission in one session. This can support variable frame size. Accordingly, it is possible to transmit a plurality of content items in one session.

Fig. 22 is an example illustrating a multiple transmission protocol.

As shown in FIG. 22, it is possible to transmit a plurality of content elements in one session. A content index is inserted in each content header. The content index may be a value consisting of predefined bits (e.g., four bits) to identify the content. The content index is a factor for distinguishing the content items transmitted during the corresponding session in conjunction with the requested content items. In addition, to distinguish between elements of information content, a separator of information content is inserted at the end of the information content. For example, a content separator may be formed of four zero bits.

Information content can be divided into many frames, according to the length of the information content. A frame size consisting of predefined bits (for example, four bits) is inserted into the frame header. The frame payload for transporting data is in front of the frame size location. On the other hand, an “end of transmission” (EOT), which indicates the end of a transmission, is inserted into the last part of the session. For example, an EOT may consist of four single bits.

A plurality of content items may be transmitted during a session corresponding to a transmission session identifier transmitted by the requesting client RC1, according to the support of the multiple transmission protocol. The above transmission is sequentially performed from the content exporter 52. The content exporter 52 sends the requested content items to the content converter 51 via the SAC channel (step S74). The content converter 51 receives the content elements and also converts the format to the format required by the addressee (step S75). After the format conversion is performed, the content converter 51 transmits the converted content items to the content importer 53 via the SAC channel (step S76). Then, the content importer 53 receives the content items and also transmits the received content items to the destination device DV2.

Content elements that were transferred from the content exporter 52 to the content importer 53 through the content converter 51 may be elements of the neutral content. Neutral content may display pure content that has not been encrypted using a predefined DRM. The content exporter 52 may export the requested content items, convert the exported content items into neutral content items, and also transfer the neutral content items. Alternatively, content exporter 52 may export pre-transformed elements of neutral content, as well as transmit elements of neutral content. This procedure can be carried out taking into account the policy or export procedure defined using the DRM applied to the requested content.

In addition, the content importer 53 may transfer the received neutral content elements to the destination device, taking into account the import policy or procedure determined by the DRM system applied to the destination device. For example, elements of neutral content can be encrypted according to the destination DRM, and also transmitted to the destination device DV2. Alternatively, the received neutral content elements may be transmitted to the destination device DV2 without encryption.

On the other hand, the content exporter 52, the content converter 51 and the content importer 53 may report the status of the transmission of the content items to the content processing controller 41. To this end, the content processing controller 41 must subscribe to a predetermined event by which the transmission status of the content can be provided. A predefined event is called an event that provides a state of transmission of information content.

A content processing controller 41 may request a subscription to provide a content transfer state before a content export request (steps S64-S66). For example, the content processing controller 41 may subscribe to relevant events by requesting the content exporter 52, the content converter 51, and the content importer 53 to subscribe to the content transfer status event.

When subscribing to an event for providing a content transfer state, the content processing controller 41 may receive an event message including information on the status of transmitting the content, by push (by subscription) or pull (by request). At this stage, in the “push” method, the content processor automatically issues an event message (including information on the transmission status of the content) with each change in the transmission status of the content. Accordingly, the content processing controller 41 may automatically accept the transmission state of the content. In the “pull” method, the content processing controller 41 obtains information about the transmission status of the content from the content processor as necessary.

When subscribing to an event, the content processing controller 41 informs the content handlers about which of the above methods (“push” or “pull”) was provided with information about the state of transmission of the content. Example 3-1 describes an example in which a content transfer state is provided to the content controller 41 for push processing.

When subscribing to a state of providing a state of transmission of information content, the controller 41 of the processing of information content may receive an event message including information about the state of transmission of information content from information content handlers. At this point, the session identifier should be included in the event message. In this case, the identifier of the transmission session is similar to the identifier of the transmission session assigned during the request for information content.

After the start of the transmission of the content, the content exporter 52 sends an event message to the content processing controller 41 to indicate that the content is starting to be transmitted. For example, an event message may be transmitted that includes a “Started” element. In addition, during the transmission of information content, an event message may be periodically transmitted to the information processing controller 41 to indicate that the information content is being processed. For example, an event message may be transmitted that includes the “ProgressDone” element (“Process Complete”). Upon completion of the content transfer, the content exporter 52 transmits an event message to the content processing controller 41 to indicate that the content transfer has been completed. For example, an event message may be transmitted that includes the element “Completed”. In addition, event messages are generated for each procedure on the basis of event information regarding all data conversion and transmission procedures, including information content or a license, in addition to the start, processing and completion procedures, and are also transmitted.

After the start of the transmission of the content, the content converter 51 sends an event message to the content processing controller 41 to indicate that the content is starting to be transmitted. For example, an event message including a “Started” element may be transmitted. In addition, during the transmission of the content to the content processing controller 41, an event message may be periodically transmitted to indicate that the content is being processed. For example, an event message including a “ProgressDone” element may be transmitted. After completion of the content transfer, the content exporter 52 sends an event message to the content processing controller 41 to indicate that the content transfer has been completed. For example, an event message including a “Completed” element may be transmitted.

After the start of the transmission of the content, the content importer 53 sends an event message to the content processing controller 41 to indicate that the content is starting to be transmitted. For example, an event message including a “Started” element may be transmitted. In addition, during the transmission of the content to the content processing controller 41, an event message may be periodically transmitted to indicate that the content is being processed. For example, an event message including a “ProgressDone” element may be transmitted. After completion of the content transfer, the content exporter 52 sends an event message to the content processing controller 41 to indicate that the content transfer has been completed. For example, an event message including a “Completed” element may be transmitted.

When an event message is received from the content exporter 52 to display the start of a transmission, the content processing controller 41 sends an event message to the requesting client RC1 corresponding to the start of the transmission. That is, the content processing controller 41 informs that the content is starting to be transmitted. Furthermore, if the content processing controller 41 receives an event message to indicate that the content is being processed, the content processing controller 41 sends an event message corresponding to the content processing to the requesting client RC1. That is, the content processing controller 41 informs that the content is being processed. If the content processing controller 41 receives an event message from the content importer to display the end of the transmission, then the content processing controller 41 sends an event message to the requesting client RC1 corresponding to the completion of the transmission. That is, the content processing controller 41 informs that the transmission of the content has been completed. If the aforementioned event messages are exported to the requesting client RC1, then event messages including a transmission session identifier determined upon requesting the requesting client RC1 to transmit information content can be transmitted.

On the other hand, the controller 41 for processing information content separately identifies the transmitted elements of information content, and also informs about the transmission status or the conversion status of the elements of information content. Alternatively, it is possible to inform about all transmitted elements of information content. In other words, the content processing controller 41 distinguishes a plurality of content items based on the transmission time, and informs the client of the transmission time at each transmission of the content. Alternatively, after the transmission of information content elements, all events are controlled, and then, the status of the transmission of information content can be informed. In addition, the identification of information content is performed based on the identification information of the information content. The above procedures can also be applied to the license. In the case of a license, the above procedures can be performed by the license transfer controller.

The requesting client RC1 may determine the status of the transmission of information content in relation to the session, which requests the transmission of information content using the above method. If the user interface function is included in the requesting client RC1, then the requesting client RC1 can inform the user about the transmission status of the content using numbers or graphics.

In addition, if a plurality of content items are transmitted during the session, then the transmission status of each content item can be determined. Accordingly, the transmission states of the requested content items transmitted during the session are sequentially determined.

On the other hand, the content exporter 52, the content converter 51, and the content importer 53 can determine an error that occurs in the SAC during the transmission of the content items. In this case, the content processor that finds the error may send an event message to the content controller 41 to indicate that an error has occurred. For example, an event message is transmitted that includes the “Error” or “SAC-Failure” element (“SAC Channel Failure”). At this point, the event message certainly includes a transmission session identifier.

When receiving an event message from a predetermined content processor for displaying that an error has occurred, the content processing controller 41 requests the content processors involved in transmitting the content items to cancel the transmission. When requesting a cancellation of a transmission, the identifier of the transmission session of the canceled transmission session shall be provided. In addition, the content processing controller 41 sends an event message to the requesting client RC1 to indicate that an error has occurred. Accordingly, the requesting client RC1 may determine that an error has occurred. On the other hand, the content processor that receives the request to cancel the transfer cancels the transfer session.

Transmission cancellation may be initiated by requesting client RC1. In this case, the requesting client RC1 transmits a transfer cancellation request including a transmission session identifier that is similar to a transmission session identifier provided to the content processing controller 41 when requesting to transmit the requested content. Then, the content processing controller 41 requests the content handlers that are participating in the transmission to cancel the transmission in response to the cancellation request. Content handlers that accept a request to cancel the transfer cancel the transfer session.

On the other hand, the content processing controller 41 may request the content converter 51 to subscribe to an event capable of managing the content conversion process, in addition to informing about an event, for example, about the start of the transmission of the content, about the transfer of the content, about the completion of the transfer informational content, about an error in transmitting informational content, etc., and can also receive a message about an event, for example, about the beginning of the formation of the information content format, about the transformation of the information content format, about the completion of the conversion of the information content format, about the error when converting the information content format, etc. Optionally, the content processing controller 41 may request an event to indicate that the data has been converted using a predefined signed encryption method, and may also receive an event message, for example, about the start of data conversion using the encryption method, about data conversion using encryption method, about completing data conversion using the encryption method, about an error in data conversion using the encryption method, etc. Optionally, the content processing controller 41 may request the content conversion processors to subscribe to the event to display the SAC channel generation procedure, and may also receive an event message, for example, the beginning of the formation of the SAC channel, the formation of the SAC channel, and the completion of the formation of the SAC channel , about errors in the formation of the SAC channel, etc.

Example 3-1 describes the procedures for generating a content transformation chain using a content processing controller of a processing control unit, using content processors of a content processing unit, and also using the transmission of one content item or a plurality of content items in one session .

In the following example 3-2, procedures will be described for generating a plurality of content transformation chains, as well as for transmitting one content item or multiple content items using multiple sessions, in response to a request from a requesting client RC1. In this case, the information content can be transferred to one or more recipients, in response to a request for the transfer of information content.

Example 3-2

23 is a flowchart illustrating a system structure for a content transfer procedure according to Example 3-2.

23, the requesting device DV1 may include the requesting client RC1 and the content exporter 52. In addition, the first destination device DV2-1 includes a first content importer 53a. The second destination device DV2-2 includes a second content importer 53b. The content processing controller 41 and the content converter 51 are included in a device separate from the requesting device DV1 or the destination device DV2.

24 is a flowchart illustrating a procedure for transmitting content according to Example 3-2. 24 illustrates an example of a procedure for transmitting one or more content items included in the requesting device DV1 to the first and second destination devices DV2-1 and DV2-2, which are addressees, in response to the request of the requesting client RC1.

As shown in FIG. 24, the requesting client RC1 transmits a request message for transmitting content to the content processing controller 41 to request one or more content items included in the requesting device DV1 to be transmitted to the first and second destination devices DV2- 1 and DV2-2 (step S81).

At this stage, the message requesting the transmission of information content includes at least one identifier of the transmission session, information content identifier, source information, destination information, and the like. In addition, the message requesting the transfer of information content may optionally include information about the DRM system of the recipient that receives the information content.

The content identifier may display information for identifying the requested content. In Example 3-2, since one or more content items are transmitted to the first and second destination devices DV2-1 and DV2-2, one or more content identifiers may be present.

Transmission Session Identifier displays an identifier for uniquely identifying a transmission session. In Example 3-2, the requested one or more content items should be transmitted to the first destination device DV2-1, and the requested one or more content items should be transferred to the second destination device DV2-2. Therefore, the transmission session is divided into two transmission sessions. Accordingly, two transmission session identifiers may exist. For example, the first and second transmission session identifiers may exist.

The source information displays information for determining where the requested content was transmitted from. The source information may include an identifier for identifying a source device or system, such as a requesting device DV1, format information of a requested content file, and the like. In Example 3-2, since the requested one or more content items are included in the requesting device DV1, the source information may include information about the requesting device DV1 and file format information.

The destination information includes information for identifying the destination device DV2, which is the destination to which the requested information content is transmitted. The recipient information may include a recipient identifier for identifying the recipient, information about a file format desired by the recipient, and the like. File format information included in the recipient information may be transmitted after the file format conversion performed by the content converter 51. In Example 3-2, destination information may include information about the first and second destination devices DV2-1 and DV2-2, as well as format information.

When receiving a message requesting the transmission of information content, the content processing controller 41 collects information about the content processors (step S82). For example, the content processing controller 41 polls one or more content exporters 52, content importers 53, and content converters 51 about functional characteristics, and receives responses from respective entities. Accordingly, the functional characteristics of source devices, intermediary devices, destination devices, systems, and DRMs can be determined.

After collecting the information, the content processing controller 41, based on the collected information, determines whether the requested one or more content items has been transmitted. That is, it is checked whether the content handlers normally transmit the requested content. In this case, you need to consider whether the two transmission sessions requested by the requesting client RC1 are completed.

After determining the transmission of the content, the content processing controller 41 controls the content handlers to form a content transformation chain by determining the content handlers that can efficiently perform the conversion of the requested content. In Example 3-2, since the transmission session for transmitting the requested content to the first destination device DV2-1 is different from the transmission session for transmitting the requested content to the second destination device DV2-2, two content transformation chains are required to complete each transmission session .

25 depicts a primary content conversion chain for transmitting one or more content items to a first destination device DV2-1.

As shown in FIG. 25, the primary content conversion chain includes an content exporter 52, a content converter 51, and a first content importer 53a.

Fig. 26 depicts a secondary content conversion chain for transmitting one or more content items to a second destination device DV2-2.

As shown in FIG. 26, the secondary content conversion chain includes an content exporter 52 and a second content importer 53b 53b.

At this stage, the primary content conversion chain includes a content converter 51, and the secondary content conversion chain does not include a content converter 51. Since the format of the requested one or more elements of the content is different from the format of the content required by the first destination device DV2-1, it is necessary to perform the conversion of the content format. On the other hand, the format of the requested one or more content items is similar to the content format required by the second destination device DV2-2.

The content processing controller 41 controls the content handlers to form the primary content transformation chain. The first transfer session is in progress. Then, the content processing controller 41 controls the content handlers to form a secondary content transformation chain. A second transfer session is in progress. In another example of forming a chain of transformation of information content, one session can be formed repeatedly.

First of all, the content processing controller 41 accordingly transmits a content export request, a content conversion request and a content import request to a content exporter 42, a content converter 51 and a content importer 53 (step S84). The aforementioned requests are performed by transmitting to the processors the information content of the control message.

After the content export request, the content processing controller 41 may transmit the first content session identifier, the identifiers of the requested one or more content items, as well as information about the content transformer 51, which is information about the receiver, to the content exporter 52.

In addition, after the content conversion request, the content processing controller 41 may transmit a first transmission session identifier, an identifier of one or more content items requested, information about the content exporter 52, which is information about the transmitter, information about the content importer 53 , which is information about the receiver, the format of the transmitted one or more information content elements information, information about the converted format, etc.

After a request to import content, the content processing controller 41 may transmit the first content session identifier, identifiers of the requested one or more content items, as well as information about the content converter 51, which is the transmitter, to the content exporter 52. In addition, the content processing controller 41 may also transmit information about a receiver that finally receives the content, as well as DRM information of the destination system. In this case, the receiver information may display information about a predetermined storage object or module included in the endpoint of the transmission of information content, for example, in the first destination device DV2-1.

As described above, if the content exporter 52, the content converter 51 and the content importer 53 respectively receive a request to export content from the content processing controller 41, then a content conversion request and a request are transmitted using the primary content transformation chain to import information content, and an event is also received (step S85).

First of all, SAC channels are established between the content exporter 52 and the content converter 51, as well as between the content converter 51 and the first content importer 53a. In addition, the SAC channel can also be established between the first content importer 53a and the first destination device DV2-1. After the SAC channels are established, the content exporter 52 starts transmitting the content. At this stage, the pairs of content processors (that is, the content exporter 52 — the content converter 51 and the content converter 51 — the content importer 53) support the aforementioned multicast protocol. Accordingly, a plurality of content elements may be transmitted in a single session.

A plurality of content items may be transmitted during a session corresponding to the first transmission session identifier transmitted by the requesting client RC1 (or generated by the content processing controller 41) according to the support of the multiple transmission protocol. The above transmission is sequentially performed from the content exporter 52. Content elements that are transmitted from the content exporter 52 to the content importer 53 through the content converter 51 may be types of neutral content items. As described above, neutral content may display pure content that has not been encrypted using a predefined DRM.

On the other hand, the content exporter 52, the content converter 51 and the first content importer 53a can inform the content processing controller 41 of the transmission status of the content items. To this end, the content processing controller 41 requests the content exporter 52, the content converter 51 and the first content importer 53a to subscribe to the content transfer status event, and receives the event message. Since the event was described in Example 3-1, its detailed description will be omitted.

After transmitting the content to the first destination device DV2-1 (step S86), the content processing controller 41 transmits a request to export the content and a request to import the content, respectively, to the content exporter 52 and the second content importer 53b included in the secondary a content transformation chain (step S87). That is, the two content conversion chains are sequentially transmitting under the control of the content processing controller 41. Specifically, two information content transformation chains are formed simultaneously, and transmission is performed using two information content transformation chains under the control of the content processing controller.

After a request for exporting content, the content processing controller 41 may transmit to the content exporter 52 a second transmission session identifier, identifiers of the requested one or more content items, as well as information about the content importer 53, which is receiver information. In addition, after a request to import content, the content processing controller 41 may transmit to the second content importer 53b a second transmission session identifier, identifiers of the required one or more content items, information about the content exporter 52, which is the transmitter.

As described above, if the content exporter 52 and the second content importer 53b respectively receive a request to export content and a request to import content from the content processing controller 41, then the content is transmitted and the event is received via a secondary circuit transforming the content (step S88).

First of all, an SAC channel is established between the content exporter 52 and the second content importer 53b. After the establishment of the SAC channel, the content exporter 52 begins to transmit the content. At this point, a pair of content processors (i.e., content exporter 52 — second content importer 53b) supports the aforementioned multicast protocol. Accordingly, a plurality of content elements may be transmitted in a single session.

A plurality of content elements may be transmitted during one session corresponding to a second transmission session identifier transmitted by the requesting client RC1 (or generated by the content processing controller 41) according to the support of the multicast protocol. The above transmission is sequentially performed from the content exporter 52. Content elements that are transmitted from the content exporter 52 to the second content importer 53b may be types of neutral content items. As described above, neutral content may display pure content that has not been encrypted using a predefined DRM. After the neutral content is transmitted to the second content importer 53b included in the second destination device DV2-2, the transfer is completed (step S89).

On the other hand, the content exporter 52 and the second content importer 53b may inform the content processing controller 41 of the content transfer status. For this, the content processing controller 41 requests the content exporter 52 and the second content importer 53b to subscribe to the content transfer status event, and receives the event message. The content processing controller 41 may determine the transmission status of each content item, as well as transmit information about the transmission status to the requesting client RC1.

Example 3-2 describes the procedures for generating multiple content transformation chains in response to a request from the requesting client RC1, as well as transmitting one content item or multiple content items over multiple sessions.

In the following example 3-3, a case will be described where the content requested by the requesting client RC1 is transmitted to a single destination by forming a plurality of content conversion chains. In example 3-3, an example will be described in which two chains of transformation of information content are formed.

Example 3-3

27 is a flowchart illustrating a system structure for a content transfer procedure according to Example 3-3.

27, the requesting device DV1 may include the requesting client RC1, as well as the content exporter 52. In addition, the destination device DV2 includes an importer 53 of information content. The content transfer controller and the content converter 51 may be included in a device separate from the requesting device DV1 or the destination device DV2.

28 is a flowchart illustrating a procedure for transmitting content according to Example 3-3. 28 illustrates an example of a procedure for transmitting one or more content items included in a requesting device DV1 to a destination device DV2, which is a destination, in response to a request from the requesting client RC1

28, first, the requesting client RC1 transmits a content transfer request message for the content transfer request to the content processing controller 41 (step S100). At this stage, the message requesting the transmission of information content includes an identifier for the transmission session, information content identifier, source information, destination information, and the like. In addition, the message requesting the transfer of information content may optionally include information about the DRM system of the recipient that receives the information content.

The content identifier may display information for identifying the requested content. If there are many requested elements of information content, then there may be many identifiers of information content to identify elements of information content.

Transmission Session Identifier displays an identifier for uniquely identifying a transmission session. The source information displays information for determining where the requested information content is being transmitted from. In Example 3-3, the source information may include information about the requesting device DV1 and format information.

The destination information includes information for identifying the destination device DV2, which is the destination to which the requested information content is transmitted. Information about the addressee may include an addressee identifier for identifying the addressee, information about a file format required by the addressee, and the like.

Upon receipt of a message requesting the transmission of information content, the content processing controller 41 collects information about information content processors, and also, based on the collected information, determines whether information content should be transmitted. If it is determined that the content has been transmitted, then the content processing controller 41 determines the content processors that are involved in the transmission (steps S101-S103).

First of all, the content processing controller 41 interrogates one or more content exporters 52, content importers, and content converters 51 about functional characteristics, and also receives responses from respective entities. Accordingly, the functional characteristics of source devices, intermediary devices, destination devices, systems, and DRMs can be determined.

After collecting information, based on the collected information, the content processing controller 41 determines whether the requested content should be transmitted. That is, it is checked whether the content handlers normally transmit the requested content. In this case, you can take into account the format of the required information content, system policy, information about the algorithm of the secure authentication channel, which can be performed among objects.

After determining the transmission of the content, the content processing controller 41 determines the content exporter 52 and the content converter 51, and also controls the content exporter 52 and the content converter 51 to form the primary content transformation chain using the content exporter 52 and the content converter 51 content. Example 3-3 describes an example of a case where the format of the requested content is different from the format of the content required by the destination device DV2. Accordingly, the content converter 51 should be included in the content conversion circuit.

Fig. 29 depicts an example of a primary content transformation chain formed using the content processing controller 41. 29, the primary content conversion chain includes an content exporter 52 and a content converter 51.

Next, the content processing controller 41 sends a request to export the content and a request to convert the content, respectively, to the content exporter 52 and the content converter 51 included in the primary content conversion chain (steps S107-S108). The aforementioned requests are performed by transmitting a control message to information processors.

After the content export request, the content processing controller 41 may transmit the content session identifier, content identifier, and information about the content converter 51, which is the receiver, to the content exporter 52. In addition, after the content conversion request, the content processing controller 41 may transmit the transmission session identifier, the content identifier, information about the content exporter 52, which is the transmitter, information about the content importer 53, which is the receiver, the format of the required content , converted format information, etc.

As described above, if the content exporter 52 and the content converter 51 respectively receive a request to export content and a request for converting content from the content processing controller 41, then a channel is established between the content exporter 52 and the content converter 51 SAC (step S109). The content exporter 52 and the content converter 51 may inform the content processing controller of the establishment of the SAC channel (steps S110 and S111).

After the establishment of the SAC channel, the content exporter 52 begins to transmit the content. At this stage, each pair of content processors (i.e., content exporter 52 — content converter 51) can support a multiple transfer protocol. As described above, a multiple-transmission protocol is used to provide multiple elements of information content with the possibility of transmission in one session. After a request for transmitting a plurality of content items, a plurality of content items may be transmitted in one session, according to the support of a multiple transmission protocol.

The above transmission is sequentially performed from the content exporter 52. The content exporter 52 transmits the requested content to the content converter over the SAC channel. Then, the content converter 51 converts the content format to the desired format.

The content exporter 52 and the content converter 51 may inform the content processing controller 41 of a transmission state or a content conversion condition. To this end, the content processing controller 41 must subscribe to a predetermined event by requesting the content processors to provide a predetermined event, before requesting to export the content (operations S104 to S106).

The predetermined event may include an event providing a state of transmission of information content, and an event providing a state of transformation of information content. As described above, information processors that participate in the transmission can inform about situations such as the beginning of the transmission of information content, the transmission of information content, the completion of the transmission of information content, an error in the transmission of information content, etc., as a message about an event using an event that provides a state of transmission of information content.

An event providing a content transformation state may be performed by the content transformer 51. The content processing controller 41 may subscribe to an event providing the content transformation state by requesting the content converter 51 to provide an event providing the content transformation state. Then, the content processing controller 41 may be provided with situations, such as the beginning of the transformation of the information content, the conversion of the information content, the completion of the transformation of the information content, an error in the conversion of the information content, and the like.

After transmitting the content transmitted from the content exporter 52 to the content converter 51, and also after completion of the conversion of the content format (step S112), the content processing controller 41 should form a secondary content conversion circuit including a content converter 51 and importer of 53 content. The primary and secondary content transformation chains operate sequentially under the control of the content processing controller 41.

30 depicts an example of a secondary content transformation chain formed using the content processing controller 41.

As shown in FIG. 30, the secondary content conversion chain includes a content converter 51 and a content importer 53. The content processing controller 41 sends a content conversion request and a content import request, respectively, to the content converter 51 and the content importer 53 included in the secondary content conversion chain (steps S113 and S114). A SAC channel is established between the content converter 51 and the content importer 53 (step S115). At this stage, the SAC channel may also be established between the content importer 53 and the destination device DV2.

The content converter 51 transmits the content, the format of which has been converted, to the content importer 53 via the SAC channel. Then, the content importer 53 receives the transmitted content. The content converter 51 and the content importer 53 may inform the content processing controller 41 of the state of transmission of the content. The information content transmitted from the information content converter 51 to the importer 53 of the information content is neutral information content. As described above, neutral content may display pure content that has not been encrypted using a predefined DRM.

Example 3-3 describes the procedure for transmitting the content requested by the requesting client RC1 to one destination using the formation of two content conversion chains.

In the following example 3-4, a case will be described where the content requested by the requesting client RC1 is transmitted to a plurality of recipients by forming a plurality of content transformation chains.

Fig. 31 is a block diagram illustrating a system for transmitting content according to Example 3-4.

31, the requesting device DV1 may include the requesting client RC1 and the content exporter 52. In addition, the first destination device DV2-1 includes a first content importer 53a. The second destination device DV2-2 includes a second content importer 53b. The third DV2-3 destination device includes a third content importer 53c. The content transfer controller and the content converter 51 may be included in a device separate from the requesting device DV1 or the destination device DV2.

32 is a flowchart illustrating the content of a transmission procedure according to Example 3-4. 32 illustrates an example of a procedure for transmitting content included in the requesting device DV1 to the first, second, and third destination devices DV2-1 to DV2-3, which are three destinations, in response to a request of the requesting client RC1.

32, the requesting client RC1 transmits a content transfer request message to the content processing controller 41 for the content transfer request (step S121). At this stage, the message requesting the transmission of information content includes an identifier for the transmission session, information content identifier, source information, destination information, and the like. In addition, the message requesting the transfer of information content optionally may include information about the DRM system of the recipient that receives the information content.

The content identifier may display information for identifying the requested content. If there are many requested elements of information content, then there may be many identifiers of information content to identify elements of information content.

Transmission Session Identifier displays an identifier for uniquely identifying a transmission session. The source information indicates information for determining where the requested information content is transmitted from. In Example 3-4, the source information may include information about the requesting device DV1, as well as format information.

The destination information includes information for identifying the destination device DV2, which is the destination to which the requested information content is transmitted. In Example 3-4, the destination information may include information about the first, second and third destination devices DV2-1 to DV2-3, information about the format required by the destination device DV2, and the like. In Example 3-4, the file formats required by the first, second, and third destination devices DV2-1 to DV2-3 are assumed to be similar. However, the present invention is not limited to this.

When receiving a request message for transmitting content, the content processing controller 41 collects information about the content processors (step S122). For example, the content processing controller 41 polls one or more content exporters 52, content importers 53, and content converters 51 about functional characteristics, and also receives responses from respective entities. Accordingly, the functional characteristics of source devices, intermediary devices, destination devices, systems, and DRMs can be determined.

After collecting the information, the content processing controller 41, based on the collected information, determines whether the requested one or more content items has been transmitted. That is, it is checked whether the content handlers normally transmit the requested content. In this case, one can take into account the format of the requested information content, system policy, and information about the algorithm of the secure authentication channel, which can be performed among objects.

After determining the transmission of the content, the content processing controller 41 controls the content exporter 52 and the content converter 51 to form a primary content transformation chain including the content exporter 52 and the content converter 51. Example 3-4 describes an example of a case where the format of the requested content is different from the format of the content required by the destination device DV2. Accordingly, the content converter 51 should be included in the content conversion circuit. In the present description, a chain is formed by receiving a control command from a client to form a chain for converting information content. However, the present invention is not limited to this. Various embodiments exist, such as an example in which a content processing controller may generate a control command to form a chain as well as form a chain.

33 depicts an example of a primary content transformation chain formed using the content processing controller 41. 33, the primary content conversion chain includes an content exporter 52 and a content converter 51.

Then, the content processing controller 41 sends a request for exporting the content and a request for converting the content, respectively, to the content exporter 52 and the content converter 51 included in the primary content conversion chain (step S124). The aforementioned requests are performed by transmitting a control message to information processors.

After the content export request, the content processing controller 41 may transmit the content session identifier, content identifier, and information about the content converter 51, which is the receiver, to the content exporter 52. In addition, after the content conversion request, the content processing controller 41 may transmit the transmission session identifier, the content identifier, information about the content exporter 52, which is the transmitter, information about the content importer 53, which is the receiver, the format of the required content , converted format information, etc.

As described above, if the content exporter 52 and the content converter 51 respectively receive a request to export content and a request for converting content from the content processing controller 41, then a channel is established between the content exporter 52 and the content converter 51 SAC.

After the establishment of the SAC channel, the content exporter 52 starts transmitting the content (step S125). At this stage, each pair of content processors (i.e., content exporter 52 — content converter 51) can support a multiple transfer protocol. Since the multiple transmission protocol is supported, a plurality of requested content items may be transmitted in a single session.

The above transmission is sequentially performed from the content exporter 52. The content exporter 52 transmits the requested content to the content converter over the SAC channel. Then, the content converter 51 converts the content format to the format required by the destination device DV2 (step S126).

The content exporter 52 and the content converter 51 may inform the content processing controller 41 of a transmission state or a content conversion condition. To this end, the content processing controller 41 must subscribe to a predetermined event by requesting the content processors to provide a predetermined event before the request to export the content. At this stage, the predefined event may include an event providing a state of transmission of information content and an event providing a state of transformation of information content. Since this was described in Example 3-3, a detailed description will be omitted.

After transmitting the content transmitted from the content exporter 52 to the content converter 51, and also after the conversion of the content format is completed, the content processing controller 41 sequentially generates a plurality of secondary content transformation chains corresponding to the plurality of destinations. The plurality of secondary content transformation chains may include first, second, and third secondary content transformation chains. In this case, the first, second and third secondary chains of information content transformation can be formed sequentially or simultaneously. In addition, the method of forming chains of transformation of information content may include a method of forming a chain from the starting point to the destination, as well as repeatedly forming a chain (many individual chains are formed as described in Example 3-2), or a method of separately forming chains by distinguishing the chains based on conversion times (described in examples 3-3 and 3-4).

Fig. 34 depicts an example of structures of a first secondary content conversion chain, a second secondary content conversion chain, and a third secondary content conversion circuit introduced by the content processing controller 41.

As shown in FIG. 34, the first secondary content conversion chain may include a content converter 51 and a first content importer 53a. The content conversion converter transmits a content conversion request and a content import request, respectively, to the content converter 51 and the first content importer 53a. A SAC channel is established between the content converter 51 and the first content importer 53a. After the SAC channel is established, content is transmitted from the content converter 51 to the first content importer 53a (step S127).

After transmitting the content to the first content importer 53a, the content processing controller 41 forms a second secondary content conversion chain. At this stage, the second secondary content conversion chain may include a content converter 51 and a second content importer 53b. The content conversion converter transmits a content conversion request and a content import request, respectively, to the content converter 51 and the second content importer 53b. Then, an SAC channel is established between the content converter 51 and the second content importer 53b. After the SAC channel is established, the content is transmitted from the content converter 51 to the second content importer 53b (step S128).

After transmitting the content to the second content importer 53b, the content processing controller 41 forms a third secondary content conversion chain. At this stage, the third secondary content conversion chain may include a content converter 51 and a third content importer 53c. The information content conversion controller transmits the information content conversion request and the information content import request to the information content converter 51 and the third content importer 53c, respectively. Then, after the establishment of the SAC channel, the content is transmitted from the content converter 51 to the third content importer 53c (step S129).

On the other hand, content handlers included in the secondary content conversion chain may send an event message to the content processing controller 41 to display the transmission status of the content and the like, according to the progress of the transmission process. The above event was described in examples 3-1 to 3-3.

Example 3-4 describes the procedure for transmitting the content requested by the requesting client RC1 to a plurality of destination devices DV2 by forming a plurality of content transformation chains. In the method of transmitting information content, according to example 3-4, it is possible to transmit information content to a plurality of recipients, as well as reduce unnecessary waste of transmission resources. It is possible to reduce the number of operations when converting the format of information content performed to transmit information content to multiple recipients. Even if an error occurs in the secondary transformation circuit of the information content, the operation of the primary transformation circuit of the information content has already been completed, and therefore only the secondary conversion circuit of the information content needs to be restored.

4. Functions and operations of the processing control node and the license processing node

On the other hand, an authenticated client of the client node may request the processing control node to transfer the license. For example, it is assumed that there is a first client device in which the first DRM is installed, and a second client device in which the second DRM is installed. If the user is about to transmit the first DRM content stored in the first client device to the second client device, then the first client can transfer the content to the second client device, which is the destination, using the above information content transfer procedures. In this case, if the second client device intends to use the transmitted information content, then a license suitable for the second DRM is required. Accordingly, the first client requests a license transfer.

Fig. 35 is a block diagram illustrating a structure of a system related to license transfer.

As shown in FIG. 35, the processing control unit 40 includes a content processing controller 41 and a license processing controller 42. Herein, a content processing controller 41 has been described above. A content processing controller 41 and a license processing controller 42 may be included anywhere in the network area or local area. The content processing controller 41 and the license processing controller 42 may be located in various areas. For example, a content processing controller 41 may be included in a predetermined device located in a local area. The license processing controller 42 may be included in a service provider located in a network area. The locations of the content processing controller 41 and the license processing controller 42 are not limited.

The license processing controller 42 receives the license transfer request from the client. Upon receipt of a request to transfer a license, the license processing controller 42 determines the objects that are involved in the transfer, and also, by collecting information about the objects included in the system, determines whether the license can be transferred. Accordingly, a chain may be formed along which the license is transferred.

The license manager 24 of the authentication and control unit 20 and the license processor 32 of the license processing unit 30, in addition to the license processing controller 42, may participate in the transfer of the license. Objects that are involved in the transfer of a license can be included anywhere in the network or local area. As necessary, SAC channels can be installed between predefined entities to ensure the security of transmitted license information.

The license processing controller 42 requests a predetermined entity, for example, the license manager 24, to transfer one or more neutral licenses, and also receives one or more neutral licenses. A neutral license can display compatible neutral license information from which many types of DRM license information can be extracted. If a user purchases a predefined DRM content, a neutral license can be generated and stored in the license manager using a DRM license. The neutral license 24 may be stored in the domain manager or in the reference point controller, in addition to the license manager 24. In the procedure for transferring a license, an entity that transfers a neutral license can act as an exporter.

A neutral license may include one or more related identifiers of information content, information about the dispatcher, information about the object that can use the license, usage models that describe authorization restrictions, etc.

The license processing controller 42 generates a new neutral license, which will be actually transferred using the transferred neutral license. At this stage, various types of information, for example, the relationship between the information content and the object, the recipient, etc., can take into account the relation of the display of the subject, the ratio of the display of resources.

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 a neutral license received from the license processing controller 42 to an inherent DRM receiver 900 of the destination. At this point, the license processor 32 can convert the accepted neutral license to a license suitable for the DRM destination, and also transfer the converted license to the native DRM receiver 900 by performing the method defined in the DRM destination. Alternatively, a neutral license may optionally be transferred to a destination DRM receiver 900. In this case, the license conversion is performed in the destination DRM system. The license processor and the inherent DRM receiver can respectively act as a converter and a receiver.

Objects that are involved in the transfer of the license can send an event message to the license processing controller 42 to display the transfer and processing of the license. For this, the license processing controller 42 must subscribe to the event of providing the transfer status of the license by requesting the corresponding object to provide the event of providing the status of transfer of the license. The license processing controller 42 may transmit to the client 3 information corresponding to the received event message. In addition, the license processing controller 42 may transmit an event message to display the status of progress, for example, a neutral license generation procedure and a neutral license transfer procedure from the license manager 24.

So far, the basic functions of an interoperable DRM system have been described, including a client node 10, an authentication and control node 20, a processing control node 40, a content processing unit 50, and a license processing unit 30. In the above description, an interoperable DRM system, according to an illustrative embodiment of the present invention, provides neutral data (neutral content format or neutral license) with compatibility with the format required by the addressee, and also transmits neutral data to the addressee in response to a data transfer request ( content or license) from the client.

5. Functions of block objects and event processing procedures

Each node of the interoperable DRM system, for example, the client node 10, the authentication and control node 20, the processing control node 40, the content processing node 50, the license processing node 30, and the like, are formed using one or more objects. At this stage, objects can display modules or devices formed as software or hardware that perform predetermined unique functions. Each object can be formed using one or more functional modules of the block that perform the predefined functions of the block. The object is installed in a predefined device for exchanging data with another object using a predefined interface. In addition, even if the objects belong to one node, the object can be installed in various devices. Devices may vary according to runtimes.

After the initial formation of the domain, the object can inform another object in the specific environment in which the object is included about the existence of the object. For this, the object may include a provider of formation information, which is a functional module of the block.

Fig. 36 is an example illustrating the functional modules of a block included in an object, as well as their functions.

As shown in FIG. 36, the predefined object 110 includes a plurality of block functional modules 111 that perform unique block functions, as well as a formation information provider 112. The formation information provider 112 must transmit the formation information of the predetermined object 110 in response to a request for transmitting the formation information from the requesting object, which is another object. At this stage, the formation information may include information about the block functional module 111 included in the predetermined object 110.

In addition, the formation information provider 112 may be requested by another entity to subscribe to the formation information change event. The formation information provider 112 then allows or denies the subscription by determining whether the subscription request is legal. At this stage, the formation information change event may display an event message including changing information about the formation of the predetermined object 110 in cases of changing information about the formation of the predetermined object 110.

An event of a change in formation information may be transmitted by a push or pull method. In the push method, the formation information provider 110 issues an event message including changed formation information to the requesting entity 114 that is subscribed to the event, each time the formation information of the predetermined object 110 is changed. In the pull method, the requesting object 114, which is subscribed to the event, receives changed information about the formation of the predefined object 110 as necessary. When a requesting entity 114 is requested to subscribe to an event, it informs the provider 112 of formation information about which of the methods (push or pull) sent the event message. Accordingly, it is determined in which way (“push” or “pull”) the event message was transmitted.

There are various types of events, for example, the aforementioned event of providing a state of transformation of information content, an event of transformation of formation information, and the like, in addition to an event of changing formation information. Next, the procedure for executing an event between objects will be described.

37 is an example illustrating a procedure for transmitting an event between two authenticated entities.

As shown in FIG. 37, an object having an event subscriber function and an object having an event issuing function must exist to execute a predetermined event. Further, an object having an event subscriber function is called an event subscription object 117. An object having an event issuing function is called an event issuing object 119. In addition, events may have names. The name of the event is information for displaying which of the events of providing the state of transmission of information content, events of transformation of information about the formation, etc., is an event.

The event issuing entity 119 must have its own unique identifier. This is because the event issuing entity 119 may be different from another event that is executing an event having the same event name since the event is executed by the event issuing entity 119. The unique identifier of the event issuing entity 119 may include an index for displaying sources of event messages issued by the event issuing entity 119.

To subscribe to a predefined event, the event subscription entity 117 must request the event issuing entity 119 that issues the predefined event to subscribe to the event.

When requesting an event subscription, the event subscribing entity 117 transmits a unique identifier to allow the event issuing entity 119 to identify the event subscribing entity 117. In addition, the event subscribing entity 117 must inform the event issuing entity 119 of which method (“push” or “pull”) the event issuing entity 119 transmitted the event. Accordingly, it is determined in which way (“push” or “pull”) the event was transmitted. At this stage, in the “push” method, the event issuing entity 119 automatically issues an event message including relevant information about the event subscribing entity 117 whenever an event state occurs. On the other hand, in the pull method, the event subscribing entity 117 requests the event issuing entity 119 and also receives the event message as necessary.

In addition, the event subscribing entity 117 may convey the event subscription identifier (ID) for the event, expiration information, the desired structure of the event information, and the like to the event issuing entity 119. The expiration information may display events of the expiration value of the subscription. For example, expiration information may include data on expiration, an event subscription period, and the like. If information about the expiration is not provided, then the subscription period is not limited.

The event issuing entity 119 enables or disables the subscription by determining whether the event subscription request is correct in response to the event subscription request. At this stage, the response message including information for displaying the subscription permission and information for displaying the subscription ban is transmitted to the event subscription object 117 taking into account the determination result.

When determining the identifier (ID) of an event subscription, information about expiration, etc. can be taken into account. For example, if the event subscription identifier (ID) is transmitted by the event subscription object 117 when requesting an event subscription, then the event issuing entity 119 may take into account whether the event subscription identifier (ID) is valid and also expired expiration date of the event subscription. At this stage, if the event subscription identifier (ID) transmitted by the event subscribing entity 117 is incorrect or has expired, then the event issuing entity 119 may transmit a message to the event subscribing entity 117 to display a subscription ban. Alternatively, if the event subscription identifier (ID) transmitted by the event subscription object 117 is correct and does not expire, then the subscription identifier (ID) as well as the subscription identifier information (ID) can be used. On the other hand, if the event subscription identifier (ID) was not transmitted by the event subscription object 117 when the event subscription was requested, then the event issuing entity 119 may transmit a new event subscription identifier (ID).

On the other hand, the event subscription object 117 may cancel the current event subscription. To this end, the event subscription entity 117 may send a message to the event issuing entity 119 to display the cancellation of the event. In addition, the event subscribing entity 117 may stop the event subscription by canceling the event submission method. For example, in the method of presenting the event currently selected as “push” or “pull” for subscribing to the event, the selection of the “push” or “pull” method is canceled.

So far, information about the formation between objects and the method of processing the event have been described. Using the aforementioned method, objects can interact with each other, according to certain situations.

6. Method and infra-system for domain management

Next will be described a method and infra-system for managing a domain, allowing control of the movement of the location of the domain. To do this, you can save and manage the current and previous domain locations using the domain manager that manages the domain. In addition, the movement of a domain location may be limited, according to predefined restrictions.

An interoperable DRM system manages domain location relocation information. In particular, an interoperable DRM system limits the moved domain location or the number of movements. If it is determined that the domain has gone beyond the limited zone by checking the change in the location of the domain, the interoperable DRM system deletes the domain or performs an additional action.

Next will be described a method of managing a domain, allowing the management of information about moving the location of the domain. The described embodiment of a domain management method may include a method for limiting the number of domain movements, a method for limiting a domain formation location, and the like. For ease of understanding, the first method is called example 4-1, and the last method is called example 4-2. In addition, the basis of the systems of examples 4-1 and 4-2 is illustrated in Figure 2.

Example 4-1

Fig. 38 is a flowchart illustrating a domain management method according to Example 4-1. Fig. 38 illustrates the procedures for establishing the allowed number of Na domain movements, corresponding information for logging in to the system, checking the number of domain movements, and also limiting the formation of the domain.

The domain manager 22 stores the allowed number Na of domain movements corresponding to the login information. Login information can be received from the 24 license manager. Alternatively, the domain manager 22 may provide a login function. The allowed number of Na domain transfers can depend on the size of payments made by the user. The upper limit of quantity can be politically set by the service provider. The allowed number of Na domain movements can be set to five, ten, etc. In addition, the domain manager 22 stores and manages the current and previous locations of the domain. When moving a domain, the domain manager 22 saves and controls the number of moves.

In Fig. 38, the domain manager 22 analyzes the current location of the domain 5 (step S140), and determines whether the domain is moving (step S141). In particular, by comparing the current location of the domain with the location of the domain obtained from the previous analysis, it is determined whether the domain is moving. The determination may be performed every predetermined period of time. Optionally, the determination can be performed each time a new domain is formed. Optionally, the determination may be arbitrary, depending on the management of the service provider.

An anchor point controller 26 located in the domain 5 can participate in determining the location of the domain 5. At this point, the anchor point controller 26 can be a reference point relative to the location of the formation of the local domain. An anchor point controller 26 may be included in a predefined device that subscribes to domain 5 in a local area. The reference point controller 26 transmits information about the inside of the domain 5, for example, the location information of the domain 5, to the domain manager 22 as a representative of other client devices in the domain.

Alternatively, the reference point controller 26 may not be involved in determining the location of the domain 5. Each device can transmit location information in the domain by gaining access to the domain manager 22. That is, the reference point controller 26 may or may not participate in determining the location of the domain. This is a selectable factor, according to runtimes.

Accordingly, the location of the domain 5 can display the location of the reference point controller 26 in the domain or the location of each device. On the other hand, it is possible to increase security by limiting the number of attempts to select a reference point controller, including reference point controller 26, to a predetermined number. In addition, the user can log in using the controller 26 reference points.

Next, methods for determining the location of a domain will be described.

In the first method, the domain location can be determined using the IP address of the reference point controller 26. In this case, the first method can be performed according to the scheme in which the provider of high-speed Internet access allocates a static IP.

In the second method, the domain location can be determined using the IP address of the subnet of the controller 26 reference points. For example, if the subnet address is similar to the previously discovered subnet address, then we can assume that the domain is not moving. If the subnet address is changed, and also if the TTL is outside of three hops, it is assumed that the domain is moving.

In the third method, if the domain is included in a neighboring area of the reference point controller 26, then the location of the domain is determined using the media access control address (MAC) of the reference point controller 26. For example, if a television set-top box, which is considered as a separate reference point controller using a high-speed Internet provider, is installed in the house, then the periphery of the set-top box is set up as a domain. A device associated with a set-top box is wired or wirelessly determines that the device is a member of a predefined domain. Accordingly, the location of the device can be determined.

In a fourth method, a domain location can be determined using a global positioning system (GPS).

In the fifth method, when using a mobile terminal, for example, a mobile phone, the location of the device in the domain can be determined using the base station.

On the other hand, if it is determined that the domain is being moved, then the domain manager 22 increases the previous number of domain moves by 1 (step S142), and also determines the total number N of domain transfers that has been increased to date (step S143). Alternatively, if the domain is not moving, then the domain 5 that is currently formed is supported (step S147).

Next, the domain manager 22 compares the current total number N of domain transfers with the stored allowed number of domain transfers Na (step S144). If, as a result of the comparison, it is determined that the total number N of domain transfers is equal to or less than the allowed number Na of domain transfers, then the domain manager 22 maintains the current domain 5 (step S147). Alternatively, if the total number N of domain transfers is greater than the allowed number of domain transfers Na, then the domain manager 22 prohibits the use of the current domain (step S145).

Then, the domain manager 22 records a denial of service history with respect to the current user (step S146). Additionally, the domain manager transmits domain deletion information to the service provider. The service provider or domain manager 22 may send a warning message to the user. In addition, the service provider or domain manager 22 prompts the user to purchase new information for entering the domain through a consumer payment system.

On the other hand, the accumulated number of domain transfers can be reset to zero each period, according to the policy of the service provider. For example, the number of domain transfers can be reset annually.

Example 4-2

Fig. 39 is a flowchart illustrating a domain management method according to Example 4-2. Fig. 39 illustrates a procedure for limiting domain formation by checking the location of domain formation.

For this, the domain manager 22 stores the allowed number Ma of domain locations corresponding to the login information. The allowed number of Ma domain locations may depend on the size of payments made by the user. The upper limit of quantity can be politically set by the service provider. The allowed number of Ma domain locations can be set to five, eight, etc. In addition, the domain manager 22 stores and manages the current and previous locations of the domain.

In Fig. 39, the domain manager 22 analyzes the current location of the domain 5 (step S150) and determines whether the domain is moving (step S151). In particular, by comparing the current location of the domain with the location of the domain obtained from the previous analysis, it is determined whether the domain is moving. The determination can be performed every predefined period. Optionally, the determination can be performed each time a new domain is formed. Optionally, the determination may be arbitrary, depending on the management of the service provider.

As described above, the reference point controller 26 may or may not participate in determining the location of the domain 5. The location of the domain 5 can be determined using the IP address, subnet IP address, MAC information of the reference point controller 26, GPS, information about mobile communications, etc.

If it is determined that the domain is not moving, then the domain manager 22 maintains the current domain 5 (step S158). On the other hand, if it is determined that the domain is being moved, then the domain manager 22, by comparing the current location of the domain 5 with the stored previous locations of the domain, determines whether the current location of the domain is a new location (step S152).

If it is determined that the current domain location is not a new location, then the domain manager 22 maintains the current domain 5 (step S158). On the other hand, if the current domain location is a new location, then the domain manager 22 stores the current domain location (step S153).

Subsequently, the domain manager 22 receives the total number M of domain formation locations, including the current location of the domain 5 (step S154), and compares the received number M with the predetermined allowed number of domain locations Ma (step S155). As a result of the comparison, if it is determined that the total number M of domain formation locations is equal to or less than the allowed number Ma of domain locations, then the domain manager 22 maintains the current domain 5 (step S156). Alternatively, if the total number M of domain formation locations is greater than the allowed number of domain locations Ma, then the domain manager 22 deletes the current domain 5 (step S157).

Then, the domain manager 22 records a denial of service history with respect to the current user. Additionally, the domain manager transmits domain deletion information to the service provider. The service provider or domain manager 22 may send a warning message to the user.

As described above, in Example 4-2, the domain manager 22 restricts the formation of the domain according to the locations of the formation of the domain. For example, if the service provider resolves four domain formation locations, then the domain manager 22 automatically remembers the four domain locations from the first domain location, and determines whether the subsequent domain formation location deviates from the allowed four locations. If the domain has been formed exclusively in stored locations, despite the fact that the domain is often moved, the domain is not limited to moving. Alternatively, if the domain moves to a location other than the four stored locations, then the domain manager 22 restricts the formation of the domain.

On the other hand, if the user’s coverage area changes completely, for example, moving the user to a new house, where the domain location does not correspond to the previous domain location, the domain formation location should be re-saved based on the moved location, except for the domain previously saved by the manager 22 domain formation locations. In this case, the information about the location of the formation of the domain can be reset to zero, in response to a specific user request.

In addition, the domain formation location information may be reset to zero by the service provider's policy. In this case, the number of zeros may be limited. For example, the number of zeros of information about the location of the formation of a domain can be limited to one or two times a year. On the other hand, the change in the information about the location of the formation of the domain can be determined using a subscription to service items of information content, as well as information about entering the system, in addition to changing the IP address.

To date, a method for managing a domain has been described, allowing storage and management of the current and previous locations of the domain, as well as limiting the number of domain transfers based on predefined restrictions.

7. Structure, operation and scenario to prevent misuse and contamination of information content

When you enter unreliable content items, such as inappropriate content items or infected content items, etc., into shared media items among various types of DRM through an interoperable DRM system, the user or system may be harmed. A system and scenario are required that allow the resolution of harm problems.

Next, a method for processing information content using an interoperable DRM system will be described in which suitable actions can be prepared by checking whether the externally entered information content is legitimately used, whether it is infected, and whether the security function is applied to it.

40 is a block diagram illustrating a system structure of an environment in which various types of DRM are compatible with each other.

As shown in FIG. 40, the interoperable DRM system 340 provides an interoperable DRM function so that predetermined DRM regions, for example, the first and second DRM regions 320 and 330, are compatible with each other. Fig. 34 describes a case where two DRM regions are compatible with each other using an interoperable DRM system. The present invention is not limited to this. Three or more DRM regions can be compatible with each other using an interoperable DRM system.

The first DRM area 320 may display a protected DRM area including a system or device that uses the first DRM used by the first service provider 322.

The first DRM area 320 may include a first DRM system 323. The first DRM system 323 serves to generate the first DRM content and the first license, which is authorization information, to use the first DRM content by applying the first DRM to the content of the source transmitted by the first content provider 322, as well as the transmission of the generated first DRM content and the first license to the first client device 210. At this stage, your client device 210 may display the device in which the first DRM is installed. Accordingly, the first client device 210 may use the first DRM content within the authority granted by the first license. 40, the first content provider 325 is separated from the first service provider 322. However, the present invention is not limited to this. The first content provider 325 may be similar to the first service provider 322. Alternatively, the first content provider 325 may be included in the first service provider 322.

The first DRM system 323 may communicate with the first security system 325. The first security system 324 is used to apply the security function to the first DRM content. For example, the system can be a fingerprint system that provides a tracking function to track a user who uses information content, a watermarking system to protect the copyright of the author, an anti-virus system to check and treat viral infection of information content, and a system to prevent misuse to prevent the possibility of illegal using content or an attack detection system (IDS).

The second DRM region 330 uses a DRM that is different from the DRM of the aforementioned first DRM region 320. That is, the second DRM region 330 may display a protected DRM region including a system or device using the second DRM used by the second service provider 332.

The second DRM area 330 may include a second DRM system 333. The second DRM system 333 serves to generate a second DRM content and a second license, which is authorization information for using the second DRM content by applying the second DRM to the content of the source transferred to the second content provider 335, as well as for transmitting the generated second DRM content and the second license to the second client device 331. At this stage the second client device 331 may display the device in which the second DRM is installed. Accordingly, the second client device 331 may use the second DRM content within the authority granted by the second license. 40, the second content provider 335 is separated from the second service provider 332. However, the present invention is not limited to this. The second content provider 335 may be similar to the second service provider 332. Alternatively, the second content provider 335 may be included in the second service provider 332.

The second DRM system 333 may communicate with the second security system 334. The second security system 333 is a system for applying the security function to the second DRM content. For example, the system may be a watermarking system, a fingerprint system, an anti-virus system, an abuse prevention system, or IDS.

41 is a block diagram illustrating a detailed structure of a DRM region. The DRM region structure depicted in FIG. 41 can typically be applied to the structure of the first or second DRM region 320 or 330 shown in FIG. 40.

41, an information content provider 380 transmits information content having a raw data type, or information content to which a predetermined security function, such as watermarks, is applied to the DRM system 371.

The DRM server 372 of the DRM system 371 encrypts the transmitted information content using an encryption module, and also transmits to the client device 360 the secret key value used to encrypt the information content and license information, together with the encrypted information content. License information can be transmitted by the server 375 licenses. The DRM client module 361 of the client device 360, which receives the encrypted information content, restores the information content by decrypting the encrypted information content.

In addition, fingerprint information can be inserted into information content that will be transmitted to the client device 360. The fingerprint information is inserted by the fingerprint system 376 included in the service provider 370. Fingerprint system 376 may include a fingerprint generator 377, a controller 378, a fingerprint processor 379, and the like. Fingerprint information for identifying a user of the client device 360 can be inserted into the content transmitted to the client device 360. The fingerprint information can be inserted with a fingerprint reader included in the client device 360.

Fig. 41 shows an example in which a fingerprint function is applied to the content. However, the security function that can be applied to the content may be the aforementioned watermarking function, the misuse prevention function, or the IDS function.

As shown in Figs. 40 and 41, a security system for applying a security function to information content, such as a fingerprint system, a watermarking system, an anti-virus system, an abuse prevention system, IDS and the like, can be installed in DRM service provider. Alternatively, the security system may be included in an interoperable DRM system.

42 is a block diagram illustrating the structure of an interoperable DRM system. Fig. 42 illustrates a case where an interoperable DRM system includes a function for ensuring the reliability of externally inputted content.

As shown in FIG. 42, the interoperable DRM system may further include a security system 9 and a content reliability management node 8. As described above, the security system 9 may display a fingerprint system, a watermarking system, an anti-virus system, an abuse prevention system, or an IDS. The security system 9 may be included in the interoperable DRM system 500. Alternatively, the interoperable DRM system 500 may communicate with another security system.

The content reliability management node 8 may interact with an external inherent DRM domain and includes various processes to ensure the reliability of the content. After a request for external input of information content, the process of the node 8 for managing the reliability of information content can be performed automatically. Alternatively, the process may be performed in response to a request from the processing control node. The process of the content reliability management node 8 will be described according to the following scenario.

Further, if the content has been transmitted in an interoperable DRM environment, scenarios in which the reliability of the content can be ensured will be described. At this stage, in an interoperable DRM environment, content can be transferred from a predetermined DRM region to a DRM region using an interoperable DRM system.

First of all, the following description sequentially describes a scenario to which an anti-abuse policy can be applied after the transmission of information content, a scenario that can prevent the spread of virus-infected information content, after allowing DRM to be compatible with other DRM, a scenario to which the watermarking function can be applied, after allowing DRM to be compatible with another DRM, another scenario to which the function can be applied creating watermarks, after allowing DRM to be compatible with another DRM, a scenario to which a fingerprint function can be applied, after allowing DRM to be compatible with another DRM, another scenario to which a fingerprint can be applied, after allowing DRM to be compatible with another DRM, as well as a processing script used in cases where a user whose fingerprint information does not match the stored information, requests the transfer of information content. For ease of understanding, the first scenario is called Example 5-1. The second scenario is called Example 5-2. The third scenario is called Example 5-3. The fourth scenario is called example 5-4. The fifth scenario is called example 5-5. The sixth scenario is called Example 5-6. The seventh scenario is called Example 5-7.

Example 5-1

Fig. 43 is a functional flowchart illustrating a method for processing content using an interoperable DRM system according to Example 5-1. FIG. 43 illustrates a procedure to which a content misuse prevention policy can be applied after transmitting DRM content in an interoperable DRM environment.

The Prevention of Misuse Policy is designed to prevent the occurrence of DRM content that is being misused. For example, an abuse prevention policy may include a policy that previously prevents the child from viewing adult content that cannot be used by a user under the age of 19.

As shown in FIG. 43, the interoperable DRM system 500 receives a content request message to request transmission of predetermined content from a first client device 410 included in a first DRM area to a second client device 610 included in a second DRM- area 600 (step S170). A request message for transmitting information content may include requested information content, information about a transmitter that transmits information content, information about a receiver that receives information content, and the like. At this stage, since the requested information content is transmitted from the first client device 410 included in the first DRM area 400, the requested information content can display information content to which the first DRM is applied.

When receiving a request for transmitting content, the interoperable DRM system 500 retrieves transmitter information and receiver information from the received request message for transmitting content (step S171). Next, the interoperable DRM system 500 requests a predetermined object of the first DRM region 400 to transmit user information corresponding to the extracted transmitter information (step S172), and also requests a predetermined object of the second DRM region 600 to transmit user information corresponding to receiver information (operation 173).

At this point, the predefined object of the first DRM area 400 may be the first service provider 420. The predetermined object of the second DRM area 600 may be a second service provider 620. Therefore, the first and second service providers 420 and 620 transmit information about the transmitting user and information about the receiving user to the interoperable DRM system 500 in response to the request (steps S174 and S175). Information about the transmitting user and information about the receiving user can be transmitted by transmitting requests and responses between the interoperable DRM system 500 and the providers 420 and 620 services.

Information about the transmitting user can display user information of the first client device 410, which transmits information content. In addition, information about the receiving user can display user information of the second client device 610, which receives information content. Information about the transmitting user and information about the receiving user include predefined user information, which is the standard definition for applying a policy to prevent misuse of information content, such as information about the age of the user.

Then, the interoperable DRM system 500 may request a predetermined object of the first DRM area 400, for example, the first content provider 420 for transmitting content information (step S176). The first service provider 420 transmits information about the content in response to the request (step S177). At this stage, information about information content may include information about a restriction to prevent misuse of information content. For example, information about information content may include information about the age limit of a user who can use information content.

Then, the interoperable DRM system 500 determines the possibility of misuse of information content by comparing and analyzing information about the information content and information about the receiving and transmitting users (step S178), and also informs the first client device 410 about whether the information content has been transferred to the second client device 610, depending on the result of the determination (step S179). In addition, the interoperable DRM system 500 may inform the second client device 610 whether information content has been transmitted. The possibility of misuse of information content is determined using the interoperable DRM system 500 or an external system to prevent misuse.

For example, if the age restriction information included in the information on the content indicates that users under the age of 19 are not allowed, and if the age of the sending user is 15 years, then the DRM interoperable system 500 determines the possibility of misuse of the requested information content, transmits a message to indicate that the content cannot be transferred to the first client device 410, and then stops the procedure.

On the other hand, if the age of the receiving and transmitting users is 24 years, then the interoperable DRM system 500 determines the possibility of legitimate use of the requested information content, and transmits a message to indicate that the information content should usually be transmitted to the first client device 410. After informing about normal transmission, an interoperable DRM system 500 converts license information and a data protection method applied to the requested information content iju from the first DRM to the second DRM (step S180), and transmits the transformation result to the second client device 610 (step S181).

A policy to prevent misuse of content may be defined and adopted through negotiation or consent of DRM providers (not shown) associated with the DRM 500 interoperable system and service providers 420 and 620. In addition, messaging between the first DRM region 400, the interoperable DRM system 500, and the second DRM region 600 may be in the format of an extensible markup language (XML), hypertext markup language (HTML), or shared data. After the transfer of information has been completed, a secure channel can be provided with an enhanced encryption standard (AES) of 128 bits or more.

Example 5-2

Fig. 44 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-2. Fig. 44 illustrates a procedure for preventing the spread of virus-infected content after allowing DRM to be compatible with other DRM.

As shown in FIG. 44, the interoperable DRM system 500 receives a content transfer request message for a request to transmit predetermined content from the first client device 410 to the second client device 610 (step S190). A request message for transmitting informational content includes the requested informational content. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content displays the content to which the first DRM is applied.

When receiving a message requesting to transmit information content, the interoperable DRM system 500, by analyzing the requested information content, determines whether the information content is infected (step S192). According to the determination result, the interoperable DRM system 500 determines whether the content has been transmitted to the second client device 610, and also informs the first client device 410 of the determination result (step S193). At this stage, the interoperable DRM system 500 may also inform the second client device 610 of the determination result.

For example, the interoperable DRM system 500 checks the requested content for viruses. If the content is infected with viruses, then the interoperable DRM system 500 determines that the content cannot be transmitted, sends a message to the first client device 410 to display the result of the determination, and then stops the procedure. In this case, the first client device 410 or the first service provider 420 can remove viruses from the content. The first client device 410 then requests the interoperable DRM system 500 to retransmit the content.

Alternatively, if the requested content is not infected with viruses, then the interoperable DRM system 500 determines that the content should normally be transmitted, and transmits a message to the first client device 410 to display the result of the determination.

Then, the interoperable DRM system 500 performs DRM conversion, in which the license information and the data protection method applied to the requested information content are converted from the first DRM to the second DRM (step S193), and also transmits the conversion result to the second client device 610 (step S194).

On the other hand, the interoperable DRM system 500 determines the possibility of infection of information content. If the content was infected, then an interoperable DRM system can remove viruses from the content, and usually transmit the content. In this case, the interoperable DRM system 500 may include means or a system capable of removing viruses from the information content, or request a separate network-connected anti-virus system to remove viruses from the information content. In addition, the characteristics of viruses that infect information content, as well as the result of removal, can be reported to the first client device 410.

Example 5-3

Fig. 45 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-3. Fig. 45 illustrates an example to which the watermarking function can be applied after allowing DRM to be compatible with another DRM.

As shown in FIG. 45, the interoperable DRM system 500 receives a content transfer request message to request transmission of predetermined content from a first client device 410 to a second client device 610 (step S190). A request message for transmitting informational content includes the requested informational content. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content displays the content to which the first DRM is applied.

Upon receipt of the content transfer request message, the interoperable DRM system 500, by analyzing the requested content, determines whether a watermark has been inserted in the content (step S196). If a watermark has been inserted into the content, then the interoperable DRM system 500 performs a DRM conversion process in which license information and a data protection method applied to the requested content are converted from the first DRM to the second DRM (step S201), and transmits the conversion result to the second client device 610 (step S202).

Alternatively, if a watermark has not been inserted into the requested content, then the interoperable DRM system 500 requests a predetermined object of the first DRM area 400, for example, the first service provider 420, to complete the watermark creation process (step S197). In particular, it is required to insert a watermark in the requested information content. Then, the first service provider 420, which requests the completion of the watermarking process, inserts the watermark in the requested content (step S198), and again asks the interoperable DRM system 500 to transmit the content (step S199).

The interoperable DRM system 500 checks whether a watermark has been inserted into the requested information content (step S200), performs a DRM conversion process in which license information and a data protection method applied to the requested information content are converted from the first DRM to the second DRM ( step S201), and transmits the conversion result to the second client device 610 (step S202).

On the other hand, if means for providing a watermarking function are installed in the first client device 410, then the interoperable DRM system 500 may request the first client device 410 to complete the watermarking process. At this point, the first client device 410 may request the first service provider 420 or content provider to transmit the copyright information to form a watermark, and may also obtain copyright information.

To date, with reference to FIG. 45, a watermark insertion procedure has been described after allowing DRM to be compatible with another DRM. In order to implement the procedure illustrated in FIG. 45, a watermarking system for providing a watermarking function should be included in a predetermined object of the first DRM region 400. Alternatively, if the watermarking system is not included in a predetermined object of the first DRM region 400, then the interoperable DRM system 500 may perform the watermarking process or request a separate watermarking system to complete the watermarking process. These cases will be described below with reference to Fig.

Example 5-4

Fig. 46 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-4. Fig. 46 illustrates another example to which the watermarking function can be applied when DRMs are compatible with other DRMs.

As shown in FIG. 46, the interoperable DRM system 500 receives a content transfer request message to request transmission of predetermined content from a first client device 410 to a second client device 610 (step S210). A request message for transmitting informational content includes the requested informational content. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content displays the content to which the first DRM is applied.

Upon receipt of the content transfer request message, the interoperable DRM system 500 determines whether a watermark has been inserted into the requested content (step S211). If a watermark has been inserted into the content, then the interoperable DRM system 500 performs a DRM conversion process in which license information and a data protection method applied to the requested content are converted from the first DRM to the second DRM (step S215), and transmits the conversion result to the second client device 610 (step S216).

Alternatively, if a watermark has not been inserted into the requested content, then the interoperable DRM system 500 requests a predetermined object of the first DRM area 400, for example, the first service provider 420, to transmit information about the copyright holder of the requested content (step S212) . In particular, information about the copyright holder may be information about the content provider. In this case, the interoperable DRM system 500 may request the first service provider 420 to transfer information about the copyright holder. Alternatively, the interoperable DRM system 500 may directly request the content provider to transfer copyright owner information. Example 5-4 assumes that the copyright owner information is transmitted by the first service provider 420. However, the present invention is not limited to this.

The first service provider 420 transmits copyright owner information to the interoperable DRM system 500 in response to a request for copyright owner information transmitted from the interoperable DRM system 500 (step S213). Then, the interoperable DRM system 500 generates a watermark using the copyright owner information transmitted by the interoperable DRM system 500, decrypts the requested information content, and also performs a watermark creation process in which the generated watermark is inserted into the information content (step S214) . At this point, the interoperable DRM system 500 may include a watermarking system and also use a watermarking system. Alternatively, the interoperable DRM system 500 may directly request a separate network-connected watermarking system to complete the watermarking process.

After the watermarking process is completed, the interoperable DRM system 500 performs the DRM conversion process (step S215). In particular, the license information and the data protection method applied to the content in which the watermark is inserted are converted into a second DRM, which is the target DRM. Then, the interoperable DRM system 500 transmits the converted content to the second client device 610 (step S216).

On the other hand, the interoperable DRM system 500 may enable the watermarking process to be able to execute by transmitting to the first client device 410 information about the address of a separate watermarking system, for example, a URL. In this case, the first client device 410 may directly request the first service provider 420 or content provider of copyright information transfer required for the watermarking process. Alternatively, the interoperable DRM system 500 may transmit to the first client device 410 copyright information transmitted by the first service provider 420 in conjunction with the URL. In addition, the interoperable DRM system 500 may enable the watermarking process to be able to perform by transmitting the URL of a separate watermarking system to the first service provider 420 from the first DRM area 400 or the content provider.

Example 5-5

Fig. 47 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-5. 47 illustrates an example to which a fingerprint function can be applied after allowing DRM to be compatible with another DRM.

As shown in FIG. 47, the interoperable DRM system 500 receives a content transfer request message for a request to transmit predetermined content from a first client device 410 to a second client device 610 (step S221). A request message for transmitting informational content includes the requested informational content. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content displays the content to which the first DRM is applied.

Upon receipt of a content transfer request message, the interoperable DRM system 500 determines whether a fingerprint drawing including user information of the first client device 410 has been inserted into the content by analyzing the requested content (step S222). The determination process can be performed immediately after accepting a request for transmitting content or before performing a DRM conversion.

If it is determined that the fingerprint is normally inserted into the content, then the interoperable DRM system 500 performs a DRM conversion process in which the license information and the data protection method applied to the requested content are converted from the first DRM to the second DRM (step S227) , and also transmits the conversion result to the second client device 610 (step S228).

Alternatively, if it is determined that the fingerprint image has not been inserted into the requested information content, the interoperable DRM system 500 requests the first client device 410 to perform the fingerprint process (step S223). In particular, a fingerprint included in the user information of the first client device 410 must be inserted into the requested information content.

At this stage, an interoperable DRM system can transmit the address information necessary to provide a fingerprint tool to perform a fingerprint process, such as a URL, to the first client device 410 via a URL trigger or reverse channel. Since fingerprinting algorithms are very different, the interoperable DRM system 500 may not save and control all fingerprinting algorithms. Accordingly, the interoperable DRM system 500 must transmit the address of the fingerprint system, which can download fingerprint tools to the first client device 410 using the algorithm in the first DRM region 400. The address of the fingerprint system can be obtained by transmitting requests and responses between the interoperable DRM system 500 and the first provider of 420 services.

A fingerprint system may be included in the first provider 420 of services. Alternatively, the fingerprint system may be a predefined server communicating with a service provider 420. However, if the fingerprint function is not included in the first DRM region 400, then the first service provider 420 cannot provide a fingerprint function. In this case, the interoperable DRM system 500 can transmit information about the address of an individual fingerprint system that allows fingerprinting to be provided to the first client device. In addition, if predefined fingerprints are installed in the first client device 410, then the interoperable DRM system 500 may not transmit additional address information and requests the first client device 410 to perform a fingerprint process using the installed fingerprint tools.

The first client device 410 requested to perform the fingerprint process can perform a fingerprint process by downloading fingerprint tools using the address information received from the interoperable DRM system 500, or perform a fingerprint process using the installed fingerprint tools (step S224). In particular, the fingerprint included in the user information is inserted into the requested information content.

Then, the first client device 410 re-requests the interoperable DRM system 500 to transmit content in which the fingerprint is inserted to the second client device 610 (step S225). Then, the interoperable DRM system 500 checks whether a fingerprint has been inserted into the requested information content (step S226), performs a DRM conversion process in which license information and a data protection method applied to the requested information content are converted from the first DRM to the second DRM (step 227), and also transmits the conversion result to the second client device 610 (step S228).

On the other hand, although not shown, the interoperable DRM system 500 may request a second client device 610, which receives information content, to perform a fingerprint process. In this case, the interoperable DRM system 500 can transmit information about the address of the fingerprint system that allows the fingerprint process to the second client device 610. At this stage, information about the address of the fingerprint system can be obtained by transmitting requests and responses between the interoperable DRM system 500 and a second provider of 610 services. In addition, if the second service provider 610 does not include a fingerprint function, then the interoperable DRM system 500 may transmit the address of a separate fingerprint system.

Example 5-6

Fig. 48 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-6. 48 illustrates another example to which a fingerprint function can be applied after allowing DRM to be compatible with another DRM. In Example 5-6, an interoperable DRM system includes fingerprints.

As shown in FIG. 48, the interoperable DRM system 500 receives a content transfer request message to request transmission of predetermined content from the first client device 410 to the second client device 610 (step S230). A request message for transmitting informational content includes the requested informational content. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content displays the content to which the first DRM is applied.

The received message requesting the transfer of information content includes information about the transmitting and receiving users, that is, information about the user of the first and second client devices 410 and 610.

Then, the interoperable DRM system 500 determines whether a fingerprint included in the user information of the first client device 410 has been inserted into the information content by analyzing the requested information content (step S231). If the fingerprint was inserted into the requested information content, the interoperable DRM system 500 performs a DRM conversion process in which the license information and data protection method applied to the requested information content are converted from the first DRM to the second DRM (step S233), and also transmits the conversion result to the second client device 610 (step S234).

Alternatively, if the fingerprint image has not been inserted into the requested information content, the interoperable DRM system 500 generates a fingerprint image including the received user information of the first client device 410, using the fingerprint tools included in the interoperable DRM system 500, encrypts the requested information content, and also performs a fingerprint process, in which the generated fingerprint is inserted into the information content holding (step S232). Fingerprints are stored in a predefined device of the DRM 500 interoperable system in the form of a cache. Fingerprint tools can function after the fingerprint process.

Upon completion of the fingerprint process (step S232), the interoperable DRM system 500 performs the DRM conversion process (step S233).

In particular, the license information and the data protection method applied to the information content into which the fingerprint is inserted is converted into a second DRM, which is the target DRM. Then, the interoperable DRM system 500 transmits the converted information content to the second client device 610 (step S234).

On the other hand, the interoperable DRM system 500 may insert a fingerprint drawing including information about a second client device 610 that receives information content into the information content. In this case, the interoperable DRM system 500 must store the corresponding fingerprints in the form of a cache.

Example 5-7

Fig. 49 is a functional block diagram illustrating a method for processing content using an interoperable DRM system according to Example 5-7. Fig. 49 illustrates a procedure for informing a system that includes or distributes information content that the fingerprint information of the information content does not match user information when a user whose fingerprint information does not match user information requests to transmit information content .

As shown in FIG. 49, the interoperable DRM system 500 receives a content transfer request message to request transmission of predetermined content from a first client device 410 to a second client device 610 (step S250). A message requesting the transfer of information content includes information about the sending and receiving users, that is, information about the users of the first and second client devices 410 and 610. In addition, a fingerprint image is inserted into the requested information content.

The interoperable DRM system 500 compares and analyzes user information included in the fingerprint information inserted in the requested information content, as well as user information of the first client device 410 (step S251). When an error is found in which the user information included in the fingerprint image does not match the user information of the first client device 410 (step S252), the interoperable DRM system 500 informs the first client device of the error (step S254). In addition, the interoperable DRM system 500 transmits a failure to the second client device 610 to indicate that content sharing is not approved at (step S253). Accordingly, illegal information content, the fingerprint of which does not correspond to the user information of the first client device 410, cannot be transmitted.

While the present invention has been depicted and described in detail with reference to illustrative embodiments, those skilled in the art will understand that various changes in form and detail can be made therein without departing from the spirit and scope of the present invention as defined using the attached claims.

Claims (20)

1. A method for controlling data transmission in an interoperable data medium, performed by the controller, including the steps of:
receive a request from the client, and the request requests the transfer of data from the source to the recipient, and the data contains at least one element of information content or at least one license;
collect information from facilities regarding facilities that should be involved in data transmission;
form a chain that includes at least two objects, based on the collected information;
controlling at least two objects for transmitting data from a source to a destination through a chain; and
receive from at least one of the objects included in the circuit, an event message describing the state of transmission. 2. The method according to claim 1, in which the request further comprises:
transmission session identifier; and
data identifier associated with the data. 3. The method according to claim 1, in which the step of collecting information regarding the objects further includes the steps in which:
interrogate objects for information on functional characteristics;
receive information about functional characteristics from objects; and
access data describing the functional characteristics of sources, intermediaries, recipients, and a digital rights management system (DRM), using the received information about the functional characteristics. 4. The method according to claim 1, further comprising the step of determining, using the collected information, whether to transmit data based on the request. 5. The method according to claim 1, in which at least two objects include:
an exporter configured to export data from a source and transmit exported data;
a converter configured to convert the transmitted, exported data into a data format supported by the destination, and transmit the converted data; and
an importer, configured to receive the transmitted, converted data, and provide the received data to the addressee. 6. The method according to claim 1, in which at least two objects include:
an exporter configured to export data from a source and transmit exported data; and
an importer configured to receive the transmitted data and provide the data to the addressee. 7. The method according to claim 1, further comprising transmitting the event message to the client in accordance with the received event message, the event message describing the transmission status. 8. A device for controlling data transmission in an interoperable data medium, comprising:
an interface configured to:
receiving a request from a client, the request requesting the transfer of data from the source to the recipient, and the data contains at least one element of information content or at least one license, and
receiving from at least one of the objects included in the circuit, an event message describing a transmission state; and
a processor configured to:
collection of information from objects in relation to objects that should be involved in data transmission;
forming a chain comprising at least two objects, based on the collected information; and
control of at least two objects for transmitting data from a source to a destination through a chain. 9. The device of claim 8, in which the request further comprises:
transmission session identifier; and
data identifier associated with the data. 10. The device according to claim 8, in which the collection of information regarding the objects further includes the steps at which:
interrogate objects for information on functional characteristics;
receive information about functional characteristics from objects; and accessing data describing the functional characteristics of the sources, intermediaries, recipients, and the digital rights management system (DRM) using the received information about the functional characteristics. 11. The device according to claim 8, in which the processor is additionally configured to determine, using the collected information, whether to transmit data based on the request. 12. The device of claim 8, in which at least two objects include:
an exporter configured to export data from a source and transmit exported data;
a converter configured to convert the transmitted, exported data into a data format supported by the destination, and transmit the converted data; and the importer, configured to receive the transmitted, converted data, and provide the received data to the addressee. 13. The device of claim 8, in which at least two objects include:
an exporter configured to export data from a source and transmit exported data; and an importer configured to receive the transmitted data and provide the data to the addressee. 14. The device according to claim 8, in which the interface is further configured to transmit an event message to a client in accordance with the received event message, the event message describing the transmission status. 15. A data transmission control system in an interoperable data medium, comprising:
customer and
a controller configured to
receive a request from the client, and the request requests the transfer of data from the source to the recipient, and the data contains at least one element of information content or at least one license;
to collect information from objects in relation to objects that should participate in the transfer of data;
form a chain that includes at least two objects, based on the information collected;
manage at least two objects for transmitting data from a source to a destination through a circuit; and
receive from at least one of the objects included in the chain, an event message describing the state of transmission. 16. The system of clause 15, in which the request further comprises:
transmission session identifier; and
data identifier associated with the data. 17. The system of clause 15, in which the collection of information in relation to objects includes operations in which:
interrogate objects for information on functional characteristics;
receive information about functional characteristics from objects; and
access data describing the functional characteristics of sources, intermediaries, recipients, and a digital rights management system (DRM), using the received information about the functional characteristics. 18. The system of clause 15, in which the controller is additionally configured to:
determine, using the information collected, whether data should be transmitted based on the request. 19. The system of clause 15, in which at least two objects include:
an exporter configured to export data from a source and transmit exported data;
a converter configured to convert the transmitted, exported data into a data format supported by the destination, and transmit the converted data; and
an importer, configured to receive the transmitted, converted data, and provide the received data to the addressee. 20. The system of clause 15, in which at least two objects include:
an exporter configured to export data from a source and transmit exported data; and
an importer configured to receive the transmitted data and provide the data to the addressee.

Images