KR20080035433A - Method for connecting between entities by pointing and drm domain system - Google Patents

Abstract

A method for making a connection among entities via pointing and a DRM domain system are provided to manage connection relationships systematically among entities even though plural license servers and one domain server exist when providing a DRM mutual service. A method for making a connection among entities via pointing comprises the following several steps. A license server receives a credential from a client at the client's request for authentication, and checks effectiveness of the credential(S1). If there is no problem in the effectiveness, the license server generates an authentication token via the received credential, generates a license account by using the authentication token, and stores the generated license account(S2). The license server receives pointing information which can connect the license account to other entities(S3). Then, the license server points the license account according to the license information(S4). The license server checks the license account and its related domain account(S5). The license server provides various services requested by the client(S6).

Description

Method for Connecting Between Entities by Pointing and DRM Domain System}

1 is a block diagram showing the configuration of a DRM domain system.

2 is an exemplary diagram for explaining a process of creating a license account and a domain account of a client.

FIG. 3 is an exemplary diagram illustrating an association between a client, a domain server, and a license server when there are two domain servers but one license server.

FIG. 4 is an exemplary diagram illustrating a form in which a subscription server is added in the case shown in FIG. 3.

5 is a block diagram showing the configuration of license information generated and managed by a license server.

FIG. 6 is an exemplary diagram for describing a concept of mapping distribution usage included in service notification information.

7 is an exemplary diagram for explaining a pointing relationship between a license server, a domain server, and a subscription server.

FIG. 8 is an exemplary diagram for explaining how pointing may be performed when multiple license servers exist.

9 is an exemplary diagram illustrating an example of defining a compatibility function of a license server for compatibility between DRMs.

FIG. 10 is an exemplary diagram for explaining an example of pointing from a domain account to a license account as opposed to the example shown in FIG. 8.

11 is an exemplary view for explaining how the pointing information is provided from the license server or the domain server.

12 is a flowchart illustrating an operation of a license server that provides a service based on pointing information.

<Description of the symbols for the detailed parts of the drawings>

LS: License Server

DS: Domain Server

C, C1, C2, C3: Client

The present invention relates to a method for linking entities and a DRM domain system through pointing. More specifically, a method for systematically designating and linking a relationship between entities through pointing information in a domain service and a method thereof The present invention relates to a DRM domain system capable of realizing this.

In recent years, as the digitization of information is accelerated, the copyright problem of digital content has emerged. Unlike analog content, digital content can be easily copied without illegal information, and thus is easily exposed to illegal copying and illegal use. Therefore, for the service of digital content, a technology capable of stably protecting digital content from illegal copying and use must be supported.

Digital Rights Management (DRM) is a comprehensive digital content protection technology that prevents illegal copying and use of digital content and ensures that only authorized users can use the digital content. This DRM provides a comprehensive framework for the distribution of digital content. For example, DRM uses encryption technology to convert digital content into encrypted data in the form of packages, and the content cannot be used without legitimate authentication.

Such DRM has been linked with various content service models and has become the foundation of stable and legal content service. In fact, current content service providers adopt their own DRM to protect the content they serve. For example, a music service that provides sound sources online provides sound sources encrypted with a specific encryption pattern to prevent illegal duplication. Such sound sources can be played only by applications provided by the service provider. have. Therefore, the user may purchase a sound source from a specific service provider and then play the sound source using a device on which an application provided from the service provider is installed, such as a PC or a mobile phone, such as an MP3 player.

However, since the DRM has a very closed technical or policy characteristic, the DRM is generally not compatible with each other. For this reason, the DRM content service is far superior to the general content service in terms of stability and legitimacy, but has a very limited problem for the user consuming the content. This problem acts as a factor that hinders the flexibility of the digital content distribution structure, and as a result, it is preventing the activation of the content market.

Accordingly, recently, a DRM system that allows devices within the same DRM framework to freely share and use content, or a DRM interoperable system that provides an interoperable framework for interoperability between different closed DRMs is proposed. It is becoming.

These systems commonly introduce the concept of Domain as the basic unit of the DRM Trusted Framework. A domain may mean a collection of authorized devices or software systems. Through a set of legitimate procedures, domain-certified devices or software systems (hereinafter referred to as devices) can share and use freely the same DRM or different DRM-applied content.

