Domain management method, domain extension method and domain system

FIELD OF THE INVENTION The present invention relates to a method for managing a domain, a method for expanding a domain, and a method for selecting a reference point controller. More specifically, it relates to a method for managing a domain, a method for expanding a domain, and a method for selecting a reference point controller. A method of recovering the operating domain of the function of the reference point controller when an error occurs in the reference point controller, and a method of expanding the domain and a method of selecting the reference point controller related thereto.

2. Description of the Related Art Generally speaking, digital content is different from analog content and can be copied indefinitely without loss of information. Therefore, digital content may be vulnerable to illegal copying and use. This is why it is necessary to support content protection technologies that can stably protect digital content from illegal copying and use to provide digital content services.

Digital Rights Management (DRM) is a general digital content protection technology that allows only legally authorized users to use digital content. Although DRM includes security technology, watermark technology, anti-tampering technology, etc., more accurately, DRM represents a framework rather than a technology.

DRM focuses on thoroughly preventing illegal copying and use of content. In DRM, digital content is converted into encrypted data in the form of data packets by using encryption technology. Therefore, even if a predetermined user obtains digital content accidentally, the digital content cannot be used without a legality authentication process.

Most legal content services provided through a wired/wireless communication network such as the Internet or a mobile communication network can only be performed by DRM devices that support DRM adopted by the service provider of the corresponding content or the content provider. This is caused by the closed nature of DRM's technology and policies.

200780006766.9 On the other hand, the advantage of the closed technology and policy of DRM is to ensure the legality of the content. However, the problem is that users are restricted from using content. This is because the DRM device or DRM using software in which the DRM adopted by the service provider is installed must be separately included so that the user can use digital content provided by multiple service providers. In this case, the user must perform contract signing, payment, authentication, etc. separately.

The foregoing problems reduce the flexibility of the distribution structure of digital content. Ultimately, this problem caused restrictions on digital content services.

Recently, it is planned to provide a framework in which closed DRM structures are compatible with each other. In order to allow different types of DRM to be compatible with each other, a DRM interoperating system that arbitrates the differences between closed DRMs is needed. The DRM interoperating system can be realized by defining system resources and proposing an operation model for generating and managing the defined system resources. In addition, in order to support the DRM interoperating system, various scenarios (scenarios) using the defined system resources and operating models must be proposed.

[Disclosure] [Technical Problem] The present invention provides a method of operating a domain, which can restore the function of the reference point controller by using reference point controller candidates when an error occurs in a reference point controller.

The present invention also provides a method for expanding the domain. By introducing the concept of the reference point controller agent, the method can improve the flexibility of the domain.

The invention also provides a method for effectively selecting the reference point controller.

Technical solutions

200780006766.9 According to one aspect of the present invention, there is provided a method for operating a domain by using a management entity for managing the domain. The method includes: receiving a request for authenticating a reference point controller from a reference point controller candidate; The stored membership of the reference point controller is invalid; generating a unique reference point controller membership for verifying that the reference point controller candidate is a new reference point controller; and transmitting the generated reference point controller candidate to the reference point controller candidate Membership of the reference point controller.

In the above aspect of the present invention, the method may further include storing the generated reference point controller membership for the domain. In addition, the reference point controller candidate may be a reference point controller candidate having the highest priority among a plurality of reference point controller candidates.

According to another aspect of the present invention, there is provided a method of operating a domain, the method comprising: selecting a reference point controller capable of determining the range of a local area in which the domain is constructed in a management entity and registering the reference point Controller; selecting at least one reference point controller candidate capable of replacing the function of the reference point controller and registering the at least one reference point controller candidate in the management entity; and when controlling at the registered reference point When an error occurs in the device, the reference point controller candidate is used to replace the reference point controller.

In the above aspect of the present invention, selecting and registering the reference point controller may include: transmitting and receiving capability information between devices subscribing to the domain; by comparing the capability information of each device with the received capability of another device The information is compared to perform a selection competition, in which devices with lower capabilities are eliminated; the device that ultimately survives the selection competition is selected as the reference point controller; and the selected reference point controller is allowed to report to the The management entity reports that the selected reference point controller is selected as the reference point controller and allows the selected reference point controller to register with the management entity.

In addition, selecting and registering the reference point controller may include: providing the management entity with capability information of the device subscribed to the domain; allowing the management entity to analyze the provided device capability information to determine the device with the highest capability Select as the reference point controller and

200780006766.9 first and register the selected device.

In addition, selecting and registering the reference point controller may include: transferring the capability information between devices in the domain; and comparing the capability information of each device with the received capability information of another device. Perform a selection competition, in which devices with lower capabilities are eliminated; the device that ultimately remains in the selection competition is selected as a reference point controller; and the selected reference point controller is allowed to report the selected reference to the management entity The point controller is selected as the reference point controller and allows the selected reference point controller to register with the management entity.

In addition, an information signal indicating that the reference point controller and the reference point controller candidate are operating normally may be transmitted between the reference point controller and the reference point controller candidate through a predetermined route. The reference point controller and the reference point controller candidate may determine whether an error occurs in the reference point controller and the reference point controller candidate according to whether the information signal is normally transmitted.

According to another aspect of the present invention, there is provided a method for expanding the domain by using an entity that constructs the domain, the method comprising: selecting a reference point controller agent capable of interacting with the domain for constructing an extended domain Register the selected reference point controller agent in the management entity of the domain; and allow the registered reference point controller agent to determine the scope of the local area in which the extended domain with the same authority as the domain is constructed.

According to another aspect of the present invention, there is provided a method for selecting a reference point controller. The method includes: transmitting and receiving device information between devices in a reserved domain; and comparing the device information of the device with the received device information according to a predetermined algorithm. Compare the device information of other devices in the device to perform selection competition in the device; and select the device that ultimately survives in the selection competition as the reference point controller of the domain.

In the above aspect of the present invention, the transmitting and receiving the device information may include: setting the device information of the device; and continuously broadcasting information including the set device information

200780006766.9 The standardized grouping.

In addition, the device information may include: domain information for identifying the domain; device identification information for identifying the device; and capability information, which includes capability information for identifying the capability of the device according to a predetermined standard .

According to another aspect of the present invention, there is provided a method of selecting a reference point controller by using an entity for managing a domain, the method comprising: receiving capability information of the device from a device subscribing to the domain; and The reference point controller used to determine the range of the local area in which the domain is formed is selected by analyzing the received device capability information.

BRIEF DESCRIPTION OF THE DRAWINGS By describing the exemplary embodiments of the present invention in detail with reference to the accompanying drawings, the above and other features and advantages of the present invention will become more apparent, in which: Figure 1 shows a DRM according to an exemplary embodiment of the present invention A block diagram of the concept and main functions of the interoperating system; FIG. 2 is a block diagram showing the schematic structure of the DRM interoperating system according to an exemplary embodiment of the present invention; Examples of contents; Fig. 4 shows an example in which the client requests the processing control part to transmit a license; Fig. 5 is a block diagram showing the domain, the entities constituting the domain, and the relationship between the entities; Fig. 6 shows the selection reference An example of the format of the DPDU data packet required by the point controller; Fig. 7 is a flowchart showing the process of automatically selecting the reference point controller by using DPDU; Fig. 8 is a diagram showing the selection reference according to Example 1-2 A flowchart of a method of a point controller; FIG. 9 is a flowchart showing a process of selecting a reference point controller candidate according to Example 2-1; FIG. 10 is a flowchart showing a reference point controller for transmitting an information signal and Control at reference point

200780006766.9 Block diagram of the connection between the controller candidates; FIG. 11 is a block diagram showing an example in which a typical domain device and a typical candidate domain device transmit information signals; FIG. 12 is a diagram showing the concept of a reference point controller agent Block diagram; Figure 13 is a flowchart showing the process of registering a reference point controller; Figure 14 shows an example of the structure of the unique information used to manage legacy equipment; Figure 15 is a diagram showing the authentication of legacy equipment The flowchart of the process; Figure 16 shows an example of the structure of the DRM interoperating system for managing the information of users who use the legacy equipment; Figure 17 is a flowchart showing the process of registering the legacy equipment to the domain; Figure 18 Is a block diagram showing the structure of the processing control section and the content processing section; FIG. 19 shows an example for showing the positions of the content processing controller and the content processing body; FIG. 20 shows an example for showing the content processing control Examples of other locations of the content processing body and the content processing body; FIG. 21 is a flowchart showing the process of transmitting content by using the content processing controller and the content processing body; FIG. 22 shows a diagram for showing the multiplexing protocol Example; Fig. 23 is a block diagram showing a system structure for a content transmission process according to Example 3-2; Fig. 24 is a flowchart showing a content transmission process according to Example 3-2; The main content conversion chain for transmitting one or more content to the first target device; Fig. 26 shows an auxiliary content conversion chain for transferring one or more contents to a second target device; Fig. 27 is a block diagram showing a system structure for a content transmission process according to Example 3-3; Fig. 28 is Shows a flowchart of a content transmission process according to Example 3-3; FIG. 29 shows an example of a main content conversion chain constructed using a content processing controller;

200780006766.9 Fig. 30 shows an example of an auxiliary content conversion chain constructed using a content processing controller; Fig. 31 is a block diagram showing a system for delivering content according to Example 3-4; Fig. 33 shows an example of the main content conversion chain constructed by the content processing controller; Fig. 34 shows the first auxiliary content conversion chain and the first auxiliary content conversion chain caused by the content processing controller. An example of the structure of the second auxiliary content conversion chain and the third auxiliary content conversion chain; FIG. 35 is a block diagram showing the structure of a system related to the transmission license; FIG. 36 is a block diagram showing the units included in the entity Examples of the functions of the functional modules and the unit functional modules; FIG. 37 shows an example for illustrating the process of transferring events between two authenticated entities; FIG. 38 is a diagram showing the management domain according to Example 4-1 Fig. 39 is a flowchart showing a method of managing a domain according to Example 4-2; Fig. 40 is a block diagram showing a system structure of an environment in which different types of DRMs are compatible with each other; Fig. 41 is a diagram showing A block diagram showing the detailed structure of the DRM area; FIG. 42 is a block diagram showing the structure of the DRM interoperating system; FIG. 43 is a function showing the method of processing content by using the DRM interoperating system according to Example 5-1 Block diagram; Figure 44 is a diagram showing processing by using the DRM interoperating system according to Example 5-2 Fig. 45 is a functional block diagram showing a method of processing content by using a DRM interoperating system according to Example 5-3; Fig. 46 is a functional block diagram showing a method for processing content by using DRM according to Example 5-4; A functional block diagram of a method of processing content by an operating system; FIG. 47 is a functional block diagram showing a method of processing content by using a DRM interoperating system according to Example 5-5; FIG. 48 is a functional block diagram showing a method according to Example 5-6 A functional block diagram of a method of processing content by using the DRM interoperating system; and FIG. 49 is a diagram showing processing by using the DRM interoperating system according to Examples 5-7

200780006766.9 The functional block diagram of the method of the content.

DETAILED DESCRIPTION Now, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In addition, in order to clearly describe the exemplary embodiments with reference to the accompanying drawings, specific technical terms are used. However, the present invention is not limited to the selected specific technical terms, and each specific technical term includes all technical synonyms that operate in a similar manner in order to obtain similar entities.

FIG. 1 is a block diagram showing the concept and main functions of the DRM interoperating system according to an exemplary embodiment of the present invention.

As shown in FIG. 1, the DRM interoperating system 1000 is used to allow services to be compatible with each other between different DRM regions. The DRM interoperating system 1000 can perform data interoperability control functions fl, data interoperability functions £2, status display functions £3, domain management functions f4, and so on.

The data interoperability control function fl is used to control the interoperability of data so that the data are compatible with each other. At this time, the data may indicate content or license. Specifically, the data interoperability control function fl includes a content interoperability control function fla and a license interoperability control function f2bo. The data interoperability function £2 may mean that it is allowed under the control of the data interoperability control function fl. Content or license compatible functions. For example, according to the data interoperability function £2, the data (such as content or license) of system A or device A in DRM area A can be provided to system B in DRM area B or device Bo in DRM area B The content or license of B or device B can be provided to system A or device A in DRM area A. Specifically, the data interoperability function f2 may include the content interoperability function f2a and the license interoperability function f2bo. The status display function. 3 may indicate the operating status of the DRM interoperability system 100.

200780006766.9 No. function. For example, the status display function f3 may include an event function f3a such as a channel formation event function, an event function f3b related to transmission, an event function f3c related to conversion, and the like.

The domain management function f4 may represent a function of managing a domain for authentication and management of clients. The domain management function f4 may include the reference point controller registration/management function f4a, the legacy equipment management function f4b, and so on.

Hereinafter, the structure and operation of the system for performing the aforementioned functions will be described in detail.

*System structure and operation* FIG. 2 is a block diagram showing a schematic structure of a DRM interoperating system in which different types of DRM are compatible with each other.

As shown in FIG. 2, the DRM interoperating system may include a client part 10, an authentication and management part 20, a processing control part 40, a content processing part 50, and a license processing part 30.

One or more entities can be used to construct the above-mentioned parts. At this time, the entity may mean a module or device configured as software or hardware that performs a predetermined unique function. Each entity may be a group of one or more unit function modules that perform predetermined unit functions. The entity is installed in a predetermined device to communicate data with another entity through a predetermined interface. In addition, even if the entities belong to the same part, the entities can be installed or implemented in different devices. The equipment may vary based on the execution environment.

Hereinafter, the function of the entities included in each part and the operations performed through the interaction between the entities will be described, and the characteristic structure and function of each part will be described.

1. Functions and operations of the client part The client part 10 may include a client. The client is an entity that cooperates with the authentication and management part 20 and the processing control part 40 to provide various functions so that the user can

200780006766.9 The first use of DRM interoperability services.

The client can be included in the user's device. The device including the client is referred to as the client device.

The client can be authenticated by requesting the authentication and management section 20 to authenticate the client. The authenticated client may request the processing control section 40 to transfer predetermined data, for example, predetermined content or a license, to a desired target by calling a predetermined entity. Here, the target may be a device or a software system in which a DRM different from the DRM applied to the predetermined content or license is installed, for example, another client device in the domain.

3 and 4 show examples in which the authenticated client requests the processing control section 40 to transmit data. FIG. 3 shows an example in which the client requests the processing control section 40 to transfer content. FIG. 4 shows an example in which the client requests the processing control section 40 to transfer a license.

As described in FIG. 3, the client requests the content processing controller 41 of the processing control section 40 to transmit content. Then, the content processing controller 41 controls the content processing section 50 so that the requested content is transferred to the desired destination. At this time, the content format and DRM of the requested content may be different from the content format and DRM required by the target. The content processing section 50 processes the content so that the content meets the conditions required by the target and provides the processed content to the target. The transmission and processing procedures will be described later with reference to FIGS. 18 to 34.

In addition, as shown in FIG. 4, the client requests the license processing controller 42 of the processing control section 40 to transfer the license. Then, the license processing controller 42 controls the license processing section 30 so that the requested license is transferred to the desired destination. At this time, the format of the requested license may be different from the format of the license required by the target. The license processing section 30 processes different attributes so that the conditions required by the target are satisfied and the processing result is provided to the target. The process of processing and transferring the license will be described later with reference to FIG. 35.

200780006766.9 On the other hand, the client may include typical functions of the client, for example, the function of using (or reproducing) content, the user interface function, and so on. In this case, the client can be the end of content consumption.

The client must be authenticated as a legitimate client by the authentication and management section 20 and managed. In order to easily perform the above process, the DRM interoperating system can introduce the concept of domain.

The domain (domain) is the basic unit of the DRM trust framework and represents the actual application range of the DRM interoperating system. A set of authorized devices or systems can be used to construct a domain. For example, a domain may include a set of authorized client devices. In this case, although the client devices in the domain include different DRM content, the client devices can share the content.

2. Functions and operations of the authentication and management part Fig. 5 is a block diagram showing the domain, the entities constituting the domain, and the interrelationship between the entities. Figure 5 shows entities related to client authentication and management.

Referring to Figure 5, the DRM interoperating system forms domain 5. The physical location of the client device 12 can be considered to construct the domain 5. Specifically, the domain 5 is constructed using authorized client devices 3 in a predetermined physical area. Alternatively, only logically authenticated client devices may be used to construct the domain 5 regardless of the physical location of the client device 12.

In the present invention, as described above, although the physical location of the client device 3 is considered to construct a domain using the client device 3 in a predetermined local area, an example is exemplified in which the physical location of the client device 3 is outside the predetermined local area in the network area. The client device also subscribes to the situation of the domain. However, this is an example of the embodiment. The present invention is not limited to this.

A local environment is needed to construct domain 5. At this time, the local area environment means that a physical network is prepared so that devices in a predetermined local area interact with each other, and where the physical network

200780006766.9 The environment for the interaction between the network and the external network.

As an example for providing a local area environment, there is a home network system. Generally, in a home network system, household appliances, various sensors, security devices, etc. can interact with each other through a wired/wireless local area network and can interact with an external network such as the Internet through a communication node such as a home gateway. Two or more interactive network devices other than the home network system can be used to construct a local area environment.

The following local area is assumed to be an area in which the above-mentioned local environment is prepared. In this local area, there may be multiple client devices 3. By requesting the authentication and management section 20 to authenticate the client 3, the client 3 included in the client device 12 can be authenticated as a legitimate client. The device including the authenticated client 3 is the client device 12. Different DRM contents can be used in the client device 3 within the scope permitted by the license.

Therefore, the user sets the user's home as a local area and constructs a domain by using devices including different DRMs in the home. Then, share and use content between devices.

However, in addition to the client 12 in the local area, through authentication, it is also possible to provide services to the client in the external network area. In this case, it is necessary to distinguish the status of the client authenticated in the network from the status of the client 3 authenticated in the local area, and manage the status separately. To this end, the status of the authenticated client can be classified into a remote status and a local status, and can be managed.

5, the authentication and management part 20 for authenticating and managing the client 3 includes a domain manager 22, a license manager 24, and a reference point controller 26.

The domain manager 22 is designed to monitor the domain 5. For example, the domain manager 22 may perform the following functions: create domain 5, destroy domain 5, associate a client with domain 5, delete a client from domain 5, register reference point controller 26, and so on.

200780006766.9 The domain manager 22 may exist in any location in the local area or the network area. For example, in the example shown in FIG. 5, the domain manager 22 is located in the network area. In this case, the domain manager 22 can interact with the reference point controller 26 and the client 3. Alternatively, the domain manager can be located in the local zone. In this case, the domain manager is included in the device in the local area to interact with the reference point controller and the client.

The license manager 24 is designed to manage user's license information. For example, the license manager 24 may provide users with a login function and perform the functions of a typical online service manager that stores and manages license information. The license manager 24 can perform the following functions: create a user name, delete a user name, associate license information with a user name, create license information, delete license information, and so on.

The license manager 24 may be located in a network area, such as a server of a service provider. However, the license manager 24 may be located in a network area such as a server of a service provider. Alternatively, the license manager 24 may be located in the local area. That is, the domain manager 22 and the license manager 24 may be located in any location in the local area or the network area.

The reference point controller 26 checks whether a predetermined entity is located in the local area, and provides the verified entity with a certificate confirming that the entity is located in the local area. To this end, the reference point controller 26 can determine the extent of the local area. At this time, the range of the local area can be determined by using physical distance, number of jumps, reaction time, etc.

The reference point controller 26 checks whether the client 3 is located in the local area according to the request of the client 3. When it is determined that the client 3 is located in the local area, the reference point controller 26 may provide a domain certificate confirming that the client 3 is located in the local area. When the client 3 requests the domain manager 22 to authenticate the client 3, the domain certificate can be provided to the domain manager 22. The domain manager 22 confirms that the client 3 is located in the local area and authenticates the client 3.

In addition, the domain manager 22 determines based on the domain certificate whether the client 3 is in a remote state or

200780006766.9 The local state. The domain manager 22 can limit the number of clients accessing the domain manager 22 in a remote state by identifying the state of the client 3 to prevent multiple clients from accessing the domain through the network and improve security.

The reference point controller 26 may be located in the local area. Specifically, the reference point controller 26 may be determined as a device located in the local area. Although the advantage is that the reference point controller 26 is determined as a device such as a set-top box, a desktop PC, etc., which includes multiple computing resources and does not have mobility, it is possible to determine the reference point controller 26 as a highly mobile device.

When the domain is initially constructed, the reference point controller 26 can be selected according to a predetermined process. Specifically, when the domain 5 is initially constructed, a device for performing the function of the reference point controller for determining the range of the local area is selected. The selected device must be determined as the reference point controller 26. At this time, the determined reference point controller 26 is registered with the domain manager 22. Then, the client 3 can query the domain manager 22 about the reference point controller 26.

-The choice of reference point controller There are three ways to select the reference point controller.

The first method is that the devices that wish to subscribe to the domain communicate device information with each other and compare the device information according to a predetermined algorithm, so that the most appropriate device is selected as the reference point controller. The selected reference point controller must report to the domain manager that the device is selected as the reference point controller. Then, the device must be registered to the domain.

The second method is to wish to register the device of the domain to report the device information of the device to the domain manager, and the domain management entity selects the reference point controller based on the reported device information.

The third method is to select the reference point controller through predetermined information. At this time, the predetermined information can be set by the administrator or the user. Alternatively, the predetermined information may include arbitrarily determined information. For example, when an administrator or a user inputs predetermined information into the domain manager, the domain manager can select a reference point based on the predetermined information

200780006766.9 No. controller. Alternatively, the reference point controller may be established by allowing an administrator or user to directly select a device to be used as the reference point controller.

Hereinafter, the above three methods will be described in detail. For ease of understanding, the above-mentioned first method of selecting the reference point controller is referred to as Example 1-1. The second method of selecting the reference point controller is called Example 1-2. The third method of selecting the reference point controller is called Example 1-3.

<Example 1-1>

First, before describing the process of selecting the reference point controller, define the data format of the domain payload data unit (DPDU: domain payload data unit). DPDU is a standardized data format used to transmit device information of each device when selecting a reference point.

Fig. 6 shows an example of the format of a DPDU data packet required to select a reference point controller.

Referring to Figure 6, the DPDU is structured to have a domain header and a domain payload.

The domain header includes a device capability identifier (hereinafter, abbreviated as DC-ID), a domain identifier (hereinafter, abbreviated as D-ID), and a device entity identifier (hereinafter, abbreviated as DE-ID) ο

The DC-ID is information for identifying the capability value of the device. At this time, the ability value can be used to display the device's predetermined items (for example, remaining energy, hardware specifications, network connection speed, network capabilities, outward mobility, system stability, computing power, resource consumption, etc.) Ability information. Before or after the device enters the domain, an arbitrary value can be assigned to the DC-ID according to a predetermined standard determined by the administrator or an arbitrary value can be generated by the corresponding device. DC-ID is a standard used to select the most appropriate device when selecting a reference point controller.

200780006766.9 No.

D-ID is information used to classify domains according to the environment and attributes of the device. As described above, the domain may be an area classified according to a physical area classification standard, or may be an area classified by a logical authentication service. Therefore, D-ID is information that classifies domains according to physical areas, or information that classifies domains according to logical services.

DE-ID is information used to identify each device belonging to the domain.

On the other hand, the domain payload is a field for recording general data and error check information. At this time, the general data represents information about the device and the DRM reliability system. In addition, the error check information may indicate information used to check the error of the DPDU data packet.

As described above, the DPDU includes information for distinguishing the capabilities of devices subscribing to the domain from each other. Therefore, the DPDUs are exchanged between the devices in the domain, and the capabilities are compared with each other. Therefore, a capable device can be selected, and the capable device can be determined as the reference point controller. Hereinafter, the above-mentioned process will be described in detail.

FIG. 7 is a flowchart showing a process of automatically selecting a reference point controller by using DPDU.

Referring to FIG. 7, when the process starts, the device (for example, the client device) of the subscribed domain sets the DC-ID value X, the D-ID value Y, and the DE-ID value Z to predetermined values (operation S1).

At this time, the setting value of the DC-ID is allocated according to a predetermined standard, or the setting value of the DC-ID is generated in the corresponding device. These two situations will be described separately below.

1. The situation where the administrator assigns a DC-ID value according to a predetermined standard The administrator recognizes the capability information of each device by using a predetermined management device, converts the capability information into a capability value according to a predetermined standard, and converts the capability Value assigned to

200780006766.9 The DC-ID value of the device. At this time, the management device may be a predetermined device in a domain, a device located at another communicable location, or a predetermined system (for example, a domain manager) in a network area.

For example, when the DC-ID value is determined based on the remaining energy, the administrator checks the battery remaining amount of each device in the domain, expresses the battery remaining amount as a number according to a predetermined standard, and assigns the DC-ID value to the device . Then, the DC-ID value of the device is determined, that is, the DC-ID of the device A is 4, the DC-ID of the device B is 8, and the DC-ID of the device C is 2.

2. The situation where the DC-ID value is generated by the corresponding device Each device recognizes the capability information, converts the capability information into a capability value according to the previously stored information, and sets the capability as the DC-ID value.

For example, when the DC-ID value is determined based on the remaining amount of energy, the device checks the remaining amount of the battery, and represents the remaining amount of the battery as a number according to the previously stored battery remaining amount-energy remaining amount map, and generates the DC-ID value. Then, the DC-ID value of the device is determined, that is, the DC-ID value of the device A is 4, the DC-ID of the device B is 8, and the DC-ID of the device C is 2. At this time, the battery remaining amount-energy remaining amount mapping table may be received from the management device and stored. Alternatively, the battery remaining amount-energy remaining amount mapping table may be stored when the product is manufactured.

In Example 1-1, it is assumed that when the battery capacity is high, the DC-ID value is set to a small value. In this case, when the DC-ID value becomes smaller, the device has a higher capacity. However, the present invention is not limited to this. Alternatively, it may be assumed that when the battery capacity is small, the DC-ID value is set to a small value.

In addition, in addition to the remaining energy, hardware specifications, network connection speed, network capabilities, outward mobility, system stability, computing power, resource consumption, etc. can be used to construct the capabilities of the device. The DC-ID value may not be a simple number, but various types of information.

200780006766.9 On the other hand, D-ID is set as a unique number or information data used to display the domain subscribed by the device. In addition, the DE-ID value of each device is initialized as a code for distinguishing the devices from each other. The D-ID value and DE-ID value can be assigned by an administrator, or the D-ID value and DE-ID value can be generated by a corresponding device.

As described above, when the setting of DC-ID and D-ID for each device is completed, the device sequentially broadcasts or multicasts the DPDUC operation including the set information to neighboring devices S2). Then, the A device may receive a DPDU transmitted from another device (operation S3). When a predetermined device receives a DPDU, the corresponding device extracts the DC-ID value V included in the header of the received DPDU (operation S4) and The extracted DC-ID value is compared with the DC-ID value X of the device (operation S5). On the other hand, when the DPDU is not received, it is determined whether the set time T1 has elapsed (operation S12). V represents the DC-ID value of the DPDU received from another device. In the device that transmits DPDU, the DC-ID value can be Xo as the comparison result of the DC-ID value. When the DC-ID value of the device is less than the received DC-ID value, the device destroys the received DC -ID value (operation S6). In this case, this is because the device that receives the DC-ID has higher energy (ie, capability) than the device that transmits the DC-ID.

On the other hand, as a result of the comparison of the DC-ID value, when its own DC-ID value is greater than the received DC-ID value, the device extracts the D-ID included in the header of the received DPDU D-ID information W (operation S7), and check whether the extracted D-ID information W is the same as its own D-ID information Y (operation S8) ο It is possible to be in the same domain by checking the received D-ID information Select the reference point controllers one by one. W represents the D-ID value of the DPDU received from another device. In the device that transmits DPDU, the DC-ID value can be Y.

200780006766.9 As the result of the D-ID check, when the received D-ID is the same as the D-ID of the device, the device stops broadcasting the DPDU (operation S9) ο This is because the device with the high capacity value is located in the same domain in. This can indicate that the device failed to select the reference point controller.

On the other hand, as a result of the D-ID check, when the received D-ID is different from the d-ID of the device, the device regards the received DPDU as a DPDU received from a device in another domain, And broadcast DPDUs successively. At this time, the device transmits DPDUs to another device and checks whether the set time T2 has elapsed (operation S10). At this time, when no more DPDUs are received within the set time T2 Or when a DPDU in which the DC-ID is less than the DC-ID value of the device and in which the D-ID is the same as the D-ID of the device is not received, the device has the highest capability in the domain. Therefore, the device is selected as the reference point controller as a representative in the domain (operation S11). The device selected as the reference point controller reports to the domain manager that the device is selected as the reference point controller. Register the device as a reference point controller. Here, the registration process will be described with reference to FIG. 13.

Software that can perform the functions of the reference point controller can be installed in the device selected as the reference point controller. The software is pre-installed in the device in a disabled state. When the device is selected as the reference point controller, the software is activated and built according to the command of the domain manager. Alternatively, the domain manager or another device may upload the software that can perform the function of the reference point controller to the selected device. It is assumed that the domain device participating in the process of selecting the reference point controller satisfies the basic conditions for performing the function of the reference point controller. At this time, the basic condition may mean that it includes disabled software or has hardware that satisfies the software specifications in which the function of the reference point controller can be executed.

As described above, according to Example 1-1 related to selecting a reference point controller, by exchanging DPDU data packets between devices, the device with the highest capability can be selected as the reference point controller. The above description is an example. Without departing from the spirit and scope of the present invention, changes can be made to the DC-ID setting capabilities, comparison capabilities, and the like.

200780006766.9 No. <Example 1-2>

Hereinafter, Example 1-2 will be described as another example of the method of selecting the reference point controller.

In the method of selecting a reference point controller of Example 1-2, a device (for example, a client device) that wishes to register to the domain reports the device information of the device to the domain manager, and the domain manager is based on the reported Device information to select the reference point controller. At this time, the device information may include information about the domain subscribed by the device, information about the capabilities of the device, identification information of the device, and the like. For example, the device information may be DPDUo. FIG. 8 is a flowchart showing a method of selecting a reference point controller according to Example 1-2.

Referring to FIG. 8, when the process starts, the device to subscribe to the domain sets the DC-ID value X, the D-ID value Y, and the DE-ID value Z to predetermined values (operation S20). At this time, the setting value of the DC-ID is allocated according to a predetermined standard, or the setting value of the DC-ID is generated by a corresponding device.

For example, when the standard of the DC-ID value is the specification of the central processing unit (CPU) embedded in the device, the administrator assigns the DC-ID value of each device. Alternatively, the DC-ID value of each device is set to the generated capability value. For example, the DC-ID value of device A is 4, the DC-ID value of device B is 2, the DC-ID value of device C is 3, and the DC-ID value of device D is 8c. At this time, when the specifications of the CPU are lower When it is high, the DC-ID value is assumed to be a smaller value. Specifically, when the DC-ID value becomes smaller, the device has high capacity. However, the present invention is not limited to this. Alternatively, it may be assumed that the DC-ID value is set to a smaller value when the battery capacity is smaller. In addition, according to the execution environment, information about hardware other than the CPU, energy information, and the like can be applied to the capabilities of the device in various types.

200780006766.9 Set D-ID as a unique number or information data used to display the domain subscribed by the device. In addition, the DE-ID value of each device is initialized as a code for distinguishing the devices from each other. The D-ID value and the DE-ID value can be assigned by an administrator, or the D-ID value and the DE-ID value can be generated by a corresponding device.

As described above, when setting the DC-ID and D-ID for each device is completed, the device transmits the DPDU including the setting information to the domain manager (operation S21). The DPDU can be transmitted within a predetermined time. The domain manager maintains a standby state within the predetermined time. When a predetermined time has elapsed, the domain manager no longer receives the DPDU. The domain manager compares the DC-ID values included in the domain header of the DPDU received from the device with each other (operation S22), and extracts the value with the smallest value. The device with the DC-ID value, that is, the device with the highest capability (operation S23)=When the device with the highest capability is extracted, the domain manager checks the D-ID of the device (operation S24), and checks the D- Whether the ID is the same as the ID of the newly formed domain. When the D-ID is the same as the ID of the domain to be newly formed, the device is selected as the reference point controller (operation S25). As described in Example 1-1, the function of the reference point controller may be installed in the device selected as the reference point controller.

As a result of the D-ID check, when the D-ID of the device is not the ID of the domain to be newly formed, the DC-ID values of the devices other than the corresponding device are compared with each other, and the one with the highest capability is searched for equipment. The device with the highest capability can be selected as the reference point controller.

On the other hand, in the above-mentioned Example 1-2, the reference point controller is selected based on the capability of each device. Alternatively, in addition to the capabilities, the reference point controller may be selected based on the degree of matching with reference information, user's settings, and the like.

For example, when a device that wishes to register to the domain transmits device information including information about the hardware specifications of the device to the domain manager, the domain manager may use the transmitted device

200780006766.9 The second information is compared with the predetermined specification information to select the most appropriate equipment. In addition, the domain manager may select a device matching the device information as the reference point controller, the device information previously determined by the user from the device information transmitted from each device.

<Example 1-3>

In the method of selecting a reference point controller according to Examples 1-3, the reference point controller is selected based on setting information previously set by an administrator or a user or arbitrarily set. For example, when an administrator or a user inputs setting information into a domain manager, the domain manager may select a reference point controller based on the setting information. Alternatively, the administrator or the user can directly select the device to be used as the reference point controller by the user, and establish the reference point controller. Therefore, in Example 1-3, the device desired by the administrator or the user, or any device, is selected as the reference point controller.

The method of selecting the reference point controller when initially constructing the domain has been described through Examples 1-1 to!] 1-3, and the reference point controller is used to determine the range of the local area. When the reference point controller is selected, the range of the local area in the local state of the domain subscribed by the client can be determined by the reference point controller.

On the other hand, the domain manager or license manager may exist anywhere in the local area or the external network area. When a domain manager or a license manager exists in an external network, it must support a secure communication device that reliably interacts with the domain.

On the contrary, since the reference point controller is an entity that determines the scope and environment of the local area in the local area, the reference point controller is different from the domain manager or the license manager, and it must exist in the local area. At this time, the reference point controller periodically and continuously communicates information signals with the domain manager in order to confirm the normal operation of the reference point controller.

When the domain manager does not receive any information from the reference point controller within a predetermined time

When 200780006766.9 is the first signal, this indicates that the reference point controller is not operating normally. Specifically, the reference point controller fails. Alternatively, the reference point controller malfunctions because the reference point controller enters an external non-communication area.

In this situation, the client device in the local area of the subscribed domain may not be able to use the content normally. In fact, because the reference point controller may be installed in a mobile phone, a personal digital assistant (PDA), etc., the reference point controller may enter an external non-communication area. In this case, the reference point controller may malfunction.

Therefore, in the present invention, a method for preventing the failure of the reference point controller is disclosed. First, the concept of reference point controller candidates is introduced. The reference point controller candidate indicates a device that replaces the reference point controller when the reference point controller fails. The reference point controller candidate may be selected when the domain is initially constructed, or the reference point controller candidate may be selected according to the domain manager after the domain is constructed.

-Selection and operation of reference point controller candidates There are four methods for selecting reference point controller candidates.

The first method is to communicate device information among devices other than the current reference point controller among the devices in the domain. The device information is compared with each other based on a predetermined algorithm (for example, the algorithm described in Example 1-1), and a reference point controller candidate is selected. For example, the ability to communicate between devices. The device with the highest capability is selected as the reference point controller candidate. The selected reference point controller candidate reports to the domain manager that the device is selected as the reference point controller candidate.

The second method is that the device in the domain provides device information (for example, DPDU including capabilities) about the device to the domain manager, and is similar to selecting the reference point controller according to the above example 1-2, the domain manager is based on all The device information selects reference point controller candidates.

The third method is that the devices in the domain provide the device information of the device to the reference point controller.

200780006766.9 The first reference point controller selects a reference point controller candidate based on the device information. In this case, when the reference point controller is selected, the reference point controller must report information about the selected reference point controller candidate to the domain manager.

The fourth method is to select reference point controller candidates based on predetermined information. At this time, the predetermined information can be set by the administrator or the user. Alternatively, the predetermined information may include arbitrarily set information.

Hereinafter, the above-mentioned four methods will be described in detail. For ease of understanding, the above-mentioned first method of selecting reference point controller candidates is referred to as Example 2-1. The second method of selecting reference point controller candidates is referred to as Example 2-2. The third method of selecting reference point controller candidates is referred to as Example 2-3. The fourth method of selecting reference point controller candidates is referred to as Example 2-4. <Example 2-1>

FIG. 9 is a flowchart showing a process of selecting a reference point controller candidate according to Example 2-1. Figure 9 shows the process of automatically selecting a reference point controller by using the capabilities of the device.

When constructing a domain, the process of selecting a reference point controller candidate according to Example 2-1 may start after the process of selecting a reference point controller is completed. Alternatively, the process of selecting reference point controller candidates according to Example 2-1 may be started according to a start command of an entity such as a domain manager at any time after the domain is constructed.

As shown in FIG. 9, when the process starts, devices other than the reference point controller in the devices in the domain set device information (operation S30). The device information may include information about capabilities, information about domains , Equipment identification information, etc. Here, the information about capabilities may include information about the remaining energy of the device, hardware specifications, network connection speed, outward mobility, system stability, and so on. this

200780006766.9 In addition, the information about capabilities can be numbers such as the value of DC-ID. Alternatively, the information about capabilities may be various types of information.

When setting device information (capability information, domain information, device identification information) for each device is completed, the device forms the set information into a standardized group, for example, the device inserts the set information into the DPDU and Sequentially broadcast or multicast DPDUs to another device (operation S31). Then, each device receives a normalized packet transmitted from another device (operation S32), and combines the capability information included in the received packet with the devices The capabilities are compared (operation S33), and a device (the device that transmits the packet or the device that receives the packet) is eliminated (operation S34) ο For example, the device receiving the packet compares the capability information of the received packet with the capability information of the device Compare. When the capability information of the received packet is greater than the capability of the device, the device stops broadcasting the DPDU. That is, the device receiving the packet is eliminated in the selection of the reference point controller candidate. At this time, the following process may also be performed: according to the information about the received packet, it is checked whether the device transmitting the packet and the device receiving the packet are in the same domain. On the other hand, when the capability information of the received packet is less than the capability of the device receiving the packet, the packet is destroyed. That is, the device that transmits the packet is eliminated in the selection of the reference point controller candidates.

Finally, through the above-mentioned process, only the device with the highest capability is retained (operation S35). Then, the surviving device is selected as the reference point controller candidate (operation S36). The selected device reports to the domain manager that the device is selected as the reference point controller candidate.

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

200780006766.9 On the other hand, multiple reference point controller candidates can be registered to the domain manager in order of priority. Specifically, the process of selecting the first reference point controller candidate is performed, and the first reference point controller candidate is registered. The process of selecting the second reference point controller candidate is performed, and the second reference point controller candidate is registered. The above-mentioned process is repeatedly performed, and a desired number of reference point controller candidates can be registered.