Hereinafter, a DRM system or a DRM interoperable system constituting such a domain will be collectively referred to as a DRM domain system. The DRM domain system can be configured by defining the functions of each entity based on the physical interworking environment of the entities constituting the domain and properly linking the entities.

Since such a DRM domain system is often associated with a large number of providers, the association between entities may be complicated. Therefore, there is an urgent need for a method that can systematically handle the association between such complex entities.

SUMMARY OF THE INVENTION The present invention has been made in this background, and an object of the present invention is to provide a method for linking between entities and a DRM domain system through pointing, which can systematically link a plurality of entities according to the pointing information.

In order to achieve this object, the present invention provides a method for linking between individuals through pointing in one aspect. An association method between entities through pointing includes: generating an account using information of a credential received from a client; And if pointing information for pointing to the created account is provided from the client, pointing and associating the account with a specific entity according to the provided pointing information.

The generating of the account may include generating an authentication token through a credential received from the client; And generating the account using the generated authentication token.

The creating account may mean a license account. In this case, the linking step may include linking the license account to a domain account of a specific domain server according to the pointing information.

The license account defines license information, the license information including authentication and management information including information related to authorization and granting of a license to the license account; Pointing information indicating which domain server the license information is pointing to; Service recipient information indicating whose license the license information is defined for; Service seed information defining a target serviced by the license information; And service notice information defining a restriction on use of the target defined in the service seed information.

On the other hand, the created account may mean a domain account. In this case, the associating step may include associating the domain account with at least one client in the domain according to the pointing information. In this case, the association method between the entities through the pointing, if the domain service for the associated specific client is stopped, deleting the pointing information to the client, the domain service is stopped; And storing information of the client from which the pointing information is deleted. On the other hand, the associating step may include associating the domain account with a license account stored in at least one license server according to the pointing information.

The creating account may mean a subscription account. In this case, the linking step may include linking the subscription account to at least one of a license server, a domain server, and a client according to the point information.

Meanwhile, in order to achieve the above object, the present invention provides a DRM domain system in another aspect. The DRM domain system may form a domain to provide a service. Such a DRM domain system includes a client authenticated to the domain; And a plurality of accounts for creating an account by using the credentials of information received from the client, receiving pointing information for pointing the account from the client, and pointing and associating the account with a specific entity according to the provided pointing information. Can contain managed objects.

In this case, the plurality of management entities may include at least two or more of a license server, a domain server, and a subscription server. The client may also include the pointing information in the credential and provide it to the management entity.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. In the preferred embodiment of the present invention described below, specific technical terms are used for clarity of content. However, the invention is not limited to the particular term selected, and it is to be understood that each specific term includes all technical synonyms that operate in a similar manner to achieve a similar purpose.

FIG. 1 is a block diagram illustrating a configuration of a DRM domain system, and exemplarily illustrates a domain, basic entities for configuring the domain, and an association relationship between the entities.

First, the domain system to which the present invention is applied may be a DRM system or a DRM interoperable system. The DRM domain system mentioned below is described as an example of being a DRM interoperable system. But that's not limiting.

As shown in FIG. 1, the DRM domain system basically includes entities such as the client 10, the domain manager 30, and the license manager 40. In this case, the entity may mean a network node, for example, a device or a software system that performs a specific function. Each object can be organically linked with other objects through a specific interface.

This DRM domain system forms the domain 1 as a basic unit of the DRM trust system. The domain 1 is a set of authorized devices or software systems (hereinafter, referred to as 'devices or software systems' as 'devices') and may mean, for example, a set of clients 10. Such a domain may be an area in which a license for an account or content of a user or device is defined, or may be viewed as a service area provided by a service provider.

The domain 1 may be configured in consideration of the physical location of the client 10 or may be configured only with logically authenticated clients without considering the physical location of the client 10.

The client 10 is an entity that performs various functions so that a user can receive a content service through a DRM domain system. The client 10 may perform a function for requesting authentication to a domain, a function for using (playing) content, a request for transmitting content or a license to a specific destination, a user interface function, and the like. That is, the client 10 may be an entity that is an end point of consumption of content.

The client 10 may authenticate the domain 1 by requesting the domain manager 30 for authentication. The client 10 authenticated to the domain may be provided with the service of the DRM domain system according to the license information stored and managed by the license manager 40. For example, in the present description, since the DRM domain system is a DRM interoperable system, the same DRM content and different DRM content may be shared among the clients 10 belonging to the domain. Meanwhile, when the DRM domain system is a DRM system, the same DRM content may be shared among clients belonging to the domain.

The license manager 40 is an entity that generates, stores, and manages licenses for users or devices. In this case, the license may refer to information defining rights and contents of services and contents in the DRM domain system. In addition, the license manager 40 stores authentication information of the client 10 authorized to use the service, for example, a credential, an authentication token, and the like. On the other hand, the license manager 40 may provide a login function for a user and perform a function of a typical online service manager that stores and manages license information of the user.

The license manager 40 may include, for example, creating user names, deleting user names, associating license names with user names, and generating license information. Create License Information), Deleting License Information, etc.

The license manager 40 may be built on a license server operated by a service provider. However, the license manager 40 does not necessarily exist on the service provider side and may be provided in a module form in a device in the domain depending on the implementation environment.

The domain manager 30 is an entity that sets up a domain 1 in which the license defined by the license manager 40 can actually be realized. The domain manager 30 creates a domain 1 for a user or device and associates it with the domain 1. Stores parameters and manages the domain 1 as a whole.

The domain manager 30 may be, for example, creating a domain 1, destroying a domain 1, or associating the client 10 with the domain 1. Clients with a Domain, Removing Clients from a Domain, Registering Domain Reference Point, and so on.

The domain manager 30 may be built in a domain server operated by a service provider. However, the domain manager 30 is not necessarily present at the service provider side and may be provided in a module form in a device in the domain according to an implementation environment.

The above described entities can be used to construct various practical models of the DRM domain system. When constructing a practical model of the DRM domain system, it may further include various entities having specific functions as needed.

For example, the DRM domain system, although not shown, a reference point controller that helps the client 1 authenticate, and content that controls the transfer of content between devices in response to a request from the client 1. Content Mediator, Content Exporter that exports content from the source under the control of the content moderator, Content Transformer that transforms the content under the control of the content moderator, Under the control of the content moderator It may further include various entities performing specific unique functions such as a content importer for importing content to a destination, a license mediator for controlling the transfer of licenses in response to a request of the client 1, and the like. .

Meanwhile, in order for a user to use the service through his or her device, that is, a client, a license account defining rights for the content service (for example, a license to use the content, etc.) and a right defined in the license account In some cases, a domain account is required to enable services within a domain.

FIG. 2 is an exemplary diagram for describing a procedure of creating a client's license account and a domain account, and an example in which one license server (LS) and one domain server (DS) exist. Is showing.

As shown in FIG. 2, one license server LS and one domain server DS exist for the service to the client C. As shown in FIG.

The license server LS is a management entity having a license manager (40 in FIG. 1). The license server LS may have various functions such as a charging function, a subscription and authentication function, a license conversion function, a license token conversion function, and the like as well as a license manager function. The domain server DS is also a management entity having a domain manager (30 in FIG. 1). Thus, the domain server DS includes the function of the domain manager. The license server LS and the domain server DS may be operated by a service provider. In this case, the service provider operating the license server LS and the service provider operating the domain server DS may be different.

Client (C) must submit Credential for license authentication to License Server (DS). The credential includes encrypted information for identifying the client C and proving that the user is a legitimate user. These credentials can be the means of authentication required for management of licenses or domains.

After verifying the credentials submitted from the client C, the license server LS may generate an authentication token based on the verified credentials and drop it to the client C. The client C then holds the authentication token from the license server LS. Meanwhile, the license server LS generates and stores a license account through the created authentication token. These license accounts define the right to receive specific content.

On the other hand, the client (C) must submit the credentials for domain authentication to the domain server (DS). The credential may include encrypted information for identifying the client C and proving that the user is a legitimate user. These credentials can be the means of authentication necessary to manage a domain or license.

After verifying the credentials submitted from the client C, the domain server DS may generate an authentication token based on the verified credentials and drop it to the client C. The client C then holds the authentication token from the domain server DS. In addition, the domain server DS generates and stores a domain account through the created authentication token. These domain accounts define the authority to receive domain services.