When the plurality of reference point controller candidates are registered, the reference point controller may be replaced in order of priority. At this time, the registered multiple reference point controller candidates must periodically confirm that the reference point controller candidates are operating normally. The verification process will be described in detail later.

<Example 2-2>

In the method for selecting reference point controller candidates according to Example 2-2, devices in the domain report device information of the devices to a domain manager, and the domain manager selects reference point controller candidates based on the reported device information .

This method is similar to the concept of selecting a reference point controller according to Example 1-2. In Example 1-2, the device subscribed to the domain reports the device information of the device to the domain manager, and the domain manager selects the most appropriate device based on the reported device information and registers the selected device It is the reference point controller.

In Example 2-2, devices in the domain other than the reference point controller provide the device information of the device to the domain manager, and the domain manager selects the most appropriate device based on the reported device information and sets the selected The device is registered as a reference point controller candidate.

At this time, the device information may include capability information representing the capability of the device according to a predetermined standard. The domain manager may register the device by assigning priority to the device based on the capability information provided by the device in descending order of capability.

For example, the domain manager may be able to first replace the device based on the capability information of each device.

200780006766.9 The order of the first reference point controller candidate, the second reference point controller candidate and the third reference point controller candidate of the first generation reference point controller, select and register a plurality of reference point controller candidates. When the plurality of reference point controller candidates are registered, the reference point controller candidates replace the reference point controller in the assigned priority order.

On the other hand, the process of selecting a reference point controller candidate may be performed after the reference point controller is selected. According to the execution environment, the reference point controller candidates may be selected when the process of selecting the reference point controller disclosed in Example 1-2 is performed. That is, when the reference point controller is selected, the first reference point controller candidate, the second reference point controller candidate, and the like are selected. For example, when a domain is constructed, a device that subscribes to the domain reports information about capabilities to the domain manager, and the domain manager may select the reference point controller, the first reference point controller candidate, and the second reference point controller based on the reported capabilities. Reference point controller candidates, etc.

<Example 2-3>

In the method of selecting reference point controller candidates according to Example 2-3, the devices in the domain report the device information of the devices to the domain manager, and the reference point controller selects the reference point controller candidates based on the reported device information.

The method of selecting reference point controller candidates according to Example 2-3 is basically the same as the method of selecting reference point controller candidates according to Example 2-2 except that the reference point controller selects reference point controller candidates.

The device information reported to the reference point controller may include capability information representing the capabilities of the device. The reference point controller may register the device by assigning a priority to the device based on the capability information reported by the device in descending order of capability. For example, the reference point controller may be based on the capability information of each device in the order of the first reference point controller candidate, the second reference point controller candidate, and the third reference point controller candidate that can first replace the reference point controller , Select and register multiple reference point controller candidates. When the plurality of reference point controller candidates are registered, the reference point controller candidates may replace the reference point controllers in order of priority.

200780006766.9 On the other hand, when the reference point controller is selected, the reference point controller registers the selected reference point controller candidate to the domain manager. In addition, even when the plurality of reference point controllers are selected in the order of priority, the reference point controller reports the selection history to the domain manager. Therefore, even when the reference point controller fails for a long time or enters a non-communication area, the reference point controller candidate can replace the reference point controller. Therefore, the service is provided normally.

<Example 2-4>

In the method of selecting a reference point controller according to Examples 2-4, a reference point controller candidate is selected based on setting information previously set by an administrator or a user or arbitrarily set. For example, when an administrator or a user inputs setting information into a domain manager or reference point controller, the domain manager or reference point controller may select a reference point controller based on the setting information.

The setting information may include information about the plurality of reference point controller candidates to which priorities are assigned. Specifically, the domain manager or the reference point controller may select the plurality of reference point controller candidates in the order of priority included in the setting information. For example, the device A is selected and registered as the first reference point controller candidate, and the device B is selected and registered as the second reference point controller candidate. Then, when an error occurs in the reference point controller, the first reference point controller candidate may replace the reference point controller. When an error occurs in the first reference point controller candidate, the second reference point controller candidate may replace the first reference point controller candidate.

In the case where the domain manager selects the reference point controller candidates, when constructing the domain, the domain manager simultaneously selects the reference point controllers and designates the reference point controller candidates in a predetermined order of priority. Then, when the reference point controller fails, the error can be handled flexibly and quickly. On the other hand, in a case where the reference point controller selects a reference point controller candidate, after the reference point controller is selected, the reference point controller may specify a candidate for replacing the reference point controller based on the setting information.

200780006766.9 On the other hand, the administrator or user can directly select the device that will be used as a reference point controller candidate without using the domain manager or reference point controller. In this case, the selected reference point controller candidate must report to the domain manager that the device is selected as the reference point controller candidate.

The method of selecting reference point controller candidates has been described through Examples 2-1 to 2-4. In the case of selecting the reference point controller, even when an error occurs in the reference point controller, the reference point controller candidate can replace the reference point controller. In addition, by setting a plurality of reference point controller candidates in a predetermined priority order, the stability and flexibility of the service in the domain can be ensured.

The reference point controller candidates may have the following functions.

1. The function of the reference point controller: for example, measure the proximity of a predetermined device and issue a domain certificate. The function of the reference point controller has been described previously.

2. The function of transmitting and receiving information signals: the reference point controller candidate must communicate with the reference point controller through a predetermined interface and the information signal used to report the normal operation of the reference point controller candidate.

3. Set the function of not receiving conditions: Set the function of distinguishing the conditions of not receiving information signals. For example, you can set timeouts, count limits, range limits, and so on.

4. Reporting function to the domain manager: the function of supporting the data structure and interface used to communicate with the domain manager.

5. Download function: supports the function of the interface used to download entities (software) from the domain manager or a predetermined service terminal.

200780006766.9 On the other hand, the reference point controller must periodically confirm to the domain manager or other devices that the reference point controller is operating normally. In addition, the reference point controller candidate must periodically confirm to the domain manager or other devices that the reference point controller candidate is operating normally. This is because when an error occurs in the reference point controller candidate, the reference point controller candidate may not replace the reference point controller.

Fig. 10 is a block diagram showing a reference point controller for transmitting an information signal and connections between reference point controller candidates.

As shown in FIG. 10, designated routes a, b, and c for transmitting information signals are formed between the reference point controller 70 and the reference point controller candidates 71 and 72 in the domain 6.₀Routes a, b, and c for transmitting information signals indicate routes for transmitting information signals for confirming whether the equipment is operating normally.

For example, in the routes a, b, and c for transmitting the information signal, the reference point controller 70 transmits the information signal to the first reference point controller 71, and the reference point controller candidate 71 transmits to the second reference point controller 72 Information signal. In addition, the second reference point controller candidate 72 transmits an information signal to the reference point controller 70. At this time, the first reference point controller candidate 71 represents a primary reference point controller candidate, and the second reference point controller candidate 72 represents an auxiliary reference point controller candidate.

A secure communication device or channel must be provided in the routes a, b, and c used to transmit information signals. In order to form a secure communication device or channel, various encryption methods can be used. For example, a public key method, a method of sharing a key in advance, a method of providing key information to the device by the domain manager, and the like can be used. Alternatively, when generating a secure authentication channel between the content exporter, the content converter, and the content importer, the content transmission controller may provide key information.

The transmission signal is periodically transmitted through the routes a, b, and c for transmitting the information signal. The transmission signal is used to verify that the reference point controller or the reference point controller candidate is

200780006766.9 No. regular operation. The transmission signal may include domain information, device identification information, system information, timeout information, and so on.

Here, the timeout information relates to a time limit for determining whether the information signal is normally received.

For example, when the information signal is not received from the reference point controller 70 within the time limit , the first reference point controller candidate 71 determines that an error has occurred in the first reference point controller 70. The first reference point controller candidate 71 reports to the domain manager that an error has occurred in the reference point controller 70 and the first reference point controller candidate 71 replaces the reference point controller 70. Then, the first reference point controller candidate 71 performs the function of the reference point controller 70.

At this time, the first reference point controller candidate 71 may receive information and tools required to perform the function of the reference point controller from the domain manager 60 or another terminal. For example, the first reference point controller candidate 71 may download and install software for performing the function of the reference point controller or may enable disabled software installed therein.

Regarding another example, when the reference point controller 70 does not receive the information signal from the second reference point controller candidate 72 within the time limit, the reference point controller 70 determines that it occurs in the second reference point controller candidate 72. Error and report to the domain manager 60 that an error occurred in the second reference point controller candidate 72. Then, a reference point controller candidate (for example, a third reference point controller candidate (not shown)) having a lower priority than the second reference point controller candidate may replace the second reference point controller candidate 72. The priority can be newly reconstructed through the above-mentioned process (Examples 2-1 to 2-4) of selecting reference point controller candidates.

On the other hand, in the example shown in FIG. 10, it is determined whether an error has occurred in the device by information signal transmission between the reference point controller 70 and the reference point controller candidates 71 and 72. The present invention is not limited to this. As shown in FIG. 11, the reference point controller 70 and the reference point controller candidates 71 and 72 can directly transmit information signals to the domain manager 60 through routes e, f, and c. Regarding another example, the reference point controller 70 may directly transmit to the domain manager 60

200780006766.9 Sends information signals, and the reference point controller candidates and 72 can transmit information signals to each other through a predetermined route. That is, depending on the execution environment, the route for transmitting the information signal can be changed differently.

As described above, the reference point controller 70 and the reference point controller candidates 71 and 72 periodically confirm their normal operation by using the information signal. Instead of the reference point controller 70, the priority of the reference point controller candidates 71 and 72 may be reconstructed according to whether an information signal is received.

On the other hand, due to policy reasons, etc., the range of the local area determined by a single reference point controller is physically or logically restricted. However, the user may wish to use the content service in a wider range than the currently set local area. Therefore, there is a need for a method in which the service area can be expanded while maintaining the range limit of the local area.

In the present invention, the concept of reference point controller agent is introduced. The reference point controller agent means a device that performs the function of the reference point controller instead of the reference point controller. The reference point controller agent is required when the domain is extended or when the reference point controller is temporarily moved to the outside.

-Selection and operation of the reference point controller agent FIG. 12 is a block diagram showing the concept of the reference point controller agent. FIG. 12 shows an example in which domain A'is added to domain A.

As shown in FIG. 12, the range and environment of the local area in which the device can reserve the domain 86 is determined by the reference point controller 82. When the extended service area or the reference point controller 82 temporarily moves to the outside of the local area, an extended domain with the same authority as the domain A (for example, domain A'96) must be generated. It can be determined by the reference point controller agent 92 The device can subscribe to the range and environment of the local area of the domain A'96 in it. The reference point controller agent 92 executes in the domain A'96

200780006766.9 The function of the first reference point controller. That is, the reference point controller agent 92 is the reference point in the domain A, 96. In addition to domain A 86, users can receive content services from domains A, 96 through client devices 84 and 94.

The reference point controller agent 92 is easily selected by the process described in the above example of selecting the reference point controller and the reference point controller candidates. That is, the method of selecting the reference point controller agent 92 will be described below.

In the first method, devices in subscribed domains A and 96 communicate device information with each other. According to a predetermined algorithm (for example, the algorithm described in Example 1-1), the device information is compared with each other. The reference point controller agent 92 is selected based on the device information. For example, the ability to communicate between devices. The device with the highest capability is selected as the reference point controller agent 92. The selected reference point controller agent 92 reports to the domain manager 80 that the device is selected as the reference point controller agent 92.

In the second method, similar to the concept of selecting the reference point controller according to Example 1-2, the device subscribing to domain A provides the device information (for example, DPDU including capability information) of the device to the domain manager, And the domain manager 80 selects the reference point controller agent 92 based on the device information.

In the third method, the reference point controller agent 92 is selected based on the setting information previously set by the administrator or the user or arbitrarily set.

On the other hand, when the reference point controller agent 92 is selected, a candidate for preventing a situation in which an error occurs in the reference point controller agent 92 can be selected. That is, a candidate to replace the reference point controller agent 92 when an error occurs in the reference point controller agent 92 is selected. The candidate of the reference point controller agent can be easily selected by using the above-mentioned process of selecting the reference point controller candidates.

The method of selecting the candidates of the reference point controller agent 92 will be described below.

200780006766.9 In the first method, the devices in the subscribed domains A and 96 communicate device information with each other. According to a predetermined algorithm (for example, the algorithm described in Example 1-1), the device information is compared with each other. The reference point controller agent 92 and the candidates of the reference point controller agent 92 are selected based on the device information. For example, the ability to communicate between devices. The device with the highest capability is selected as the reference point controller agent 92. Subsequently, candidates for the reference point controller agent are selected by communicating capabilities between devices other than the reference point controller agent 92. There is a priority among the candidates of the reference point controller agent. In addition, the selected reference point controller agent 92 and the selected reference point controller agent 92 candidates must report to the domain manager 80 that the device is selected as a candidate for the reference point controller agent 92 and the reference point controller agent 92 .

In the second method, similar to the concept of selecting a reference point controller according to Example 1-2, a device subscribing to domain A provides the domain manager with device information (for example, a DPDU including capability information) of the device, and The domain manager 80 selects the reference point controller agent 92 and candidates for the reference point controller agent 92 based on the device information. At this time, there may be a priority among the candidates of the reference point controller agent 92.

In the third method, the reference point controller agent 92 and the candidates of the reference point controller agent 92 are selected according to the priority. At this time, the administrator or the user can set the predetermined information. Alternatively, the predetermined information may include arbitrarily set information.

On the other hand, the reference point controller agent 92 must report to the reference point controller 82 that the reference point controller agent 92 continuously and stably provides services. The reference point controller agent 92 periodically communicates predetermined information signals with the reference point controller 82. When the information signal is not communicated within a predetermined period of time, the reference point controller agent 92 is not in a normal state. Therefore, the domain A* 96 cannot be maintained₀ The domain reference information may include domain reference information, device identification information, timeout information, unique system information, and so on.

200780006766.9 It is necessary to transmit the information signal through a wired or wireless transmission route in which a secure communication device or channel is provided. In order to form a secure communication device or channel, various encryption methods can be used. For example, a public key method, a method of sharing a key in advance, a method of providing information about the key to the device by the domain manager, and the like may be used. In addition, in addition to between the reference point controller and the reference point controller agent, the information signal may be continuously communicated between the reference point controller and the domain manager and between the reference point controller agent and the domain manager. .

On the other hand, when it is not necessary to maintain the domain 496, the domain A'96 must be destroyed. In this case, the domain A'96 can be destroyed by using the information signal.₀For example, the reference point controller 82 or the domain manager 80 stops transmitting an information signal or transmitting a destruction signal to the reference point controller agent 92. Then, since the reference point controller agent 92 does not operate normally, the reference point controller agent 92 is destroyed. Therefore, domain A is automatically destroyed.

-Registering a reference point controller Hereinafter, the process of registering a new reference point controller will be described. The process of registering the reference point controller may be performed when a new domain is generated or when the reference point controller is replaced.

FIG. 13 is a flowchart showing a process of registering a reference point controller.

Referring to FIG. 13, the domain manager receives a request to authenticate the reference point controller from a device to be registered as a new reference point controller. At this time, the device to be registered as a new reference point controller may be selected from the above process of selecting a reference point controller, a reference point controller candidate for replacing an existing reference point controller, and a reference point controller agent. One of the devices.

When the domain manager receives a request to authenticate the reference point controller, the domain manager invalidates the existing reference point controller membership. At this time, when the reference point controller is registered, the domain manager generates the reference point controller membership. The reference point controller membership may represent information used to verify that the corresponding entity is a reference point controller.

200780006766.9 The domain manager described above generates and stores a unique new reference point controller membership, and transmits the generated reference point controller membership to a device requesting the domain manager to provide the new reference point controller membership. At this time, the domain manager stores and manages the reference point controller membership and the domain as a pair.

The device receiving the reference point controller membership stores the reference point controller membership. Register the device as a reference point controller. When the newly registered reference point controller provides various types of information to the domain manager or requests the domain manager to provide various types of information, or when authenticating the client, the stored reference point controller membership can be used as Authentication component information. In addition, when the reference point controller is maintained, the reference point controller membership is periodically stored.

-Method of authenticating the client In the following, the method of authenticating the client will be described. Returning to FIG. 5, when the client 3 subscribes to the domain 5, the domain manager 22 generates a client membership that is unique to the client 3. The client membership given to the client 3, which is a member of the domain 5, is continuously stored. When the client 3 exits the domain 5, the domain manager 22 maintains the client membership of the client during a predetermined period of time and cancels the client membership. At this time, even when the client terminal 3 exits the domain 5, the content used before the timeout continues to be used during the predetermined period of time. The predetermined time period can be selectively applied through the provider's strategy.

The client must confirm to the predetermined entity that the client normally subscribes to the domain 5 so that the client 3 subscribed to the domain 5 can use the service. To this end, the client 3 requests the domain manager 22 to authenticate the client 3. When the client 3 requests the domain manager 22 to authenticate the client 3, the client 3 must submit a confirmation certificate or an automatic certificate to the domain manager 22.

The clear credential is encrypted information including the client membership given to the client 3 and the clear credential. At this time, when domain 5 is generated, the assured domain certificate is generated by the domain manager 22. After domain 5 is generated, the domain manager 22

200780006766.9 Domain certificates generated by various transaction applications of the first domain.

The automatic certificate is encrypted information including the membership of the reference point controller and the membership of the client. The automatic certificate may represent a domain certificate provided by the reference point controller 26. When the reference point controller 26 is registered to the domain 5, the reference point controller membership is generated by the domain manager 22. The reference point controller membership is continuously stored when the reference point controller 26 is maintained. The automatic certificate is information about whether the client 3 normally exists in the local area, and the information is guaranteed by the reference point controller 26. Therefore, the client 3 in the local state can use the automatic certificate.

When the client 3 requests the domain manager 22 to authenticate the client 3, the domain manager 22 determines whether the submitted certificate is valid. When it is determined that the client 3 does not subscribe to the domain 5, the domain manager 22 generates an error. Alternatively, when the client 3 normally subscribes to the domain 5, the domain manager 22 authenticates the client 3. The client 3 can use the content within the authorized scope.

The domain manager 22 recognizes whether the client 3 is in a remote state or a local state based on whether the certificate submitted by the client 3 is a sure certificate or an automatic certificate, and manages the client 3. As described above, the remote state may indicate a situation in which the client 3 accesses the domain 5 in a network area outside the local area. For example, the client 3 accesses the domain 5 through the Internet. On the other hand, the local state may indicate a situation in which the client 3 exists in the local area. The reference point controller 26 can check the client 3 in the local state by measuring the number of hops. Through a predetermined process, the client 3 can register as a member of the domain 5.

-Registration, certification and management of legacy devices. Legacy devices other than client devices can also access the domain. At this time, the legacy device may indicate that the device that is an entity operating as a client in the domain is not completely installed thereon. Specifically, devices that only have certain functions of the client or devices that do not include the client are referred to as legacy devices.

In order to allow the provision of services in the domain to legacy equipment, the client part includes

200780006766.9 The adapter of the legacy device access system, that is, the interface entity. The interface entity must provide various functions to enable the legacy device to perform functions equivalent to that of the client device.

The above-mentioned interface entity is called a virtual client. The virtual client is an entity required to connect the legacy device with the system. The virtual client unites with the legacy device to allow the legacy device to provide services similar to the client device. Specifically, the domain manager regards the access to the domain by the virtual client and the legacy device as an access to the domain by a client. One or more legacy devices can be connected to the virtual client.

The virtual client or domain manager can manage the unique information of the legacy device. In addition, the virtual client or domain manager also manages information about users who use the legacy device.

FIG. 14 shows an example of the structure of unique information for managing heritage equipment.

As shown in FIG. 14, when the legacy device 210 requests the virtual client 220 to be accessed by the legacy device 210, the unique information about the legacy device DV-info is provided to the virtual client. At this time, the unique information DV-info about the legacy device may represent unique information such as a media access control address, a disk volume ID, etc., that is unique to the legacy device 210.

When the legacy device 210 requests to access the virtual client, the unique information about the legacy device DV-info may be transmitted to the virtual client 220 together with the request for the access request message. Alternatively, when the legacy device 210 requests access to the virtual client 220, the virtual client 220 can extract the unique information DV-info about the legacy device from the legacy device 210. The virtual client 220 can store and manage information provided by the legacy device 210 The unique information DV-info of the legacy equipment. At this time, as shown in FIG. 14, the unique information DV-info about the legacy equipment can be stored and managed in the form of an information table 222 corresponding to the device identifier LD-info. Here, the equipment identifier The symbol LD-info is globally unique identification information used to identify the legacy equipment 210. The device identifier LD-info44 can be assigned by the domain manager 240

200780006766.9 The domain manager 240 stores and manages the device identifier LD-info for each domain and the unique information DV-info about the legacy device corresponding to the device identifier LD-info. For example, as shown in FIG. 14, the domain manager 240 The domain identifier D-ID, the device identifier LD-info, and the unique information about the legacy equipment corresponding to the domain identifier D-ID and the device identifier LD-info can be stored and managed in the form of the information table 242 DV-info. At this time, the domain identifier D-ID is information used to identify the domain visited by the heritage device 210. The domain identifier D-ID may also be information for identifying the domain 200 in which the virtual client 220 is included.

When the domain manager 240 manages the device identifier LD-info and the unique information DV-info about the legacy device corresponding to the device identifier LD-info, the domain manager 240 can prevent the legacy device 210 from dually requesting another domain for authentication The heritage device 210ο will become clear by the method of authenticating the heritage device described below.

FIG. 15 is a flowchart showing the process of authenticating heritage equipment.

14 and 15, when a predetermined legacy device 210 requests to access the virtual client 220 (operation S41), the virtual client 220 receives unique information DV-info about the legacy device from the legacy device 210 (operation S42). Subsequently, the virtual client 220 searches the information table 222 stored therein (operation S43) and determines whether there is the same legacy device unique information as the unique information DV-info of the legacy device requesting access to the virtual client 220 (operation S44). That is, it is determined whether the legacy device 210 has been previously registered.

At this time, when there is the same legacy device unique information as the unique information DV-info of the legacy device requesting access to the virtual client 220, since the legacy device 210 has registered the virtual client 220, the virtual client requests the domain manager 240 authentication device identifier LD-info (operation S46). When the domain manager 240 is requested to authenticate the device identifier LD-info, the device identifier LD-info and the unique information DV-info of the legacy device may be provided to the domain manager 240.

200780006766.9 On the other hand, when it is determined that there is no unique information of the legacy device that is the same as the unique information DV-info of the legacy device requesting access to the virtual client 220, the virtual client 220 receives the new device identifier LD from the domain manager 240 -info, and store the new device identifier LD-info in the information table 222 (operation S45). Therefore, the unique information DV-info of the legacy device and the newly allocated device identifier LD-info are equally stored in the information table 222. That is, the legacy device 210 is registered as a new device.

In order to register the legacy device, the virtual client 220 or the domain manager 240 checks the unique information of the legacy device 210 and checks whether the legacy device 210 is a device that can be registered. At this time, the devices that can be registered can refer to devices that are allowed devices in terms of policy and technology. For example, a service provider, another authorizer, a domain manager, etc. manage a list of types of legacy devices that can access the domain. When registering a new legacy device, the virtual client or domain manager checks the type list of legacy devices and only assigns device identifiers to allowed devices. This will be described in detail with reference to FIG. 17.

When storing the device identifier LD-info, the virtual client 220 requests the domain manager 240 to authenticate the device identifier LD-info (operation S46).

Then, in response to the authentication request, the domain manager 240 considers the unique information DV-info of the legacy device corresponding to the device identifier LD-info to authenticate the device identifier LD-info. Specifically, the domain manager 240 searches for 240 manages the information table (operation S47) and determines whether the legacy device 210 visits another domain (operation S48). For example, the domain manager 240 determines whether the unique information of the legacy device that is the same as the unique information of the legacy device is currently authenticated.

When it is determined that the legacy device 210 does not access another domain, it reports to the virtual client 220 that the device identifier LD-info is allowed to access the domain (operation S50). That is, the legacy device 210 is allowed to access the domain. Therefore, the legacy device 210 can access the domain 200 and use the content.

On the other hand, when it is determined that the heritage device 210 visits another domain, it is determined that the heritage

200780006766.9 The first device intends to double access the domain. The determination result is reported to the virtual client 220 (operation S49). That is, the legacy device 210 is not allowed to access the domain. Therefore, the legacy device 210 cannot access the domain 200. As described above, the virtual client 220 and the domain manager 240 store and manage the unique information of the legacy device 210. For example, the virtual client 220 and the domain manager 240 store and manage device certificates of legacy devices.

Therefore, it is possible to prevent the heritage device 210 from dually accessing the domain 200. Therefore, it is possible to prevent the legacy device 210 from illegally sharing content.

On the other hand, in addition to unique information about legacy equipment, virtual clients and domain managers can also manage information about users who use legacy equipment. In this case, the number of legacy equipment that the user can use can be limited.

FIG. 16 shows an example of the structure of a DRM interoperating system for managing information about users who use legacy equipment.

As shown in FIG. 16, when the legacy device 251 accesses the virtual client 260 to request domain authentication of the legacy device 251, the unique information about the legacy device DV-info and the user information U-info of the legacy device 251 are provided to the virtual client 260 . At this time, the user information U-info of the legacy device 251 may represent unique information used to identify the user who uses the legacy device 251, such as subscriber identification module information, user certificate information, or information explicitly input by the user (such as ID, password, etc.) ). This can correspond to the user's system login information. As described above, the unique information about the legacy device DV-info may represent unique information such as the media access control address, the disk volume ID, etc., which is unique to the legacy device 210. That is, the unique information about the legacy equipment means information including physical information or logical information.