The license account and domain account may be created from the same credential. In other words, the credentials for license authentication and the credentials for domain authentication may be the same. In addition, the same authentication token may be generated from different credentials, or the same account may be created by different authentication tokens. Here, the same account may mean that the license account and the domain account are the same.

For example, if the service provider operating the license server LS and the domain server DS are the same, the credentials provided for the same license authentication and the credentials provided for the domain authentication may be the same. However, in the case of DRM interoperable systems, many DRM providers are linked to each other, so the license server (LS) and the domain server (DS) are often different, so it is necessary to separate and manage credentials, authentication tokens, and accounts.

FIG. 3 is an exemplary diagram illustrating an association between a client, a domain server, and a license server when there are two domain servers but one license server.

As shown in FIG. 3, one domain server DS exists, whereas two license servers LSA and LSB exist. At this time, the license server A (LSA) and the license server B (LSB) may be operated by different service providers, the domain server (DS) is a service provider of the license server A (LSA), license server B (LSB) May be operated by a third party service provider, or a third party service provider. Therefore, the credential, authentication token, account, etc. are separated and managed.

In this case, the client C must separately generate a credential for the domain server DS, a credential for the license server A (LSA), and a credential for the license server B (LSB). For example, the user may purchase a license from the license server A (LSA) through the client C or may purchase a license from the license server B (LSB). Based on the license you purchased, you can connect to a domain server and authenticate it to receive domain services.

There may be various cases regarding what is purchased here. For example, the client C may obtain an authentication token based on the purchased credential after purchasing the credential, or purchase the authentication token after the credential is provided free of charge. In this case, the authentication token may include the details of the license or may include the details of the domain.

FIG. 4 is an exemplary diagram illustrating a form in which a subscription server is added in the case shown in FIG. 3.

Referring to FIG. 4, a subscription may mean a service having a time constraint. Such a subscription may be serviced by being dependent on the license servers LSA and LSB, or may be serviced by being dependent only on the domain server DS. When only the domain server DS is dependent, the subscription server SS may have a default mode or an abbreviated mode. Here, the subscription server (SS) is a management entity for servicing a subscription.

As illustrated in FIG. 4, the client C may submit a credential for the subscription to the subscription server SS. However, depending on the implementation, these credentials may not be submitted. This may vary depending on the service provider's initiative.

The subscription may depend on only one license server, such as license server A (LSA), and may simultaneously depend on two or more license servers, such as license server A (LSA) and license server B (LSB). In addition, when the subscription is dependent only on the license server (LSA, LSB), only the specific client (C) who has received the corresponding license authorization can receive the subscription service, and when the subscription is dependent only on the domain server (DS), The scripting service can be shared by clients (C) in the domain.

5 is a block diagram showing the configuration of license information generated and managed by a license server.

Referring to FIG. 5, the license server generates and manages license information 60 according to a license account. The license information 60 may include authentication and management information 62, pointing information 64, service receiver information 66, and service seed information. 67 and Service Usage Information 68 may be included. The license information 60 may be managed in a token of a promised form, which may also be referred to as a license token.

The authentication and management information 62 may refer to management information related to authentication and licensing of a user's account. The license server manages authentication and management information 62 to ensure proper coordination between services in a DRM interoperable system. Meanwhile, the license server may query the pointing information for managing the authentication and management information 62.

The pointing information 64 is information indicating which domain server the license information managed in the license server is pointing to. In this case, the pointing may mean that the license information managed by the license server is associated with the domain server indicated by the pointing information 64. For example, when the license server is pointing to a specific domain server, the license defined in the license information managed by the license server may be shared in the domain of the user authenticated by the domain server.

The service recipient information 66 is information indicating whose license the license information 60 has defined. That is, it may mean a service beneficiary who can exercise the rights defined in the license information 60. This service recipient information 66 may be comprised of user information, device information, or information identifying a combination of a user and a device.

The service seed information 67 refers to information on a service target provided, that is, information of serviced content. The content may include not only audio and visual digital media such as audio and video, but also objects that cause taste, touch, and smell.

The service notice information 68 is information defining restrictions on the use of the content defined in the service seed information. That is, the service notice information 68 may include information defining usage periods, usage times, usage counts, and distributions (copy, movement, etc.) within the domain that can use the content included in the service seed information 67. Include.

FIG. 6 is an exemplary diagram for describing a concept of mapping distribution usage included in service notification information 68.