When the legacy device 251 requests to access the virtual client 260, the user information U-info and the unique information about the legacy device DV-info can be transmitted to the

200780006766.9 The first virtual client 260. Alternatively, when the legacy device 251 requests to access the virtual client 260, the virtual client 260 can extract the user information U-info and the unique information about the legacy device DV-info from the legacy device 251. The virtual client 260 stores and manages the legacy device. The unique information DV-info of the device and the user information U-info. At this time, as shown in FIG. 16, the legacy information can be stored and managed in the form of an information table 262 corresponding to the device identifier LD-info provided by the domain manager 270 The unique information of the device DV-info and user information U-info.

The domain manager 270 stores and manages the device identifier LD-info, the unique information DV-info about the legacy device, and user information for each domain. Specifically, as shown in FIG. 16, the domain manager 270 may store and manage the domain identifier D-ID, the device identifier LD-info, the unique information about the legacy device DV-info, and the user information U in the form of an information table 272. -info ο When a request for authenticating a predetermined legacy device 251 is transmitted from the virtual client 260, the domain manager 270 can search for the legacy device 251 user information U-info in the information table 272 of the domain manager 270 to retrieve the legacy device The user information U-info of 251 should be used for authentication to allow access. In addition, the management of the legacy device 251 by the domain manager 260 can be applied to general client devices.

For example, the number of legacy equipment 251 is extracted by searching for user information U-info in the information table 272. The number of legacy equipment 251 is compared with a predetermined number limit. When the number of legacy equipment 251 is less than the predetermined number limit, authentication is performed. When the number of legacy equipment 251 is equal to or greater than the predetermined time limit, authentication is not allowed. Therefore, the total number of legacy equipment of the user can be limited. At this time, the number limit will depend on the policy of the service provider or the fee paid by the user.

As described above, when authenticating the legacy device 251, it is also possible to perform a process of determining whether to double access the domain by searching for unique information about the legacy device DV-info. That is, in the

In the authentication process of 200780006766.9, it is checked whether the domain is double-accessed, and the limit on the allowed number for the user is taken into consideration by using the unique information about the legacy equipment and the user information U-info. On the other hand, it is possible to periodically check whether the domain is dually visited, and it is possible to periodically limit the number of legacy devices for each user according to a predetermined time period.

Figure 17 is a flowchart showing the process of registering legacy equipment to the domain.

Referring to FIG. 17, when a new legacy device requests access to the virtual client to reserve a domain (operation S51), unique information about the legacy device is provided to the virtual client. Then, the virtual client recognizes that the virtual client is a new legacy device through the unique information about the legacy device, and searches the list of legacy devices that can be registered (operation S52). The list of legacy devices that can be registered is included in policy and technology The device object to which the service is provided. The list can be stored in advance by the virtual client. Alternatively, the list may be provided by a domain manager, a server of a service provider, or another system.

The virtual client searches the list based on the unique information about the legacy device, and determines whether the legacy device can be registered (operation S53) ₀For example, it is determined whether there is unique information about legacy equipment in the list. At this time, when there is unique information about the legacy device in the list, the virtual client requests the domain manager to register the legacy device. Then, the domain manager generates a unique device identifier, and transmits the unique device identifier to the virtual client (operation S54). Alternatively, when there is no unique information about the legacy device in the list, the virtual client does not allow the registration of the legacy device and reports to the legacy device information about whether the legacy device can be registered (operation S55).

So far, the operations that can be performed by the authentication and management part are described with reference to FIGS. 5 to 17, for example, the functions of the client part, the process of selecting the reference point controller, the process of selecting reference point controller candidates, and when controlling at the reference point When an error occurs in the device, the process of replacing the reference point controller with the reference point controller candidate, the process of extending the domain through the reference point controller proxy, the process of selecting and using the reference point controller candidate proxy, and the registration of reference point control

200780006766.9 The process of the first device, the process of authenticating the client and the process of registering, authenticating and managing heritage equipment, etc.

3. Functions and operations of the processing control part and the content processing part When the authentication and management part constructs a domain, the authenticated client or legacy device (connected to the virtual client) in the domain can use the DRM interoperability service. At this time, the legacy device and the virtual client connected to it can be regarded as one client. Therefore, in addition to the client defined in the description of FIG. 2, the following client may also include a client constructed by connecting a legacy device to a virtual client.

The authenticated client can request a predetermined target device to transmit one or more contents. At this time, the target device refers to a device or system in which the client wishes to transmit predetermined content, for example, another client device, a predetermined web server or system.

The request to transfer content may be received by the processing control section. The processing control section controls the content processing section to transmit the content in response to a request to transmit the content. The content processing section transmits one or more contents requested to be transmitted to the target device under the control of the processing control section.

Hereinafter, the process of transferring content through the processing control part and the content processing part will be described in detail. In the following description, four methods of content transmission in the DRM interoperating system will be illustrated. For ease of understanding, the first method is referred to as Example 3-1. Call the second method Example 3-2. Call the third method Example 3-3. Call the fourth method Example 3-4o <Example 3-1>

Fig. 18 is a block diagram showing the structure of a processing control section and a content processing section. Figure 18 shows entities related to the process of transferring content.

As shown in FIG. 18, the processing control section 40 includes a content processing controller 41 and a license

200780006766.9 No. 42 processing controller. Here, since the license processing controller 42 does not involve content transmission, a detailed description thereof will be described later.

The content processing controller 41 is used to request the content processing section 50 to transfer the content and control the process of transferring the content in accordance with a request from the client to transfer the content. The content processing controller 41 may exist in any location in the local area or the network area. Preferably, the content processing controller 41 may be included in a predetermined device that subscribes to the domain in the local area.

The content processing section 50 includes a plurality of content processing bodies. The content processing body may refer to an entity that performs functions related to the transmission and processing of content. The content processing body includes a content exporter 52, a content converter 51, and a content importer 53.

The content exporter 52 executes a function of transferring the content in the form of neutral content to the content converter 51 or the content importer 53 by exporting the content transferred from the content processing controller 41 by requesting. At this time, the neutral content may represent net content that is not encrypted by using a predetermined DRM. In addition, the content requested by the content processing controller 41 may be content encrypted by using a predetermined DRM. The content exporter 52 decrypts the requested content, converts the decrypted content into neutral content, and transmits the converted content. Alternatively, the content exporter 52 may receive neutral content decrypted in advance and transmit the received content.

The content converter 51 is used to receive the neutral content transferred from the content exporter 52, convert the neutral content into content having a required format, and transfer the content having the required format to the content importer 53. At this time, the required format represents the format required by the target device DV2. The content converter 51 only participates in the transmission when the format conversion of the neutral content is required.

The content importer 53 is used to receive the neutral content transmitted from the content converter 51 or the content importer 52. In addition, the content importer 53 may provide the received neutral content to the target device DV2. Alternatively, the content importer 53 may encrypt the received neutral content into content having a format suitable for DRM applied to the target device DV2, and add

200780006766.9 The secret content is provided to the target device DV2. At this time, in the former case, the target device DV2 encrypts the neutral content delivered from the content importer 53 into content having a format suitable for DRM applied to the target device DV2, and uses the content. In the latter case, since the content encrypted by the content importer 53 is transferred, the target device DV2 can use the actually transferred content.

19 and 20 show examples for showing the positions of the content processing controller 41 and the content processing body.

As shown in FIGS. 19 and 20, the content controller 41 and content processing bodies (ie, the content exporter 52, the content converter 51, and the content importer 53) are located at various positions according to the execution environment.

First, referring to FIG. 12, the content exporter 52 may be included in the requesting device DV1. The content importer 53 may be included in the target device DV2. In addition, the content processing controller 41 or the content converter 51 may be included in another device separate from the request device DV1 and the target device DV2.

Here, the request device DV1 and the target device DV2 need to be defined₀ The requesting device DV1 represents a client device that requests to deliver content. The requesting client RC1 may be included in the requesting device DV1. In addition, a predetermined DRM may be installed in the requesting device DV1. That is, the requesting device DV1 can use the content to which the predetermined DRM is applied.

As described above, the target device DV2 represents a client device or a predetermined system to which the content requested by the client RCI is delivered. The target client RC2 may be included in the target device DV2. In addition, the target DRM can be installed in the target device DV2. That is, the target device DV2 can use the content to which the target DRM is applied.

200780006766.9 No. 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 target device DV2. In addition, the content converter 51 is separately included in another device.

As described above, the content processing controller 41, the content exporter 52, the content converter 51, and the content importer 53 may be located at various positions. For security reasons, it may be advantageous to include the content exporter 52 in the requesting device DV1 and the content importer 53 in the target device DV2.

Therefore, in the following, the present invention will be described by adopting the structure shown in FIG. 19. However, the present invention is not limited to this. That is, depending on the execution environment, the content processing controller 41 and the content processing body may be included in the same device. Alternatively, according to the execution environment, some of the content processing controller 41 and the content processing body may be included in the same device. Alternatively, according to the execution environment, the content processing controller 41 and the content processing body may be included in separate devices.

Hereinafter, the process of transferring content based on the aforementioned system will be described in detail.

FIG. 21 is a flowchart showing a process of transferring content by using the content processing controller 41 and the content processing body. FIG. 21 shows an example of a process of transmitting one or more contents included in the requesting device DV1 to the target device DV2 as a target.

As shown in FIG. 21, in order to deliver content, the request client RC1, the content processing controller 41, and multiple content processing bodies (for example, the content exporter 52, the content converter 51, and the content importer 53) need to interact with each other.

First, the client RC1 is requested to transmit a content transmission request message for requesting transmission of one or more contents to the content processing controller 41 (operation S60).

At this time, the content transmission request message includes a transmission session identifier, a content identifier,

200780006766.9 First source information, target information, etc. In addition, the DRM system information of the target receiving the content may be included as an option in the content transmission request message.

The content identifier may represent information for identifying the content requested to be delivered. When there are a plurality of contents requested for delivery, there may be a plurality of content identifiers for identifying the contents.

The transmission session identifier means an identifier for uniquely identifying the transmission session. When a predetermined operation is performed, for example, when content transmission is canceled or when content transmission status is updated, the transmission session identifier may be used to identify the session.

The source information is used to determine where to deliver the requested content. The source information may include an identifier for identifying the source device or system such as the requesting device DV1, information about the format of the content file requested to be transmitted, and the like.

The target information includes information for identifying the target device DV2 as the target to which the requested content is transferred. The target information may include a target identifier for identifying the target, information about a file format required by the target, and the like. When the file format is converted by the content converter 51, information about the file format included in the target information can be referred to.

The content transmission controller 41 can use the information included in the content transmission message as follows. At this time, the content transmission controller 41 can use the information actually received from the requesting client RC1. Alternatively, the content transmission controller 41 may generate separate information corresponding to the information received from the request client RC1 and use the generated information. For example, the content transmission controller 41 may use a transmission session identifier and a plurality of data identifiers actually received from the requesting client RC1. Alternatively, the content transmission controller 41 may use the generated transmission session identifier and a plurality of data identifiers suitable for the session.

When receiving the content transmission request message, the content processing controller 41 collects information about the content

200780006766.9 The information of the second body, it is checked whether the content can be transferred, and the content processing body is determined to convert the content, that is, the content processing body constructs a content conversion chain (operations S61 to S63).

For example, the content processing controller 41 queries one or more exporters 52, content importers 53, and content converters 51 for capabilities and receives responses from corresponding entities. Therefore, it is possible to identify source, intermediate and target devices, systems, and DRM capabilities.

When collecting information, the content processing controller 41 determines whether to deliver the requested content based on the collected information. That is, it is checked whether the content processing body normally transmits the requested content. Here, the format of the requested content, system policy, and security authentication channel algorithm information that can be executed between entities can be considered. For example, when the content converter 51 cannot support content conversion to content having a required format based on the collected capabilities of the content converter 51, the content cannot be delivered. When the content converter 51 can support content conversion to content having a required format, the content can be transferred. The content processing controller 41 determines whether to transfer the content by considering the above-mentioned factors.

When it is determined to transfer the content, the content processing controller 41 determines the content processing body capable of efficiently performing the conversion of the requested content, for example, the content exporter 52, the content converter 51, and the content importer 53, and controls the The content processing body is constructed such that a content conversion chain including the determined content processing body is constructed. That is, the determined content processing body is controlled so as to construct the content conversion chain.

When determining the content processing body included in the content conversion chain, the content transmission controller may include the content converter 51 or may not include the content converter 51. When the format of the content requested to be transferred is different from the content format required by the target, the format of the transferred content must be converted. However, when the format of the content requested to be transferred is the same as the content format required by the target, there is no need to convert the format of the transferred content.

Therefore, when the format of the requested content is different from the content format required by the target, the content processing controller 41 allows the content converter 51 to be included in the content conversion chain. Where

200780006766.9 When the format of the requested content is the same as the content format required by the target, the content processing controller 41 allows the content converter 51 not to be included in the content conversion chain. Here, the format conversion of content may mean codec conversion.

For example, when the requested content is compressed using MPEG-2 compression, and when the content format available in the target is MPEG-4, the content with the MPEG-2 format is not available, and therefore, it must be passed The content converter 51 is used to convert the MPEG-2 format into the MPEG-4 format.

In Example 3-1, a situation in which the content needs to be converted because the format of the requested content is different from the format required by the target will be described. In this case, the content conversion chain must include a content converter 51₀ Subsequently, the content processing controller 41 sends a content export request, a content conversion request, and a content import request to the content exporter 42, the content converter 51, and the content importer 53, respectively (operations S67 to S69). A control message that requests the content processing body to perform the requested operation to perform the above request.

The control message used to request the export of the content may include a transmission session identifier, a content identifier, receiver information, and so on. The receiver information may represent information about the receiver to which the content exporter 52 exports and transmits the content. In Example 3-1, a case in which the content conversion chain includes the content converter 51 is described, and therefore, the receiver information may represent the identification information of the content converter 51. However, when the content conversion chain does not include the content converter 51, the receiver information may represent the identifier information of the content importer 53.

In addition, the control message for requesting conversion of the content may include a transmission session identifier, a content identifier, sender information, receiver information, format information of the content to be transferred, information about the converted format, and the like. At this time, the transmitter information and receiver information may indicate information for identifying the entity that transmits the content and the entity that receives the content. That is, the transmitter information is used to identify the content exporter 52 as a transmitter, and

200780006766.9 The receiver information described above is used to identify the content importer 53 as a receiver.

The control message used to request the import of the content may include a transmission session identifier, a content identifier, sender information, and so on. The transmitter information may refer to information for identifying a transmitter that transmits the content. In Example 3-1, the case where the content converter 51 exists is described, and therefore, the source information may represent the identification information of the content converter 51. When the content converter 51 is not included in the content conversion chain, the content exporter 52 becomes a transmitter. When requesting to receive the content, the information about the receiver that finally receives the content may include target information of the target and DRM system information.

In addition, when the content is requested to be exported, converted, and received, the content identifier included in the control message matches the content identifier requested when the client requests to transfer the content. When there are multiple contents requested to be transmitted by the client, the identifier of the requested content when the transmission of the content is requested is the same as the content identifier included in the content export request information, the content conversion request information, and the content import request information.

As described above, when the content exporter 52, the content converter 51, and the content importer 53 receive the content export request, the content conversion request, and the content import request from the content processing controller 41, respectively, the content exporter 52 and the content converter 51 A secure authentication channel (SAC) is established between and between the content converter 51 and the content importer 53 (operation S70). At this time, for example, a security technology such as transport layer security applied to the transport layer of TCP/IP may be applied to the SAC. In response to the content export request, the content exporter 52 establishes the SAC with the content converter 51, In order to safely transfer the requested content to the content converter 51 as the receiver. In addition, in response to the content conversion request, the content converter 51 converts the content transferred from the content to the exporter 52, and establishes a SAC for transferring the converted content to the content importer 53. On the other hand, in response to the content import request, the content importer 53 may establish a SAC for transferring the content transferred from the content converter 51 to the target device DV2 (ie, the end point of the content transfer). When the content importer is installed in When in a device other than the target device, this

200780006766.9 The first is more useful.

Therefore, a SAC that constitutes a path from the content exporter 52 to the content importer 53 via the content converter 51 is established. In addition, the SAC through which the content importer 53 provides the content to the final end point can be established from the content importer to the end point. Each content processing entity can report to the content processing controller 41 that the SAC is established (operations S71 to S73). ).

When the SAC is established, the content exporter 52 starts to transfer the content. At this time, the pair of content processing bodies connected to each other (that is, the content exporter 52-content converter 51 and the content converter 51-content importer 53) support the multiplexing protocol. The multiplex protocol is used to enable multiple content to be transferred in a single session. This can support variable frame sizes. Therefore, multiple contents can be delivered through a single session.

Fig. 22 shows an example for showing a multiplexing protocol.

As shown in Figure 22, multiple content can be delivered in a single session. Insert the content index into the header of each content. The content index may be a value with predetermined bits (for example, four bits) for identifying the content. The content index is a factor used in conjunction with the requested content to distinguish the content delivered through the corresponding session from each other. In addition, a content separator for distinguishing the content from each other is inserted into the end of the content. For example, four zeros can be used to construct the content separator.

The content can be divided into multiple frames according to the length of the content. The frame size with predetermined bits (for example, four bits) is inserted into the header of the frame. The frame payload used to carry data is located behind the position of the frame size. On the other hand, the end-of-transmission (EOT, end-of-transmission), which represents the end of the transmission, is inserted into the last part of the conversation. For example, the EOT may be four digits. According to the support of the multiplex protocol, multiple contents may be transmitted through a session with the transmission session identifier provided by the requesting client RC1. Continuous execution from content exporter 52

200780006766.9 No. above transmission. The content exporter 52 sends the requested content to the content converter 51 through the SAC (operation S74). The content converter 51 receives the content and performs format conversion to the format required by the target (operation S75). After the conversion, the content converter 51 transmits the converted content to the content importer 53 through the SAC (operation S76). Then, the content importer 53 receives the content and provides the received content to the target device DV2.

The content transferred from the content exporter 52 to the content importer 53 via the content converter 51 may be neutral content. The neutral content may mean the net content that is not encrypted by using a predetermined DRM. The content exporter 52 may export the requested content, convert the exported content into neutral content, and transmit the neutral content. Alternatively, the content exporter 52 may export pre-converted neutral content and transfer the neutral content. This process can be performed in consideration of a policy or an export process specified by DRM applied to the requested content.

In addition, the content importer 53 may consider the policy or import process specified by the DRM system applied to the target device to deliver the received neutral content to the target device. For example, the neutral content may be suitable for target DRM encryption and provided to the target device DV2₀Alternatively, the received neutral content may be provided to the target device DV2 without encryption.

On the other hand, the content exporter 52, the content converter 51, and the content importer 53 may report the transmission status of the content to the content processing controller 41. To this end, the content processing controller 41 must subscribe to a predetermined event through which the transmission status of the content can be provided. The predetermined event is called a content-transmission-status providing event.

Before requesting the export of the content, the content processing controller 41 may request to reserve the content-transmission-status providing event (operations S64 to S66). For example, the content processing controller 41 may request the content exporter 52, the content converter 51 and the content importer 53 subscribe to the content-transmission-status event and subscribe to the corresponding event.

200780006766.9 When the content-transmission-status event is subscribed, the content processing controller 41 may receive the event message including the content-transmission-status information in a push or pull manner. At this time, in the push mode, as long as the content-transmission-state changes, the content processing body automatically pushes the event message (including content transmission-state information). Therefore, the content processing controller 41 can automatically receive the content transmission-status. In the pull mode, the content processing controller 41 obtains the content-transmission-status information from the content processing body when needed.

When subscribing to the event, the content processing controller 41 reports to the content processing body whether to provide the content-transmission-status information in a push mode or a pull mode. In Example 3-1, an example in which the content-transmission-status is provided to the content processing controller 41 in a push manner is described.

When subscribing to the content-transmission-status providing event, the content processing controller 41 may receive an event message including content-transmission-status information from the content processing body. At this time, the transmission session identifier must be included in the event message. Here, the transmission session identifier is the same as the transmission session identifier assigned when the content is requested.

When the content is started to be transferred, the content exporter 52 sends to the content processing controller 41 an event message indicating that the content is to be transferred. For example, it is possible to transmit an event message including a "start" element. In addition, during the transmission of the content, an event message indicating that the content is being processed may be periodically transmitted to the content processing controller 41. For example, an event message including a "process completed" element can be transmitted. When the content transmission is completed, the content exporter 52 transmits to the content processing controller 41 an event message indicating that the content transmission is completed. For example, an event message including a "done" element can be transmitted. In addition, in addition to starting, processing, and ending processes, it is also possible to generate event messages for each process based on event information about all processes of converting and transferring data including content or licenses, and transfer the event messages.

When the content is started to be transferred, the content converter 51 sends to the content processing controller 41 an event message indicating that the content is started to be transferred. For example, an event message including a "start" element can be transmitted. In addition, during the transmission of the content, the content processing controller can be periodically reported

200780006766.9 No.

41 Transmits an event message indicating that the content is being processed. For example, an event message including a "process completed" element can be transmitted. When the content transmission is completed, the content exporter 52 transmits to the content processing controller 41 an event message indicating that the content transmission is completed. For example, an event message including a "done" element can be transmitted.

When the content is started to be delivered, the content importer 53 sends to the content processing controller 41 an event message indicating that the content is started to be delivered. For example, an event message including a "start" element can be transmitted. In addition, during the transmission of the content, an event message indicating that the content is being processed may be periodically transmitted to the content processing controller 41. For example, an event message including a "process completed" element can be transmitted. When the content transmission is completed, the content exporter 52 transmits to the content processing controller 41 an event message indicating that the content transmission is completed. For example, an event message including a "done" element can be transmitted.

When receiving an event message indicating the start of transmission from the content exporter 52, the content processing controller 41 transmits an event message corresponding to the start of transmission to the requesting client RC1. That is, the content processing controller 41 reports that the content is started to be transferred. In addition, when the content processing controller 41 receives an event message indicating 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 reports that the content is being processed. When the content processing controller 41 receives an event message indicating the completion of the transmission from the content importer, the content processing controller 41 sends an event message corresponding to the completion of the transmission to the requesting client RC1. That is, the content processing controller 41 reports that the content transmission is completed. When the above-mentioned event message is output to the requesting client RC1, the event message including the transmission session identifier specified when the requesting client RC1 requests to transmit the content may be transmitted.

On the other hand, the content processing controller 41 individually recognizes the transferred content and reports the transmission status or conversion status of the content. Alternatively, the transmitted content can be reported together. In other words, when transmitting content, the content processing controller 41 distinguishes a plurality of contents based on the transmission time and reports the transmission time to the client. Alternatively, after the content is delivered, the events are managed together, and then the content-transmission-status can be reported. In addition, through content recognition

200780006766.9 first information to perform content recognition. The above process can be similarly applied to licenses. In the case of a license, the above process can be performed by the license transfer controller.

By using the above method, the requesting client RC1 can identify the transmission status of the content with respect to the session requesting the content to be delivered. When the user interface function is included in the requesting client RC1, the requesting client RC1 can report the transmission status of the content to the user by using numbers or graphs.

In addition, when multiple contents are delivered through a session, the transmission status of each content can be identified. Therefore, the transmission status of the content requested to be transmitted through the session is continuously recognized.

On the other hand, during content transmission, the content exporter 52, the content converter 51, and the content importer 53 can recognize errors that occur in the SAC. In this case, the content processing body that finds the error may transmit to the content processing controller 41 an event message indicating that the error has occurred. For example, an event message including an "error" or "SAC-fault" element is transmitted. At this time, the event message of course includes the transmission session identifier.

When receiving an event message indicating that an error has occurred from a predetermined content processing body, the content processing controller 41 requests the content processing body participating in the content transmission to cancel the transmission. When requesting cancellation of transmission, the transmission session identifier of the cancelled transmission session must be provided. In addition, the content processing controller 41 sends an event message indicating that an error has occurred to the requesting client RC1. Therefore, the requesting client RCI can recognize that an error has occurred. On the other hand, the content processing body that received the request to cancel the transmission cancels the transmission session.

The cancellation of the transmission can be initiated by the requesting client RC1. In this case, the client RC1 is requested to transmit a transmission cancellation request including the same transmission session identifier provided when requesting the transmission of the content to the content processing controller 41. Then, in response to the cancellation request, the content processing controller 41 requests the content processing entity participating in the transmission to cancel the transmission. The content processing entity that receives the transmission cancellation request cancels the transmission session.

200780006766.9 On the other hand, in addition to event messages such as content transmission start, content transmission, content transmission completion, content transmission error, etc., the content processing controller 41 can also request the content converter 51 to subscribe to events that can monitor the content conversion process, and Event messages such as content format conversion start, content format conversion, content format conversion completion, content format conversion error, etc. can be received. Alternatively, the content processing controller 41 may request an event indicating that the data conversion through a predetermined encryption technology is reserved and may receive data conversion start through encryption technology, data conversion through encryption technology, data conversion completion through encryption technology, and data conversion through encryption technology. Encryption technology data conversion error and other event messages. Alternatively, the content processing controller 41 may request the conversion content processing body to reserve an event representing the SAC formation process, and may receive event messages such as SAC formation start, SAC formation in progress, SAC formation completion, SAC formation error, etc.

In Example 3-1, the process of constructing a content conversion chain using the content processing controller of the processing control part and the content processing body of the content processing part and transferring a single content or multiple contents through a single session is described.

In the following example 3-2, the process of constructing multiple content conversion chains and delivering single content or multiple content through multiple sessions in response to a request from the client RC1 will be described. In this case, in response to the content transmission request, the content can be delivered to one or more destinations.

<Example 3-2>

FIG. 23 is a block diagram showing a system structure for a content transmission process according to Example 3-2.

Referring to FIG. 23, the requesting device DV1 may include a requesting client RC1 and a content exporter 52₀In addition, the first target device DV2-1 includes a first content importer 53a. The second target 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 request device DV1 or the target device DV2.

200780006766.9 Fig. 24 is a flowchart showing the content transmission process according to Example 3-2. FIG. 24 shows an example of a process of transmitting one or more contents included in the requesting device DV1 to the first and second target devices DV2-1 and DV2-2 as targets in response to a request of the requesting client RC1.

As shown in FIG. 24, the client RC1 is requested to transmit a content transmission request message to the content processing controller 41. The content transmission request message is used to request transmission to the first and second target devices DV2-1 and DV2-2. One or more contents in DV1 (operation S81). At this time, the content transmission request message includes at least one transmission session identifier, content identifier, source information, target information, and the like. In addition, as an option, the content transmission request message may include DRM system information of a target receiving the content.

The content identifier may represent information for identifying the content requested to be delivered. In Example 3-2, since one or more contents are transmitted to the first and second target devices DV2-1 and DV2-2, there may be one or more content identifiers.

The transmission session identifier means an identifier for uniquely identifying the transmission session. In Example 3-2, the requested one or more contents must be delivered to the first target device DV2-1, and the requested one or more contents must be delivered to the second target device DV2-2» Therefore, The transmission session is divided into two transmission sessions. Therefore, there may be two transport session identifiers. For example, there may be first and second transmission session identifiers.

The source information represents information used to determine where to deliver the requested content. The source information may include an identifier for identifying the source device or system such as the requesting device DV1, information about the format of the content file requested to be transmitted, and the like. In Example 3-2, since the requested one or more contents are included in the requesting device DV1, the source information may include information about the requesting device DV1 and information about the file format.

200780006766.9 The target information described above includes information for identifying the target device DV2 as the target for transmitting the requested content. The target information may include a target identifier for identifying the target, information about the file format required by the target, and the like. When the format conversion of the file is performed by the content converter 51, the information about the file format included in the target information can be referred to. In Example 3-2, the target information may include information and format information about the first and second target devices DV2-1 and DV2-2.

When receiving the content transmission request message, the content processing controller 41 collects information about the content processing body (operation S82). For example, the content processing controller 41 sends to one or more content exporters 52, content importers 53, and content converters. 51 Query capabilities, and get a response from the corresponding entity. Therefore, the source, intermediate, and target devices, systems, and DRM capabilities can be identified.

When the information is collected, the content processing controller 41 determines whether to transfer the requested content or content based on the collected information. That is, it is checked whether the content processing body normally transmits the requested content. Here, it must be considered whether the two transmission sessions requested by the requesting client RC1 are satisfied.

When content transmission is determined to be performed, the content processing controller 41 controls the content processing body to construct a content conversion chain by determining a content processing body that can effectively perform the conversion of the requested content. In Example 3-2, since the transmission session used to transmit the requested content to the first target device DV2-1 is distinguished from the transmission session used to transmit the requested content to the second target device DV2-2, Two content conversion chains are needed to perform each transfer session.

FIG. 25 shows the main content conversion chain for delivering one or more contents to the first target device DV2-1.

As shown in Figure 25, the main content conversion chain includes content exporter 52, content conversion

200780006766.9 The first device 51 and the first content importer 53a.

Fig. 26 shows an auxiliary content conversion chain for delivering one or more contents to the second target device DV2-2.

As shown in FIG. 26, the auxiliary content conversion chain includes a content exporter 52 and a second content importer 53bo. At this time, the main content conversion chain includes a content converter 51, but the auxiliary content conversion chain does not include content conversion. Maker 51₀Since the format of the requested content or content is different from the content format required by the first target device DV2-1, the content needs to be formatted. On the other hand, the format of the requested one or more contents is the same as that required by the second target device DV2-2.

The content processing controller 41 controls the content processing body so as to construct the main content conversion chain. Perform the first transfer session. Then, the content processing controller 41 controls the content processing body so as to construct an auxiliary content conversion chain. Perform a second transmission session. In another example of constructing a content conversion chain, a single conversation may be repeatedly generated.

First, the content processing controller 41 transmits a content export request, a content conversion request, and a content import request to the content exporter 42, the content converter 51, and the content importer 53, respectively (operation S84). The above request is executed by transmitting a control message to the content processing body.

When requesting to export the content, the content processing controller 41 may provide the content exporter 52 with the first transmission session identifier, the content identifier of the requested one or more content, and the content converter 51 as receiver information. Information.

In addition, when the content is requested to be converted, the content processing controller 41 may provide the first transmission session identifier, the content identifier of the requested one or more content, information about the content exporter 52 as the sender information, About content guide as receiver information

200780006766.9 The information of the first loader 53, the format of one or more contents to be transmitted, the information about the converted format, etc.

When the content is requested to be imported, the content processing controller 41 may provide the content exporter 52 with the first transmission session identifier, the content identifiers of the requested one or more content, and information about the content converter 51 as the sender. information. In addition, the content processing controller 41 may also provide information about the receiver that finally receives the content and DRM information of the target DRM system. Here, the information about the receiver may mean information about a predetermined storage entity or module (for example, the first target device DV2-1) included in the end point of the content transmission.

As described above, when the content exporter 52, the content converter 51, and the content importer 53 receive a content export request, a content conversion request, and a content import request from the content processing controller 41, respectively, the content is transferred and passed through the host The content conversion chain receives the event (operation S85). First, a SAC is established between the content exporter 52 and the content converter 51 and between the content converter 51 and the first content importer 53a. In addition, it is also possible to establish a SAC between the first content importer 53a and the first target device DV2-1. When the SAC is established, the content exporter 52 starts to deliver the content. At this time, the pair of content processing entities (ie, the content exporter 52-content converter 51 and the content converter 51-content importer 53) support the aforementioned multiplexing protocol. Therefore, multiple content can be delivered through a single session.

According to the support of the multiplexing protocol, multiple contents can be transmitted in a session with the first transmission session identifier provided by the requesting client RC1 (or generated by the content processing controller 41). The above-mentioned transmission is continuously performed from the content exporter 52. The content transferred from the content exporter 52 to the content importer 53 via the content converter 51 may have a type of neutral content. As described above, the neutral content may mean the net content that is not encrypted by using a predetermined DRM.

200780006766.9 On the other hand, the content exporter 52, the content converter 51, and the first content importer 53a can report the transmission status of the content to the content processing controller 41. 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-transmission-status event, and receives the event message. Since the event is described in Example 3-1, a detailed description about the event will be omitted.

When the content is transferred to the first target device DV2-1 (operation S86), the content processing controller 41 transmits a content export request to the content exporter 52 and the second content importer 53b included in the auxiliary content conversion chain, respectively And the content import request (operation S87). That is, the two content conversion chains continuously perform transmission under the control of the content processing controller 41. Of course, the two content conversion chains are generated at the same time, and the transmission is performed by the two content conversion chains under the control of the content processing controller.

When requesting to export the content, the content processing controller 41 may provide the content exporter 52 with the second transmission session identifier, the content identifier of the requested one or more content, and the content importer 53 as receiver information. Information. In addition, when the content is requested to be imported, the content controller 41 may provide the second content importer 53b with the second transmission session identifier, the content identifier of the requested one or more content, and the content exporter as a sender.Device52Information. 52 information.