5 to 6, since DRMs linked to the DRM interoperable services generally define distribution information, that is, distribution notices in a domain, in different terms, the license server services the DRM interoperable system. When managing the notice information 68, the distribution notice information of a specific DRM is mapped to terms that can be commonly used. This distribution notice is also important for content binding to recordable media in the domain.

7 is an exemplary diagram for explaining a pointing relationship between a license server, a domain server, and a subscription server.

As shown in FIG. 7, a license account is stored in the license server LS. The license account is linked to a domain account stored in the domain server DS according to the pointing information. The pointing information may be provided from clients C1 to C3 when creating a license account. Accordingly, the license server LS may associate a license account with a domain account.

The domain account stored in the domain server DS is defined for the user's domain. For example, a list of authenticated clients C1 to C3 is recorded in the domain account. This domain server (DS) stores pointing information to be associated with a domain account. The domain account is associated with three clients C1 to C3 according to the pointing information.

In this case, if the number of clients allowed in the domain is three, and if one additional client enters the domain, the service provider may decide to stop the domain service of the first client (assuming C1). For example, the pointing information of the first client, C1, is deleted. However, even in this case, the domain server DS may store the information of the client C1 and the list information of the clients C1 to C3, and only generate the pointing information when the client C1 enters the domain again.

  The subscription server SS may be with the license server LS or with the domain server DS. The subscription server (SS) associates the subscription account with the client C3 according to the pointing information. Client C3 can then receive the subscription.

FIG. 8 is an exemplary diagram for describing how pointing may be performed when multiple license servers exist.

Referring to FIG. 8, a license account A is stored in a license server A (LSA). License Server B (LSB) and License Server C (LSC) also store License Account B and License Account C, respectively.

In this case, the license server A (LSA), license server B (LSB) and license server C (LSC) may be a license server that supports the DRM mutual compatibility function. For example, suppose that License Server A (LSA) is a license server that is compatible with DRM A and DRM B, and License B (LSB) is a license server that is compatible with DRM B and DRM C. .

In fact, a license server that supports DRM interoperability can often make two DRMs compatible. Therefore, as in the above example, defining a license server for compatibility between specific DRM, and pointing according to the defined content can easily perform the service.

For example, in order to make DRM A and DRM C compatible, the license account A stored in the license server A (LSA) and the license account B stored in the license server B (LSB) are pointed to the domain account in the domain server DS. Therefore, license compatibility between DRM A and DRM C can be achieved through compatibility with DRM A and DRM B and DRM B and DRM C.

As described above, in a system for compatibility with multiple DRMs, each license server is defined as a server compatible with a specific DRM, and when DRM is compatible, DRM compatibility is performed by associating a license account of a corresponding license server with a domain account through a pointing technique. The service can be made easily.

9 is an exemplary diagram illustrating an example of defining a compatibility function of a license server for compatibility between DRMs.

9, license server A (LSA) is compatible with DRM A and DRM B, license server B (LSB) is compatible with DRM B and DRM C, and license server C (LSC) is DRM C and DRM. For compatibility with D, the license server D (LSD) can be defined for compatibility with DRM A and DRM D.

At this time, if DRM A and DRM B are compatible, the license account of the license server A (LSA) is pointed to the domain account. In addition, in order to make DRM A and DRM C compatible, the license account of License Server A (LSA) and the license account of License Server B (LSB) are respectively pointed as domain accounts.

FIG. 10 is an exemplary diagram for explaining an example of pointing from a domain account to a license account as opposed to the example shown in FIG. 8.

Referring to FIG. 10, the domain account in the domain server points to the license account A of the license server A (LSA) and the license account B of the license server B (LSB) according to the pointing information. In this case, the pointing method through the compatibility function definition of the license server described above may be applied as it is.

The subscription account of the subscription server (SS) may be pointing to the client C3 as shown in FIG. 10, but in some cases, may be pointing to a domain account, a license account A, a license account B, or the like.

On the other hand, the pointing information may be provided to the license server or domain server through a credential or an authentication token. Such credentials or authentication tokens may be obtained by a user purchasing a service to a service provider, or by sending a specific request through membership registration or the like. Pointing information may be provided from the client to the license server or domain server when the client provides credentials to the license server or domain server for authentication or when an authentication token is generated.