As described above, when the content exporter 52 and the second content importer 53b receive the content export request and the content import request from the content processing controller 41, respectively, the content is transferred, and the event is received through the auxiliary content conversion chain (operation S88) ο First, a SAC is established between the content exporter 52 and the second content importer 53b. When the SAC is established, the content exporter 52 starts to deliver the content. At this time, a pair of content processing bodies (ie, the content exporter 52-the second content importer 53b) supports the above-mentioned multiplexing protocol. Therefore, multiple content can be delivered through a single session.

According to the support for the multiplex protocol, it can be provided by the requesting client RC1 through

200780006766.9 The second transfer session identifier (or generated by the content processing controller 41) corresponds to a single session to transfer multiple content. The above-mentioned transmission is continuously performed from the content exporter 52. The content transferred from the content exporter 52 to the second content importer 53b may have a type of neutral content. As described above, the neutral content may mean the net content that is not encrypted by using a predetermined DRM. When the neutral content is transferred to the second content importer 53b included in the second target device DV2-2, the transfer is completed (operation S89). On the other hand, the content exporter 52 and the second content importer 53b may send The content processing controller 41 reports the transmission status of the content. To this end, the content processing controller 41 requests the content exporter 52 and the second content importer 53b to subscribe to the content-transmission-status event, and receives the event message. The content processing controller 41 can recognize the transmission status of each content, and also provide the transmission status information to the requesting client RC1.

In Example 3-2, the process of constructing multiple content conversion chains and transmitting single content or multiple content through multiple sessions in response to the request of the requesting client RC1 is described.

In the following example 3-3, a case will be described in which the content requested by the requesting client RC1 is transferred to a single target by constructing multiple content conversion chains. In Example 3-3, an example in which two content conversion chains are constructed will be described.

<Example 3-3>

Fig. 27 is a block diagram showing a system structure for a content transmission process according to Example 3-3.

Referring to FIG. 27, the requesting device DV1 may include a requesting client RCI and a content exporter 52. In addition, the target device DV2 includes a content importer 53. The content transmission controller and the content converter 51 may be included in a device separate from the request device DV1 or the target device DV2.

Fig. 28 is a flowchart showing a content transmission process according to Example 3-3. Figure 28 shows

The 200780006766.9 paragraph presents an example of the process of transmitting one or more contents included in the requesting device DV1 to the target device DV2 as the target in response to the request of the requesting client RC1.

Referring to FIG. 28, first, the request client RC1 transmits a content transmission request message for requesting transmission of the content to the content processing controller 41 (operation S100). At this time, the content transmission request message includes a transmission session identifier, a content identifier, source information, target information, and so on. In addition, as an option, the content transmission request message may include DRM system information of a target receiving the content.

The content identifier may indicate information for identifying the content requested to be delivered. When multiple content is requested to be delivered, there may be multiple content identifiers for identifying the content.

The transmission session identifier means an identifier for uniquely identifying the transmission session. The source information represents information used to determine where to deliver the requested content. In Example 3-3, the source information may include information and format information about the requesting device DV1.

The target information includes information for identifying the target device DV2 to which the requested content is transferred. The target information may include a target identifier for identifying the target, information about the file format required by the target, and the like.

When receiving the content transmission request message, the content processing controller 41 collects information about the content processing body, and determines whether to transfer the content based on the collected information. When it is determined to transfer the content, the content processing controller 41 determines the content processing body participating in the transmission (operations S101 to S103). First, the content processing controller 41 transfers the content to one or more content exporters 52, content importers, and content conversions. The device 51 queries the capabilities and obtains a response from the corresponding entity. Therefore, the ability to identify source, intermediate and target devices, systems, and DRM.

When collecting information, the content processing controller 41 determines whether to transmit based on the collected information.

200780006766.9 Send the requested content. That is, it is checked whether the content processing body normally transmits the requested content. Here, the required content format, system policy, information about the security authentication channel algorithm that can be executed between entities, etc. can be considered.

When it is determined to transfer the content, the content processing controller 41 determines the content exporter 52 and the content converter 51, and controls the content exporter 52 and the content converter 51 to use the content exporter 52 and the content converter 51 to construct the master Content conversion chain. In Example 3-3, an example in which the content format requested to be transmitted is different from the content format required by the target device DV2 is described. Therefore, the content converter 51 must be included in the content conversion chain.

FIG. 29 shows an example of a main content conversion chain constructed using the content processing controller 41. Referring to FIG. 29, the main content conversion chain includes a content exporter 52 and a content converter 51.

Subsequently, the content processing controller 41 transmits a content export request and a content conversion request to the content exporter 52 and the content converter 51 included in the main content conversion chain, respectively (operations S107 and S108). The above-mentioned request is executed by transmitting a control message to the content processing body.

When requesting to export the content, the content processing controller 41 may provide the content exporter 52 with a transmission session identifier, a content identifier, and information about the content converter 51 as a receiver. In addition, when requesting conversion of the content, the content processing controller 41 may provide a transmission session identifier, a content identifier, information about the content exporter 52 as a transmitter, information about the content importer 53 as a receiver, The format of the requested content, information about the converted format, etc.

As described above, when the content exporter 52 and the content converter 51 respectively receive the content export request and the content conversion request from the content processing controller 41, the SAC is established between the content exporter 52 and the content converter 51 (operation S109). The content exporter 52 and the content converter 51 may report to the content processing controller that the SAC is established (operations S110 and S111).

When the SAC is established, the content exporter 52 starts to deliver the content. At this time, each pair

200780006766.9 The content processing body (that is, the content exporter 52-content converter 51) can support multiple transmission protocols. As mentioned above, the multiplex protocol is used to enable multiple content to be delivered through a single session. According to the support for the multiplex protocol, when multiple content is requested to be transferred, the multiple content can be transferred through a single session.

The above-mentioned transmission is continuously performed from the content exporter 52. The content exporter 52 transmits the requested content to the content converter through the SAC. Then, the content converter 51 converts the format of the content into the required format.

The content exporter 52 and the content converter 51 may report the transmission status or conversion status of the content to the content processing controller 41. To this end, the content processing controller 41 must reserve the predetermined event by requesting the content processing body to provide the predetermined event before requesting the export of the content (operations S104 to S106).

The predetermined event may include a content transmission status providing event and a content conversion status providing event. As described above, the content processing body participating in the transmission can report conditions such as content transmission start, content being transmitted, content transmission completion, content transmission error, etc., as an event message by using the content transmission status providing event.

The content conversion state providing event may be executed by the content converter 51. By requesting the content converter 51 to provide the content conversion status providing event, the content processing controller 41 can subscribe to the content conversion status providing event. Then, the content processing controller 41 may be provided with conditions such as content conversion started, content being converted, content conversion completed, content conversion error status, and the like.

When the content transferred from the content exporter 52 is transferred to the content converter 51, and when the format conversion of the content is completed (operation S112), the content processing controller 41 must construct an auxiliary including the content converter 51 and the content importer 53 Content conversion chain. Under the control of the content processing controller 41, the first and auxiliary content conversion chains operate continuously.

200780006766.9 Fig. 30 shows an example of the auxiliary content conversion chain constructed by the content processing controller 41.

As shown in FIG. 30, the auxiliary 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 to the content converter 51 and the content importer 53 included in the auxiliary content conversion chain, respectively (operations S113 and S114). In the content converter 51 and the content importer Establishing SAC between 53 (operation S115). At this time, SAC may also be established between the content importer 53 and the target device DV2. The content converter 51 transmits the converted content to the content importer 53 through the SAC. Then, the content importer 53 receives the transferred content. The content converter 51 and the content importer 53 can report the transmission status of the content to the content processing controller 41. The content transferred from the content converter 51 to the content importer 53 is neutral content. As described above, the neutral content may represent net content that is not encrypted by using a predetermined DRM.

In Example 3-3, the process of constructing two content conversion chains to transmit the content requested by the client RC1 to a single target is described.

In the following Example 3-4, a case will be described in which the content requested by the requesting client RC1 is transferred to multiple destinations by constructing multiple content conversion chains.

FIG. 31 is a block diagram showing a system for delivering content according to Example 3-4.

Referring to FIG. 31, the requesting device DV1 may include a requesting client RC1 and a content exporter 52. In addition, the first target device DV2-1 includes a first content importer 53a. The second target device DV2-2 includes a second content importer 53bo and the third target device DV2-3 includes a third content importer 53. The content transmission controller and the content converter 51 may be included in a device separate from the request device DV1 or the target device DV2.

200780006766.9 Figure 32 is a flowchart showing the content transmission process according to Example 3-4. FIG. 32 shows an example of a process of transmitting the content included in the requesting device DV1 to the first to third target devices DV2-1 to DV2-3 as three targets in response to a request of the requesting client RC1.

Referring to FIG. 32, the client RCI is requested to transmit a content transmission request message for requesting transmission of the content to the content processing controller 41 (operation S121). At this time, the content transmission request message includes a transmission session identifier and a content identifier. , Source information, target information, etc. In addition, as an option, the content transmission request message may include DRM system information of a target receiving the content.

The content identifier may represent information for identifying the content requested to be delivered. When there are a plurality of contents requested for delivery, there may be a plurality of content identifiers for identifying the contents.

The transmission session identifier means an identifier for uniquely identifying the transmission session. The source information represents information used to determine where to deliver the requested content. In Example 3-4, the source information may include information and format information about the requesting device DV1.

The target information includes information for identifying the target device DV2 that is the target of transmitting the requested content. In Example 3-4, the target information may include information about the first to third target devices DV2-1 to DV2-3, format information required by the target device DV2, and the like. In Example 3-4, it is assumed that the file formats required by the first to third target devices DV2-1 to DV2-3 are the same. However, the present invention is not limited to this.

When receiving the content transmission request message, the content processing controller 41 collects information about the content processing body (operation S122). For example, the content processing controller 41 sends to one or more content exporters 52, content importers 53, and content converters. 51 Query capabilities, and get a response from the corresponding entity. Therefore, the source, intermediate, and target devices, systems, and DRM capabilities can be identified.

200780006766.9 First, when collecting information, the content processing controller 41 determines whether to transmit the requested one or more contents based on the collected information. That is, it is checked whether the content processing body normally transmits the requested content. Here, the format of the required content, system policy, information about the security authentication channel algorithm that can be executed between entities, etc. can be considered.

When it is determined to transfer the content, the content processing controller 41 controls the content exporter 52 and the content converter 51 so as to construct a main content conversion chain including the content exporter 52 and the content converter 51. In Example 3-4, an example in which the format of the content requested to be transmitted is different from the content format required by the target device DV2 is described. Therefore, the content converter 51 must be included in the content conversion chain. In this description, the chain is constructed by receiving a control command for constructing the content conversion chain from the client. However, the present invention is not limited to this. There are various embodiments, such as an example in which the content processing controller can generate a control command for constructing a chain and construct the chain.

FIG. 33 shows an example of a main content conversion chain constructed using the content processing controller 41. Referring to FIG. 33, the main content conversion chain includes a content exporter 52 and a content converter 51.

Subsequently, the content processing controller 41 sends a content export request and a content conversion request to the content exporter 52 and the content converter 51 included in the main content conversion chain, respectively (operation S124). By transmitting a control message to the content processing body Execute the above request.

When requesting to export the content, the content processing controller 41 may provide the content exporter 52 with a transmission session identifier, a content identifier, and information about the content converter 51 as a receiver. In addition, when requesting conversion of the content, the content processing controller 41 may provide a transmission session identifier, a content identifier, information about the content exporter 52 as a transmitter, information about the content importer 53 as a receiver, The format of the requested content, information about the converted format, etc.

As mentioned above, when the content exporter 52 and the content converter 51 are removed from the content processing controller

200780006766.9 No.

When 41 receives the content export request and the content conversion request, respectively, a SAC is established between the content exporter 52 and the content converter 51. When the SAC is established, the content exporter 52 starts to transfer content (operation S125). At this time, each pair of content processing bodies (ie, content exporter 52-content converter 51) can support a multiplex transmission protocol. Since multiple transmission protocols are supported, when multiple content is requested to be transmitted, the multiple content can be transmitted through a single session.

The above-mentioned transmission is continuously performed from the content exporter 52. The content exporter 52 transmits the requested content to the content converter through the SAC. Then, the content converter 51 converts the format of the content into the format required by the target device DV2 (operation S126). The content exporter 52 and the content converter 51 may report the transmission of the content to the content processing controller 41 State or transition state. To this end, the content processing controller 41 must reserve the predetermined event by requesting the content processing body to provide the predetermined event before requesting the guide content. At this time, the predetermined event may include a content transmission status providing event and a content conversion status providing event. Since this is described in Example 3-3, detailed description will be omitted.

When the content transferred from the content exporter 52 is transferred to the content converter 51, and when the format conversion of the content is completed, the content processing controller 41 continuously constructs a plurality of auxiliary content conversion chains corresponding to the plurality of targets . The plurality of auxiliary content conversion chains may include first to third auxiliary content conversion chains. Here, the first to third auxiliary content conversion chains may be formed continuously or simultaneously. In addition, the method of constructing a content conversion chain may include a method of forming a chain from a starting point to a target and repeatedly forming the chain (such as constructing multiple single chains as described in Example 3-2) or by distinguishing based on the conversion time The method of forming the chain separately (described in Examples 3-3 and 3-4).

FIG. 34 shows an example of the structure of the first auxiliary content conversion chain, the second auxiliary content conversion chain, and the third auxiliary content conversion chain caused by the content processing controller 41.

200780006766.9 As shown in FIG. 34, the first auxiliary content conversion chain may include a content converter 51 and a first content importer 53a. The content conversion controller transmits a content conversion request and a content import request to the content converter 51 and the first content importer 53a, respectively. A SAC is established between the content converter 51 and the first content importer 53a. When the SAC is established, the content is transferred from the content converter 51 to the first content importer 53a (operation S127).

When the content is transferred to the first content importer 53a, the content processing controller 41 constructs a second auxiliary content conversion chain. At this time, the second auxiliary content conversion chain may include a content converter 51 and a second content importer 53b. The content conversion controller transmits a content conversion request and a content import request to the content converter 51 and the second content importer 53b, respectively. Then, a SAC is established between the content converter 51 and the second content importer 53b. When the SAC is established, the content is transferred from the content converter 51 to the second content importer 53b (operation S128).

When the content is transferred to the second content importer 53b, the content processing controller 41 constructs a third auxiliary content conversion chain. At this time, the third auxiliary content conversion chain may include a content converter 51 and a third content importer 53co. The content conversion controller transmits the content conversion request and content to the content converter 51 and the third content importer 53c, respectively. Import request. Then, when the SAC is established, the content is transferred from the content converter 51 to the third content importer 53c (operation S129). On the other hand, the content processing body included in the auxiliary content conversion chain can be based on the progress of the transfer process. The content processing controller 41 transmits an event message indicating the transmission status of the content and the like. The above-mentioned events have been described in Examples 3-1 to 3-3.

In Example 3-4, the process of transmitting the content requested by the request client RC1 to multiple target devices DV2 by constructing multiple content conversion chains is described. In the method of transmitting content according to Example 3-4, it is possible to broadcast the content to a plurality of targets and reduce the waste of transmission resources. Ability to reduce the number of content format conversion operations performed in order to deliver to the multiple destinations

200780006766.9 The content mentioned in the article. Even if an error occurs in the auxiliary content conversion chain, the operation of the main content conversion chain has been performed, so only the auxiliary content conversion chain needs to be restored.

4. Functions and operations of the processing control part and the license processing part On the other hand, an authenticated client of the client part can request the processing control part to transfer a license. For example, assume that there are a first client device in which the first DRM is installed and a second client device in which the second DRM is installed. When the user intends to transmit the first DRM content stored in the first client device to the second client device, the first client can transmit the content to the target second client by using the above-mentioned content transmission process equipment. In this case, when the second client device intends to use the transferred content, a license suitable for the second DRM is required. Therefore, the first client requests the transfer of the license.

FIG. 35 is a block diagram showing the structure of a system related to license transmission.

As shown in FIG. 35, the processing control section 40 includes a content processing controller 41 and a license processing controller 42. Here, the content processing controller 41 has been described above. The content processing controller 41 and the license processing controller 42 may be included at any place in the network area or the local area. The content processing controller 41 and the license processing controller 42 may be located in different areas. For example, the content processing controller 41 may be included in a predetermined device in the local area. The license processing controller 42 may be included in a service provider in the 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 a license transmission request from the client. When receiving a license transmission request, by collecting information on entities included in the system, the license processing controller 42 determines the entities participating in the transmission and determines whether the license can be transmitted. Therefore, it is possible to construct a chain through which the license is transferred.

In addition to the license processing controller 42, the license manager 24 of the authentication and management section 20 and the license processor 32 of the license processing section 30 can also participate in the license transfer.

200780006766.9 Lost. The entities participating in the license transmission can be included at any place in the network area or the local area. As needed, a SAC for securely transferring license information can be established between predetermined entities. The license processing controller 42 requests the predetermined entity (for example, the license manager 24) to provide one or more neutral licenses, and Receive the one or more neutral licenses. The neutral license may represent compatible neutral license information from which license information of many types of DRM can be extracted. When a user purchases predetermined DRM content, by using a license of DRM, the neutral license can be generated and stored in the license manager. In addition to being stored in the license manager 24, the neutral license 24 may be stored in a domain manager or a reference point controller. In the process of transferring the license, the entity providing the neutral license can perform the function of the guide.

The neutral license may include one or more related content identifiers, manager information, information about the subject of which the license can be used, a usage model in which permission restrictions are described, and the like.

By using the provided neutral license, the license processing controller 42 generates a new neutral license to be actually transferred. At this time, various types of information can be considered, such as the relationship between the content and the topic, the goal, the topic mapping relationship, and the resource mapping relationship.

The neutral license generated by the license processing controller 42 is transferred to the license processor 32 of the license processing section 30. The license processor 32 is an entity that transmits the neutral license received from the license processing controller 42 to the local DRM receiver 900 of the target. At this time, by complying with the method defined in the DRM of the target, the license processor 32 can convert the received neutral license into a license suitable for the DRM of the target, and send it to the local DRM receiver 900 Provide the converted license. Alternatively, the neutral license may be provided to the local DRM receiver 900 of the target as it is. In this case, the license conversion is performed in the DRM system of the target. The license processor and the local DRM receiver may perform the functions of the converter and the receiver, respectively.

200780006766.9 The entity participating in the license transmission can transmit to the license processing controller 42 an event message indicating the process of transmitting and processing the license. To this end, by requesting the corresponding entity to provide a license transmission status event, the license processing controller 42 must subscribe to the license transmission status event. The license processing controller 42 may provide the client 3 with information corresponding to the received event message. In addition, the license processing controller 42 may provide the client with an event message for indicating a progress state (such as a process of generating a neutral license from the license manager 24 and a process of providing a neutral license).

So far, the main functions of the DRM interoperating system including the client part 10, the authentication and management part 20, the processing control part 40, the content processing part 50, and the license processing part 30 have been described. In the above description, in response to a data (content or license) transmission request from a client, the DRM interoperating system according to an exemplary embodiment of the present invention allows neutral data (neutral format content or neutral license) to be associated with the target The required format is compatible and the neutral data is transferred to the target.

5. The function of the unit entity and the process of handling events use one or more entities to construct each part of the DRM interoperating system, such as the client part 10, the authentication and management part 20, the processing control part 40, the content processing part 50, License processing section 30 and so on. At this time, the entity may refer to a module or device of software or hardware configured to perform a predetermined unique function. Each entity may be constructed using one or more unit function modules that perform predetermined unit functions. The entity is installed in a predetermined device to communicate data with other entities through a predetermined interface. In addition, even if the entities belong to the same part, the entities can be installed in different devices. According to the execution environment, the device may be different.

When the domain is initially constructed, the entity may report the existence of the entity to another entity in the specific environment in which the entity is included. To this end, the entity may include a configuration information provider as a unit function module.

200780006766.9 Fig. 36 shows an example for showing the unit function modules and the functions of the unit function modules included in the entity.

As shown in FIG. 36, the predetermined entity 110 includes a plurality of unit function modules 111 that perform unique unit functions and a configuration information provider 112. In response to a request to provide configuration information from a requesting entity as another entity, the configuration information provider 112 must provide the configuration information of the predetermined entity 110. At this time, the configuration information may include information about the unit function module 111 included in the predetermined entity 110.

In addition, another entity may request the construction information provider 112 to subscribe to the construction information change event. Then, by determining whether the reservation request is legal, the construction information provider 112 allows or disallows the reservation. At this time, the configuration information change event may indicate an event message including a change in the configuration information of the predetermined entity 110 when the configuration information of the predetermined entity 110 is changed.

The configuration information change event can be provided in a push or pull manner. In the push mode, as long as the structure information of the predetermined entity 110 changes, the structure information provider 112 pushes the event message including the changed structure information to the request entity 114 subscribing to the event. In the pull mode, the requesting entity 114 subscribing to the event obtains the changed structure information of the predetermined entity 110 as required. When the requesting entity 114 requests to subscribe to the event, it reports to the construction information provider 112 whether to transmit the event message in a push mode or a pull mode. Therefore, it is set whether to transmit the event message in a push mode or a pull mode.

In addition to the structure information change event, there are also various types of events, such as the above-mentioned content conversion state event, structure information conversion event, and so on. In the following, the process of executing events between entities will be described.

FIG. 37 shows an example for illustrating the process of transferring events between two authenticated entities.

200780006766.9 As shown in Figure 37, there must be an entity with an event booker function and an entity with an event publishing function in order to execute the scheduled event. Hereinafter, an entity having an event subscriber function is referred to as an event subscription entity 117. An entity having an event publishing function is referred to as an event publishing entity 119. In addition, the event may have an event title. The event header is information used to indicate which event is in the content transmission state event, the structure information conversion event, and the like.

The event issuing entity 119 must have its own unique identifier. This is because the event issuing entity 119 can be distinguished from another event that executes an event having the same event title as the event executed by the event issuing entity 119. The unique identifier of the event publishing entity 119 may include a factor for indicating the source of the event message published by the event publishing entity 119.

In order to subscribe to a predetermined event, the event subscription entity 117 must request the event publishing entity 119 that publishes the predetermined event to subscribe to the event.

When a subscription to an event is requested, the event subscription entity 117 provides a unique identifier for allowing the event issuing entity 119 to identify the event subscription entity 117. In addition, the event subscription entity 117 must report to the event publishing entity 119 whether the event provided by the event publishing entity 119 is provided in a push mode or a pull mode. Therefore, it is set whether to provide the event in a push mode or a pull mode. At this time, in the push mode, as long as the event condition occurs, the event publishing entity 119 automatically pushes the event message including the corresponding information to the event subscription entity 117. On the other hand, in the pull mode, the event subscription entity 117 queries the event publishing entity 119 as needed and obtains the event message.

In addition, the event subscription entity 117 can provide the event publishing entity 119 with an event subscription ID, expiration information, a desired event information structure, and the like. The expiration information may indicate the expiration value of the reservation of the event. For example, the expiration information may include expiration data, a reservation period of an event, and the like. When the expiration information is not provided, there is no restriction on the reservation period.

200780006766.9 In response to the event reservation request, the event publishing entity 119 allows or disallows the reservation by determining whether the event reservation request is valid. At this time, according to the determination result, a response message including information indicating that the reservation is permitted and information indicating that the reservation is not permitted is transmitted to the event reservation entity 117.

In the determination, the event reservation ID, expiration information, etc. can be considered. For example, in a situation where the event subscription entity 117 provides an event subscription ID when a subscription to the event is requested, the event publishing entity 119 may consider whether the event subscription ID is valid and whether the event subscription ID has expired. At this time, when the event subscription ID provided by the event subscription entity 117 is invalid or expires, the event publishing entity 119 may transmit a message to the event subscription entity 117 indicating that subscription is not permitted. Alternatively, when the event reservation ID provided by the event reservation entity 117 is valid and has not expired, the reservation ID and information about the reservation ID may be used. On the other hand, in a situation where the event subscription entity 117 does not provide an event subscription ID when a subscription event is requested, the event publishing entity 119 can provide a new event subscription ID. On the other hand, the event subscription entity 117 can cancel the current event subscription. To this end, the event subscribing entity 117 may send a message indicating that the event is cancelled to the event publishing entity 119. In addition, by canceling the setting method of providing the event, the event subscription entity 117 can stop the event subscription. For example, in the currently selected method of providing the current event in a push or pull mode in order to book the event, the selection of the push and pull mode is cancelled.

So far, the method of constructing information and handling events between entities has been described. Through the above method, entities can interact with each other according to a specific state.

6. Method and sub-system for managing domains Hereinafter, a method and sub-system for managing domains capable of managing the movement of domain positions will be described. To this end, the current and previous positions of the domain can be stored and managed by using the domain manager of the management domain. In addition, the movement of the domain position can be restricted according to predetermined restrictions.

The DRM interoperating system manages information about the movement of the domain position. Specifically, DRM mutual

200780006766.9 The operating system restricts the movement position or number of the domain. When it is found that the domain is formed outside the restricted range by checking the location change of the domain, the DRM interoperating system destroys the domain or performs another action.

Hereinafter, a method of managing a domain capable of managing position movement information of the domain will be described. The embodiment of the method of managing domains to be described may include a method of restricting the number of movement of a domain, a method of restricting a formation position of a domain, and the like. For ease of understanding, the former is referred to as Example 4-1, and the latter is referred to as Example 4-2. In addition, the basis of the system of Examples 4-1 and 4-2 is shown in FIG. 2.

<Example 4->

FIG. 38 is a flowchart showing a method of managing a domain according to Example 4-1. FIG. 38 shows the process of setting the allowable number Na of movement of the domain corresponding to the login information, the number of movement of the check domain, and the formation of the restricted domain.

The domain manager 22 stores the allowable number Na of movement of the domain corresponding to the login information. The login information can be received from the license manager 24. Alternatively, the domain manager 22 may provide a login function. The allowable number of domain moves Na may depend on the fee paid by the user. The maximum number can be set by the service provider in terms of policy. The allowable number Na of the movement of the domain can be set to five, ten, etc. In addition, the domain manager 22 stores and manages the current and previous positions of the domain. When the domain moves, the domain manager 22 stores and manages the number of moves.

Referring to FIG. 38, the domain manager 22 checks the current location of the domain 5 (operation S140), and determines whether the domain is moved (operation S141). Specifically, it is determined whether the domain is moving by comparing the current position of the domain with the position of the domain obtained from the previous inspection. The determination may be performed every predetermined period of time. Alternatively, the determination may be performed when a new domain is formed. Optionally, the determination can be arbitrarily performed based on monitoring of the service provider.

The reference point controller 26 in domain 5 can participate in determining the location of domain 5. At this time, the reference point controller 26 may be a reference point regarding the formation position of the local domain. Reference point controller 26

200780006766.9 The first can be included in the reservation device of the reservation domain 5 in the local area. The reference point controller 26 reports information about the inside of the domain 5, for example, information about the location 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 participate in determining the position of the domain 5. Each device can provide information about its location in the domain by accessing 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 an optional factor based on the execution environment.

Therefore, the location of the domain 5 may indicate the location of the reference point controller 26 in the domain or the location of each device. On the other hand, by limiting the number of selected reference point controllers including the reference point controller 26 to a predetermined number, safety can be improved. In addition, the user can log in through the reference point controller 26.

The method of determining the location of the domain will be described below.

In the first method, the location of the domain can be determined by using the IP address of the reference point controller 26. In this case, the first method can be implemented in a model where a high-speed Internet provider assigns a fixed IP to it.

In the second method, the location of the domain can be determined by using the IP subnet address of the reference point controller 26. For example, when the subnet address is the same as the previously detected subnet address, it is considered that the domain has not moved. When the subnet address is changed and when the TTL is not within three hops, the domain is considered to have moved.

In the third method, when the domain enters the adjacent area of the reference point controller 26, the location of the domain is identified by using the media access control (MAC) address of the reference point controller 26. For example, when a set-top box regarded as a separate reference point controller by a high-speed Internet provider is installed in a home, the periphery of the set-top box is set as a domain. A device connected to the set-top box in a wired or wireless manner is recognized that the device enters a predetermined domain. Therefore, you can specify the devices

200780006766.9 position.

In the fourth method, the location of the domain can be determined by using the Global Positioning System (GPS).

In the fifth method, in the case of a mobile terminal such as a mobile phone, the location of the device in the domain can be determined by the base station.

On the other hand, when it is determined that the domain is moved, the domain manager 22 increases the previous number of movements of the domain by 1 (operation S142), and identifies the total number N of movements of the domain that has been increased so far (operation S143)_OAlternatively, when the domain does not move, the currently formed domain 5 is maintained (operation S147).

Subsequently, the domain manager 22 compares the current total number N of movements of the domain with the stored allowable number Na of movements of the domain (operation S144). When, as a result of the comparison, it is determined that the total number of movements of the domain N is equal to or less than the allowable number of movements of the domain Na, the domain manager 22 maintains the current domain 5 (operation S147). Alternatively, when the total number of movements of the domain N is greater than the domain When the allowed number of moves Na is, the domain manager 22 prohibits the use of the current domain (operation S145).

Then, the domain manager 22 records the service stop history regarding the current user (operation S146). Additionally, the domain manager reports information regarding the destruction of the domain to the service provider. The service provider or domain manager 22 may transmit a warning message to the user. In addition, the service provider or domain manager 22 persuades the user to purchase new domain login information through the customer payment system.

On the other hand, according to the service provider's strategy, the cumulative number of domain movements can be reset every other period. For example, the number of domain moves can be reset once a year.

<Example 4-2>

FIG. 39 is a flowchart showing a method of managing a domain according to Example 4-2. FIG. 39 shows the process of restricting the generation of domains by checking the formation positions of domains.

200780006766.9 First, the domain manager 22 stores the allowable number Ma of domain locations corresponding to the login information. The allowable number of domain locations Ma may depend on the fee paid by the user. The maximum number can be set by the service provider in terms of policy. The allowable number of domain positions Ma can be set to five, eight, etc. In addition, the domain manager 22 stores and manages the current and previous positions of the domain.

Referring to FIG. 39, the domain manager 22 checks the current position of the domain 5 (operation S150), and determines whether the domain is moved (operation S151). Specifically, it is determined by comparing the current position of the domain with the domain position obtained from the previous check Whether the domain is moved. The determination may be performed every predetermined period of time. Optionally, the determination may be performed when a new domain is formed. Optionally, the determination can be arbitrarily performed based on monitoring 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 by using the IP address, IP subnet address, MAC information, GPS, mobile communication information, etc. of the reference point controller 26.

When it is determined that the domain has not moved, the domain manager 22 maintains the current domain 5 (operation S158). On the other hand, when it is determined that the domain is moved, the domain manager 22 performs the process by comparing the current position of the domain 5 with the stored previous position of the domain. Compare to determine whether the current position of the domain is a new position (operation S152). When it is determined that the current position of the domain is not a new position, the domain manager 22 maintains the current domain 5 (operation S158). On the other hand, when the current position of the domain is When the location is a new location, the domain manager 22 stores the current location of the domain (operation S153). Subsequently, the domain manager 22 obtains the total number M of domain formation locations including the current location of the domain 5 (operation S154), and transfers the obtained The number M of domain positions is compared with the predetermined allowable number of domain positions Ma (operation S155). As a result of the comparison, when it is determined that the total number of domain formation positions M is equal to or less than the allowable number of domain positions Ma, the domain manager 22 maintains the current domain 5 ( Operation S156) o Alternatively, when the total number M of domain formation positions is greater than the allowable number Ma of domain positions, the domain manager 22 destroys the current domain 5 (operation S157).

200780006766.9 Next, the domain manager 22 records the service stop history of the current user. Additionally, the domain manager reports information about the destruction of the domain to the service provider. The service provider or domain manager 22 may transmit 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 formation position of the domain. For example, when the service provider allows four domains to form positions, the domain manager 22 automatically memorizes the four positions of the domain from the first position of the domain, and determines whether the subsequent formation positions of the domain deviate from the allowed four positions. When the domain is formed only at the memorized position, although the domain frequently moves, the movement of the domain is not restricted. Alternatively, when the domain is moved to another place other than the four memory locations, the domain manager 22 restricts the formation of the domain.

On the other hand, in a situation where the user's action range is completely changed, for example, when the user moves to a new home, when the location of the domain does not match the previous location of the domain, it is necessary to form a position based on the domain that was first remembered by the domain manager 22. Move the location outside to the new storage domain to form the location. In this case, the information on the formation position of the domain may be newly reset in response to a specific request of the user.

In addition, the information about the location where the domain is formed can be reset through the policy of the service provider. In this case, the number of resets can be limited. For example, the number of resets of the information on the formation position of the domain may be limited to once or twice a year. On the other hand, in addition to the change of the IP address, it is also possible to limit the change of the information on the formation location of the domain by using the service reservation content and the service login information.

So far, the method for managing domains capable of storing and managing the current and previous positions of the domains and restricting the number of movement of the domains based on predetermined restrictions has been described.

7. The structure, operation and scheme used to prevent content misuse and pollution. When unreliable content (such as inappropriate content or contaminated content, etc.) is introduced

200780006766.9 When sharing content between different types of DRM through the DRM interoperating system, users or systems may suffer harm. There is a need for a system and solution that can deal with the injuries.

Hereinafter, a method of processing content by using the DRM interoperating system will be described, in which appropriate actions can be prepared by checking whether the externally introduced content is misused, contaminated, and applying security functions.

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

As shown in FIG. 40, the DRM interoperating system 340 provides a DRM interoperability function to make predetermined DRM regions (for example, the first and second DRM regions 320 and 330) compatible with each other. In FIG. 34, a situation is described in which two DRM areas are compatible with each other by using the DRM interoperating system. The present invention is not limited to this. By using the DRM interoperating system, three or more DRM areas can be compatible with each other.

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

The first DRM area 320 may include the first DRM system 323. The first DRM system 323 is used to generate the first DRM content and a first license, the first license being for using the first DRM content by applying the first DRM to the source content provided by the first content provider 322 And provide the first client device 210 with the generated first DRM content and the first license. At this time, the first client device 210 may represent a device in which the first DRM is installed. Therefore, the first client device 210 can use the first DRM content within the permission range allowed by the first license. In FIG. 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 the same as the first service provider 322. Alternatively, the first content provider 325 may be included in the first service provider 322.

200780006766.9 The first DRM system 323 can interact with the first security system 325. The first security system 324 is used to apply security functions to the first DRM content. For example, the system may be a fingerprint recognition system that provides a tracking function for tracking users who use content, a watermark system for protecting the copyright of authors, an antivirus system for checking and repairing virus-contaminated content, and a system for preventing Misuse prevention system or intrusion detection system (IDS) for the possibility of content misuse.

The second DRM area 330 uses a DRMo different from the DRM of the first DRM area 320 described above, that is, the second DRM area 330 may represent a DRM protected area including a system or device that uses the second DRM adopted by the second service provider 332.

The second DRM area 330 may include the second DRM system 333. The second DRM system 333 is used to generate second DRM content and a second license, the second license being used to use the second DRM content by applying the second DRM to the source content provided by the second content provider 335 And provide the second client device 331 with the generated second DRM content and the second license. At this time, the second client device 331 may indicate a device in which the second DRM is installed. Therefore, the second client device 331 can use the second DRM content within the permission range permitted by the second license. In FIG. 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 the same as 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 can interact with the second security system 334. The second security system 333 is a system for applying security functions to the second DRM content. For example, the system may be a watermarking system, a fingerprint identification system, an antivirus system, an anti-misuse system, or an IDS.

FIG. 41 is a block diagram showing the detailed structure of the DRM area. The structure of the DRM area shown in FIG. 41 may be commonly applied to the structure of the first or second DRM area 320 or 330 shown in FIG. 40.

Referring to FIG. 41, the content provider 380 sends a predetermined security function (such as watermark) to the

The 200780006766.9 No. DRM system 371 provides content or content with original data types.

The DRM server 372 of the DRM system 371 encrypts the provided content by using an encryption module, and transmits the key value used to encrypt the content and license information together with the encrypted content to the client device 360=can be licensed The license server 375 provides license information. The client DRM module 361 of the client device 360 that receives the encrypted content restores the encrypted content by decrypting the encrypted content.

In addition, fingerprint identification information may be inserted into the content to be transmitted to the client device 360. The insertion of the fingerprint identification information is performed by the fingerprint identification system 376 included in the service provider 370. The fingerprint recognition system 376 may include a fingerprint recognition code generator 377, a checker 378, a fingerprint recognition engine 379, and the like. The fingerprint identification information for identifying the user of the client device 360 may be inserted into the content to be transmitted to the client device 360. The insertion of the fingerprint identification information can be performed by the fingerprint identification engine included in the client device 360.

In FIG. 41, an example in which a fingerprint recognition function is applied to content is shown. However, the security function that can be applied to the content may be the above-mentioned watermark function, anti-misuse function, or IDS function.

As shown in Figures 40 and 41, security systems (such as fingerprint recognition systems, watermark systems, anti-virus systems, anti-misuse systems, IDS, etc.) for applying security functions to the content can be installed in the DRM area. Shangzhong. Alternatively, the security system may be included in the DRM interoperating system.

Fig. 42 is a block diagram showing the structure of the DRM interoperating system. FIG. 42 shows a situation in which the DRM interoperating system includes a function of ensuring the reliability of externally introduced content.

As shown in Figure 42, the DRM interoperating system may also include a security system 9 and content

200780006766.9 Part 8 of Reliability Management. As described above, the security system 9 may represent a fingerprint identification system, a watermark system, an antivirus system, an anti-misuse system, or an IDS. The security system 9 may be included in the DRM interoperating system 500. Alternatively, the DRM interoperating system 500 may interact with another security system.

The content reliability management section 8 can interact with an external local DRM area, and includes various procedures for ensuring content reliability. When the content is requested from the outside, the process of the content reliability management section 8 can be automatically executed. Alternatively, the process may be executed in response to a request of the processing control section. The process of the content reliability management section 8 will be described according to the following scheme.

Hereinafter, a scheme in which the reliability of the content can be ensured when the content is transferred in the DRM interoperability environment will be described. At this time, in the DRM interoperability environment, content can be transferred from the predetermined DRM area to the target DRM area via the DRM interoperating system.

First, in the following description, a solution that can apply an anti-misuse strategy when DRM content is transferred, a solution that can prevent the spread of virus-infected content when DRM is allowed to be compatible with another DRM, and a solution that can prevent the spread of virus-infected content when DRM is allowed to be compatible with another DRM are sequentially described. A solution capable of applying the watermark function when DRM is compatible, another solution capable of applying the watermark function when allowing DRM to be compatible with another DRM, a solution capable of applying fingerprint recognition function when allowing DRM to be compatible with another DRM, when allowing DRM to be compatible with another DRM Another solution that can apply the fingerprint recognition function when the other DRM is compatible and the processing solution used when a user whose fingerprint recognition information does not match the stored information requests to transmit content. For ease of understanding, the first scheme is referred to as Example 5-1. The second scenario is referred to as Example 5-2. The third scenario is referred to as Example 5-3. The fourth scenario will be referred to as Example 5-4. The fifth scenario will be referred to as Example 5-5. Call the sixth scenario Example 5-6o Call the seventh scenario Example 5-7₀ <Example 5-1>