11 is an exemplary view for explaining how the pointing information is provided from the license server or the domain server.

Referring to FIG. 11, the client C may have a license credential for submitting to the license server LS, a domain credential for submitting to the domain server DS, and a subscription, although not shown, Contains information about the subscription credentials for submission to the subscription server (SS). The license credential, domain credential, and subscription credential may be the same or different as mentioned above.

The license credential, domain credential, and subscription credential are used by the client when the client requests authentication or is required by the license server (LS), domain server (DS), or subscription server (SS). (DS) and subscription server (SS) respectively.

This credential includes information about the initial client C, such as a Device ID, a User ID, and the like. Pointing information may be provided to the server included in the credentials, or may be provided separately. For example, the pointing information of the license credential is provided from the client C to the license server LS, and when the license account is created by the license server LS, the license server LS must know the pointing information of the license account. The same is true for domain credentials or subscription credentials.

12 is a flowchart illustrating an operation of a license server that provides a service based on pointing information, and illustrates an association procedure between entities through pointing.

11 to 12, the license server LS checks the validity by receiving a credential from the client C when the client C authenticates the request (step: S1). Then, if no validity problem is found, the license server LS generates an authentication token through the received credentials, and creates and stores a license account using the authentication token (step: S2). At this time, the generated authentication token may be lowered to the client (C).

Meanwhile, the license server LS receives the pointing information from the client C to associate the license account with another entity (step S3). Such a licensed account may be provided in the credential, or may be provided according to a separate request.

 If the pointing information is provided, the license server LS points to the license account according to the pointing information (step: S4). For example, the license server LS may point the license account to a domain account stored in the domain server DS in response to the indication of the pointing information. The license account can then be associated with a domain account. Subsequently, the license server LS checks the license account and the domain account associated with it (step: S5) and provides various services requested from the client C (step: S6).

Although the present invention has been described above with reference to its preferred embodiments, those skilled in the art will variously modify the present invention without departing from the spirit and scope of the invention as set forth in the claims below. And can be practiced with modification. Accordingly, modifications to future embodiments of the present invention will not depart from the technology of the present invention.

As described above, according to the present invention, a relationship between entities may be systematically designated through pointing information at the time of domain service. Therefore, when a domain service is provided by a plurality of service providers, it is possible to easily manage a linkage relationship between servers. In particular, in the case of a DRM interoperable service, even when there are multiple license servers and one domain server, systematic management is possible. .

Claims (13)

Generating an account using information of a credential received from a client; And If the pointing information for pointing to the created account is provided from the client, pointing and associating the account with a specific entity according to the provided pointing information comprising the step of associating. The method of claim 1, wherein creating the account comprises: Generating an authentication token through a credential received from the client; And And generating the account by using the generated authentication token. The method of claim 1, wherein the creating account is a license account. The method of claim 3, wherein the linking step, And associating the license account with a domain account of a specific domain server according to the pointing information. The method of claim 3, wherein the license account defines license information, The license information includes authentication and management information including information related to authentication and granting of a license to the license account; Pointing information indicating which domain server the license information is pointing to; Service recipient information indicating whose license the license information is defined for; Service seed information defining a target serviced by the license information; And And at least one of service notice information defining usage restrictions on a target defined in the service seed information. The method of claim 1, wherein the creating account is a domain account. The method of claim 6, wherein the linking step, And pointing the domain account to at least one client in a domain according to the pointing information to associate the domain account with at least one client in the domain. 7. The method of claim 6, further comprising: when the domain service for the associated specific client is stopped, deleting the pointing information to the client where the domain service is stopped; And And storing the information of the client from which the pointing information has been deleted. The method of claim 6, wherein the linking step, And linking the domain account with a license account stored in at least one license server according to the pointing information. The method of claim 1, wherein the creating account is a subscription account. The method of claim 10, wherein the linking step, And linking the subscription account to at least one of a license server, a domain server, and a client according to the point information. In the DRM domain system to provide a service by forming a domain, A client authenticated to the domain; And A plurality of management to create an account using the credential information received from the client, receive the pointing information for pointing the account from the client, and to point and associate the account to a specific entity according to the provided pointing information A DRM domain system comprising an entity. 13. The DRM domain system of claim 12, wherein the plurality of managed entities comprises at least two of a license server, a domain server, and a subscription server.

Images