FIG. 43 is a functional block diagram showing a method of processing content by using a DRM interoperating system according to Example 5-1. Figure 43 shows when transmitting in the DRM interoperability environment

200780006766.9 No.

DRM content can apply the process of preventing content misuse strategy.

The anti-misuse strategy is designed to prevent situations in which DRM content is incorrectly used. For example, the misuse prevention strategy may include a strategy that prevents young children from watching adult content that cannot be used by users under 19 years old in advance.

As shown in FIG. 43, the DRM interoperating system 500 receives a content request requesting to transmit predetermined content from the first client device 410 included in the first DRM area to the second client device 610 included in the second DRM area 600 Message (operation S170). The content transmission request message may include content requested to be transmitted, information about a transmitter that transmits the content, information about a receiver that receives the content, and the like. At this time, because the requested content is transmitted from the first client device 410 included in the first DRM area 400, the requested content may represent the content to which the first DRM is applied.

When receiving a request to transmit content, the DRM interoperating system 500 extracts sender information and receiver information from the received content transmission request message (operation S171). Subsequently, the DRM interoperating system 500 requests the reservation of the first DRM area 400 The entity provides transmission user information corresponding to the extracted transmitter information (operation S172), and requests a predetermined entity of the second DRM area 600 to provide receiving user information corresponding to the receiver information (operation S173).

At this time, the predetermined entity of the first DRM area 400 may be the first service provider 420. The predetermined entity of the second DRM area 600 may be the second service provider 620. Then, the first and second service providers 420 and 620 provide the DRM interoperating system 500 with transmission user information and receiving user information in response to the request (operations S174 and S175). 620 and 620 communicate requests and responses to transmit user information and receive user information.

The transmitting user information may represent information about the user of the first client device 410 that transmits the content. In addition, the receiving user information may indicate the first information about receiving the content.

200780006766.9 Information of the user of the second client device 610. The transmitted user information and the received user information include predetermined information about the user, which is a determination criterion for applying a content misuse prevention strategy, for example, information about the age of the user.

Subsequently, the DRM interoperating system 500 may request a predetermined entity (for example, the first service provider 420) of the first DRM area 400 to provide content information (operation S176). The first service provider 420 provides the content information in response to the request ( Operation S177) ο At this time, the content information may include restriction information for preventing misuse of the content. For example, the content information may include information about age restrictions of users who can use the content.

Then, the DRM interoperating system 500 determines the possibility of content misuse by comparing and analyzing content information and transmitting and receiving user information (operation S178), and reports to the first client device 410 whether the content will be transmitted according to the determination result To the second client device 610 (operation 179). In addition, the DRM interoperating system 500 may report to the second client device 610 whether to transmit the content. The possibility of content misuse is determined through the DRM interoperating system 500 or an external misuse prevention system.

For example, when the age restriction information included in the content information indicates that users under 19 years of age are not allowed and when the age of the transmitting user is 15 years old, the DRM interoperating system 500 determines that the requested content may be misused , The report indicates a message that the content cannot be delivered to the first client device 410, and the process is stopped.

On the other hand, when the age of the receiving and transmitting user is 24 years old, the DRM interoperating system 500 determines that it is impossible to misuse the requested content and reports a message indicating that the content is normally transferred to the first client device 410. After reporting the normal transmission, the DRM interoperating system 500 converts the license information and the data protection technology applied to the requested content from the first DRM to the second DRM (operation S180), and transmits to the second client device 610 Conversion result (operation S181) ο through a DRM provider (not shown) related to the DRM interoperating system 500, and

200780006766.9 The meeting or approval of the first service providers 420 and 620 can determine and accept the content prevention misuse strategy. In addition, the communication message between the first DRM area 400, the DRM interoperating system 500, and the second DRM area 600 may be communicated in the format of Extensible Markup Language (XML), Hypertext Markup Language (HTML), or general data. When performing communication, a secure channel with Advanced Encryption Standard (AES) 128 bits or more can be provided.

<Example 5-2>

FIG. 44 is a functional block diagram showing a method of processing content by using the DRM interoperating system according to Example 5-2. FIG. 44 shows a process of preventing the spread of virus-contaminated content when the DRM is allowed to be compatible with another DRM.

As shown in FIG. 44, the DRM interoperating system 500 receives a content transmission request message requesting transmission of predetermined content from the first client device 410 to the second client device 610 (operation S190). The content transmission request message includes the content requested to be transmitted. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content represents the content to which the first DRM is applied.

When receiving the content transmission request message, the DRM interoperating system 500 determines whether the content is contaminated by analyzing the requested content (operation S192). According to the determination result, the DRM interoperating system 500 determines whether to transfer the content to the second client device 610 and reports the determination result to the first client device 410 (operation S193). At this time, the DRM interoperating system 500 may also report The second client device 610 reports the determination result.

For example, the DRM interoperating system 500 performs a virus check on the requested content. When the content is contaminated by a virus, the DRM interoperating system 500 determines that the content cannot be delivered, reports a message indicating the determination result to the first client device 410, and stops the process. In this case, the first client device 410 or the first service provider 420 can clean the virus from the content. Subsequently, the first client device 410 requests the DRM interoperating system 500 to retransmit the content.

200780006766.9 Alternatively, when the requested content is not contaminated by a virus, the DRM interoperating system 500 determines that the content is normally transferred and reports a message indicating the determination result to the first client device 410.

Subsequently, the DRM interoperating system 500 performs DRM conversion, in which the license information and the data protection technology applied to the requested content are converted from the first DRM to the second DRM (operation S193), and transmitted to the second client device 610 Conversion result (operation S194)_O On the other hand, the DRM interoperating system 500 determines the possibility of content contamination. When the content is contaminated, the DRM interoperating system can remove viruses from the content and transfer the content normally. In this case, the DRM interoperating system 500 may include tools or systems capable of removing viruses from the content, or request a separate antivirus system connected via a network to remove viruses from the content. In addition, a detailed description of the virus contaminating the content and the removal result may be reported to the first client device 410.

<Example 5-3>

FIG. 45 is a functional block diagram showing a method of processing content by using the DRM interoperating system according to Example 5-3. FIG. 45 shows an example in which the watermark function can be applied when the DRM is allowed to be compatible with another DRM.

As shown in FIG. 45, the DRM interoperating system 500 receives a content transmission request message requesting transmission of predetermined content from the first client device 410 to the second client device 610 (operation S190). The content transfer request message includes the content requested to be transferred. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content represents the content to which the first DRM is applied.

When receiving the content transmission request message, the DRM interoperating system 500 determines whether to insert a watermark into the content by analyzing the content requested to be transmitted (operation S196). When the watermark is inserted into the content, DRM interoperates The system 500 performs a DRM conversion process in which the license information and the data protection technology applied to the requested content are changed from the first

200780006766.9 No.

The DRM is converted to the second DRM (operation S201), and the conversion result is transmitted to the second client device 610 (operation S202). Alternatively, when the watermark is not inserted into the requested content, the DRM interoperating system 500 requests A predetermined entity (for example, the first service provider 420) of the first DRM area 400 performs the watermarking process (operation S197). Specifically, it is requested to insert a watermark into the content requested to be transmitted. Then, the first service provider 420 requested to perform the watermarking process inserts the watermark into the content requested to be transmitted (operation S198), and requests the DRM interoperating system 500 to transmit the content again (operation S199).

The DRM interoperating system 500 checks whether a watermark is inserted into the requested content (operation S200), and performs a DRM conversion process in which the license information and the data protection technology applied to the requested content are converted from the first DRM to the second DRM (operation S201), and transmit the conversion result to the second client device 610 (operation S202). On the other hand, when the engine for providing the watermark function is installed in the first client device 410, the DRM interoperating system 500 may request the first client device 410 to perform the watermarking process. At this time, the first client device 410 may request the first service provider 420 or the content provider to provide copyright information for generating the watermark, and can obtain the copyright information.

So far, the process of inserting a watermark when the DRM is allowed to be compatible with another DRM has been described with reference to FIG. 45. In order to implement the process shown in FIG. 45, a watermarking system for providing a watermarking function must be included in a predetermined entity of the first DRM area 400. Alternatively, when the watermarking system is not included in the predetermined entity of the first DRM area 400, the DRM interoperating system 500 may perform the watermarking process or request a separate watermarking system to perform the watermarking process. These situations will be described below with reference to FIG. 46.

<Example 5-4>

FIG. 46 is a diagram showing processing by using the DRM interoperating system according to Example 5-4

200780006766.9 The functional block diagram of the method of the content. FIG. 46 shows another example in which the watermark function can be applied when the DRM is allowed to be compatible with another DRM.

As shown in FIG. 46, the DRM interoperating system 500 receives a content transmission request message requesting transmission of predetermined content from the first client device 410 to the second client device 610 (operation S210). The content transfer request message includes the content requested to be transferred. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content represents the content to which the first DRM is applied.

When receiving the content transmission request message, the DRM interoperating system 500 determines whether to insert the watermark into the requested content (operation S211). When the watermark is inserted into the content, the DRM interoperating system 500 performs the DRM conversion process, The license information and the data protection technology applied to the requested content are converted from the first DRM to the second DRM (operation S215), and the conversion result is transmitted to the second client device 610 (operation S216).

Alternatively, when the watermark is not inserted into the requested content, the DRM interoperating system 500 requests a predetermined entity of the first DRM area 400 (for example, the first service provider 420) to provide copyright ownership of the requested content Owner's Information (Operation S212)-Specifically, the information about the copyright owner may be the information about the content provider. In this case, the DRM interoperating system 500 may request the first service provider 420 to provide information about the copyright owner. Alternatively, the DRM interoperating system 500 may directly request the content provider to provide information about the copyright owner. In Example 5-4, it is assumed that the first service provider 420 provides information about the copyright owner. However, the present invention is not limited to this.

The first service provider 420 provides the DRM interoperating system 500 with information about the copyright owner in response to the request for the information about the copyright owner transmitted from the DRM interoperating system 500 (operation S213). Then, the DRM interoperating system 500 passes Use the information about the copyright owner provided by the DRM interoperating system 500 to generate a watermark, decrypt the content requested for transmission, and perform a watermarking process in which the generated watermark is inserted into the content (operation S214). When the DRM interoperating system 500 can include a watermarking system

200780006766.9 First and use the watermarking system. Alternatively, the DRM interoperating system 500 may directly request a separate watermarking system connected through a network to perform the watermarking process.

When the watermark process is completed, the DRM interoperating system 500 performs a DRM conversion process (operation S215). Specifically, the license information and the data protection technology applied to the content into which the watermark is inserted are converted into the second DRM as the target DRM. Subsequently, the DRM interoperating system 500 transmits the converted content to the second client device 610 (operation S216).

On the other hand, the DRM interoperating system 500 may enable the watermarking process to be performed by providing the first client device 410 with information about the address (for example, URL address) of the separate watermarking system. In this case, the first client device 410 may directly request the first service provider 420 or the content provider to provide information about the copyright required for the watermarking process. Alternatively, the DRM interoperating system 500 may provide the first client device 410 with information about the copyright provided by the first service provider 420 together with the URL address. In addition, the DRM interoperating system 500 may enable the watermarking process to be performed by providing the URL address of a separate watermarking system to the first service provider 420 or the content provider of the first DRM area 400.

<Example 5-5>

FIG. 47 is a functional block diagram showing a method of processing content by using the DRM interoperating system according to Example 5-5. FIG. 47 shows an example in which the fingerprint recognition function can be applied when the DRM is allowed to be compatible with another DRM.

As shown in FIG. 47, the DRM interoperating system 500 receives a content transmission request message requesting transmission of predetermined content from the first client device 410 to the second client device 610 (operation S221). The content transfer request message includes the content requested to be transferred. Since the requested content is transmitted from the first client device 410 included in the first -DRM area 400, the content represents the content to which the first DRM is applied.

When receiving the content transmission request message, the DRM interoperating system 500 is requested through analysis

200780006766.9 It is determined whether to insert the fingerprint including the user information of the first client device 410 into the content according to the transmitted content (operation S222) ₀The determination process may be performed immediately after receiving the content transmission request or immediately before performing the DRM conversion.

When it is determined that the fingerprint is normally inserted into the content, the DRM interoperating system 500 performs a DRM conversion process in which the license information and the data protection technology applied to the requested content are converted from the first DRM to the second DRM (operation S227), and transmit the conversion result to the second client device 610 (operation S228). Alternatively, when it is determined not to insert the fingerprint into the content requested to be transmitted, the DRM interoperating system 500 requests the first client device 410 Perform a fingerprint recognition process (operation S223). Specifically, a fingerprint including user information of the first client device 410 is requested to be inserted into the content requested to be transferred.

At this time, the DRM interoperating system can provide the first client device 410 with a pair of URLs, for example, through a URL trigger or an anti-channel, to provide the address information required by the fingerprint recognition engine for performing the fingerprint recognition process. Because fingerprint recognition algorithms are significantly different, the DRM interoperating system 500 may not store and manage all fingerprint recognition algorithms. Therefore, the DRM interoperating system 500 must provide the first client device 410 with an address of a fingerprint recognition system that can download a fingerprint recognition engine with an algorithm used in the first DRM area 400. The address of the fingerprint identification system can be obtained by communicating the request and response between the DRM interoperating system 500 and the first service provider 420.

The fingerprint identification system may be included in the first service provider 420. Alternatively, the fingerprint identification system may be a predetermined server that interacts with the service provider 420. However, when the fingerprint recognition function is not included in the first DRM area 400, the first service provider 420 cannot provide the fingerprint recognition function. In this case, the DRM interoperating system 500 may provide the first client device with address information of a separate fingerprint recognition system capable of providing a fingerprint recognition engine. In addition, when a predetermined fingerprint recognition engine is installed in the first client device 410, the DRM interoperating system 500 may not transmit additional address information and request

100

200780006766.9 The first client device 410 executes the fingerprint identification process through the installed fingerprint identification engine.

The first client device 410 requested to perform the fingerprint recognition process may perform the fingerprint recognition process by downloading the fingerprint recognition engine using the address information received from the DRM interoperating system 500, or perform fingerprint recognition by using the installed fingerprint recognition engine Process (operation S224) ο Specifically, the fingerprint including user information is inserted into the requested content.

Subsequently, the first client device 410 again requests the DRM interoperating system 500 to transfer the content in which the fingerprint is inserted to the second client device 610 (operation S225). Then, the DRM interoperating system 500 checks whether the fingerprint is inserted into the requested (Operation S226), a DRM conversion process is performed, in which the license information and the data protection technology applied to the requested content are converted from the first DRM to the second DRM (operation S227), and the second client device 610 Transmit the conversion result (operation S228) ο On the other hand, although not shown, the DRM interoperating system 500 may request the second client device 610 receiving the content to perform a fingerprint recognition process. In this case, the DRM interoperating system 500 may provide the second client device 610 with address information of a fingerprint recognition system capable of performing a fingerprint recognition process. At this time, the address information of the fingerprint identification system can be obtained by communicating the request and response between the DRM interoperating system 500 and the second service provider 610. In addition, when the second service provider 610 does not include a fingerprint recognition function, the DRM interoperating system 500 may provide the address of a separate fingerprint recognition system.

<Example 5-6>

FIG. 48 is a functional block diagram showing a method of processing content by using the DRM interoperating system according to Example 5-6. FIG. 48 shows another example in which the fingerprint recognition function can be applied when the DRM is allowed to be compatible with another DRM. In Example 5-6, the DRM interoperating system includes a fingerprint recognition engine.

As shown in FIG. 48, the DRM interoperating system 500 receives a request from the first client device

101

200780006766.9 No.

410 transmits a content transmission request message of predetermined content to the second client device 610 (operation S230). The content transmission request message includes the content requested to be transmitted. Since the requested content is transmitted from the first client device 410 included in the first DRM area 400, the content represents the content to which the first DRM is applied. The received content transmission request message includes transmission and reception user information, that is, user information of the first and second client devices 410 and 610.

Subsequently, the DRM interoperating system 500 determines whether to insert the fingerprint including the user information of the first client device 410 into the content by analyzing the content requested for transmission (operation S231). When the fingerprint is inserted into the requested transmission When the content is in, the DRM interoperating system 500 performs a DRM conversion process, in which the license information and the data protection technology applied to the requested content are converted from the first DRM to the second DRM (operation S233), and to the second DRM The client device 610 transmits the conversion result (operation S234).

Alternatively, when the fingerprint is not inserted into the content requested to be transferred, the DRM interoperating system 500 generates a user including the received first client device 410 by using the fingerprint engine included in the DRM interoperating system 500 The fingerprint of the information, encrypt the content requested to be transmitted, and perform a fingerprint identification process, in which the generated fingerprint is inserted into the content (operation S232) ₀The fingerprint recognition engine is stored in a predetermined device in the DRM interoperating system 500 in the form of a cache. When the fingerprint recognition process is performed, the fingerprint recognition engine can be operated.

When the fingerprint recognition process (operation S232) is completed, the DRM interoperating system 500 executes the DRM conversion process (operation S233).

Specifically, the license information and the fingerprint insertion is applied to the contents of the second data protection technology into a target DRM DRMo Subsequently, the DRM interoperable system 500 of the content the client device 610 transmits the converted two (operation S234).

On the other hand, the DRM interoperating system 500 may include the second

102

200780006766.9 The fingerprint of the information of the client device 610 is inserted into the content. In this case, the DRM interoperating system 500 must store the corresponding fingerprint recognition engine in the form of a cache.

<Example 5-7>

FIG. 49 is a functional block diagram showing a method of processing content by using the DRM interoperating system according to Examples 5-7. FIG. 49 shows a process of reporting that the fingerprint information of the content does not match the user information to a system that includes or distributes the content when a user whose fingerprint information does not match the user information requests to transmit content.

As shown in FIG. 49, the DRM interoperating system 500 receives a content transmission request message requesting transmission of predetermined content from the first client device 410 to the second client device 610 (operation

5250). The content transmission request message includes transmitting and receiving user information, that is, user information of the first and second client devices 410 and 610. In addition, the fingerprint is inserted into the content requested to be transmitted.

The DRM interoperating system 500 compares and analyzes the user information included in the fingerprint information inserted into the content requested to be transmitted with the user information of the first client device 410 (operation

5251) ο When an error in which the user information included in the fingerprint does not match the user information of the first client device 410 is found (operation S252), the DRM interoperating system 500 reports the occurrence of an error to the first client device (operation S254) ). In addition, the DRM interoperating system 500 transmits a disagreement indicating that content sharing is not approved to the second client device 610 (operation S253). Therefore, illegal content whose fingerprints do not match the user information of the first client device 410 cannot be transmitted.

Although the present invention has been specifically shown and described with reference to its exemplary embodiments, those skilled in the art should understand that without departing from the spirit and scope of the present invention as defined by the appended claims, Various changes were made in form and details.

As described above, according to the embodiments of the present invention, by providing various operation schemes related to the reference point controller, the domain can be effectively operated. Specifically, by introducing reference point control

103

200780006766.9 The concept of the first candidate, when an error occurs, the error can be handled quickly. In addition, by introducing the concept of reference point controller agent, the flexibility of the domain can be improved.

104

200780006766.9