| Migration Guide |    
|
| Migration Guide |
|
| C H A P T E R 4 |
|
Transitioning DRM and Content Pricing |
Version 2005Q4 of the Content Delivery Server offers a flexible configuration for content protection and pricing. Customers might want to take advantage of this flexibility for their existing content and not just for new content submitted after the migration to version 2005Q4. The migration process lets you configure the type of digital rights management (DRM) protection, content type, pricing model associations, and pricing options assignments to existing content during migration. You can also reprotect content using custom DRM agents during migration.
Version 2005Q4 of the Content Delivery Server introduces changes to how content is priced and offers additional types of DRM support. To understand how to configure content pricing and DRM protection, you need to be familiar with the following terms:
Each DRM supports some set of the pricing models available in the Content Delivery Server. There is also the DRM option of None, meaning no DRM protection is assigned has a set of applicable pricing models. The Content Delivery Server comes with a number of content types. Only the content type, midlet, comes associated with a DRM type, which is CDS DRM Agent. The other content types have no DRM (the None option) associated with them.
All content types must be associated with a DRM option. In addition, one or more pricing models must be associated for each content type. The pricing models that can be associated with a content type are dependent on the DRM option selected for that content type. You have the flexibility to enable all the available pricing models for a content type or only a subset. For example, the midlet content type is associated with CDS DRM Agent, the available pricing models are free always, trial, first download only, every download, per use, per period, and per subscription. All the models can be enabled or a just subset, such as first download only, per use, and per period.
Pricing models establish a condition of purchase for content. Every pricing model has its set of arguments, that is, additional parameters that define the actual price and terms. For example, almost all pricing models have a price argument.
The Content Delivery Server supports the following pricing models:
More than one content item can have the same pricing option. The benefit of using a pricing option is that if a pricing option is changed, the price of all content using that option is changed. A pricing option is based on a combination of DRM type, content type, and pricing model. For any content type, a pricing option can be created using only those pricing models that are supported by the content type (and implicitly, by the DRM with which the content type is associated). The arguments that are available for a pricing option are dependent on the pricing model as given in TABLE 4-1.
All of the DRM types available in version 2005Q4 are created in the target database. By default, OMA DRM 1.0 is disabled while all other DRMs are enabled. These default DRMs cannot be redefined through the migration configuration file. Only new DRMs can be added. Pricing models associated with default DRMs also cannot be modified through the migration configuration file. However, they can be modified in the corresponding properties files. It is possible to enable OMA DRM 1.0 by specifying the <enable_oma_drm> tag in the configuration file. When new DRMs are defined, its meta information and pricing model associations can be specified in the migration configuration file. For example:
All required content types (including any new content types) need to be fully configured prior to migration. Full configuration includes all required MIME type configurations, file extension configurations, content type and mime type associations, and device to content type and to mime type associations. If a specific DRM that is associated with a content type requires any specific MIME types and MIME extensions to be configured, for example OMA DRM 1.0, such MIME types and extensions are added automatically by the migration during the catalog write step.
For new content types, you do not need to move content items to these new content types, but the content types must be present and configured for content items as migration performs content resubmission during the catalog write step.
New content types must be configured if there are not enough existing content types to suit all DRM requirements. For example, if the source database has two content types, midlet and ringtone, while the target database is required to have the content types, midlet, ringtone, and truetone, where all truetone type content items are protected with the OMA DRM 1.0 and ringtone type content items are not protected with any DRM. If the DRM protection is the same, the content type must stay the same.
By default, the migration process associates the CDS DRM Agent option with the midlet content type and the None option (no DRM) with the other content types. This default association can be changed by listing content types in the migration configuration file, instructing the migration tool which DRM technology to associate to which content type, and which pricing models are to be available for that content type.
If no pricing models are listed with a content type definition, all the pricing models applicable for the DRM associated with the content type are used. You can specify that the default list of pricing models is used. In that case, the Free, Every Download, and Recurring Download pricing models are selected for all content types. For the content type midlet, all three models, plus Subscription, Usage, Period, and Trial Usage, are configured. If any pricing models specified for a content type are not supported by its associated DRM, those pricing models are excluded.
Generally, you only need to specify content types in the migration configuration file to change the default settings. Any content types not specified are still migrated and the default DRMs and pricing models applied.
The midlet content type is special, as well as the DRM type, CDS DRM Agent. Only the midlet content type can be associated with midlets and midlet-specific instrumentation. No other content types can be associated with midlets and midlet related instrumentation. The migration process does not verify if you specified midlet instrumentation for any other content type, but for such instances, content resubmission executed during migration fails.
To change the content type of migrated content, you can include a special class in the migration. This class controls how a content type changes for every item of content. The class needs to be compliant to the interface, com.sun.content.server.migration.ContentTypeMapper. See Appendix A for more information.
The following example shows some of the possible configuration you can include in the migration:
Version 2005Q4 offers two ways of pricing an individual content item:
Both the previous and latest version of the Content Delivery Server give three different prices for the same content item:
Price, as referred to in the previous list, is the combination of pricing model and monetary value, for example, $0.99 on every download.
By default, the retail price is either the same as the catalog price or differs by a markup value if a vending server is configured to automatically mark up content when stocked. In the previous version of the Content Delivery Server, it was possible to have completely different pricing models and price values for all three prices. In version 2005Q4, however, only the suggested and catalog pricing models can differ. Pricing models are selected from the list of pricing models allowed for the content type. The retail price must have the same pricing model as the catalog price. If the catalog price is set using a pricing option, the retail price can be specified using the same option or by setting a customized price. If the catalog price is a customized price, the retail price must also be a customized price. Pricing options are shared between Catalog and Vending Managers. However, each Vending Manager can set a monetary value that is different from the catalog price as well as the value set in other Vending Managers. In the case where the catalog price is set using a pricing option and the retail price is set using a custom price, the same pricing model must be used for both.
The migration configuration file lists the pricing options that become available after migration. It also assigns content to the pricing options during migration. A pricing option is defined by its name, its external name, the pricing model it uses, and the content type with which it is associated. Additional arguments can be specified for a pricing option that affect the monetary price and usage conditions. See TABLE 4-1 for a list of all available arguments.
You can specify the number of trials that are allowed for a content item, that is, how many times a content can be used before the subscriber is charged. To apply trials, the content type must support the Trial Usage pricing model.
In the database, two pricing rows are created when trials are enabled for a content item. It is not possible to configure trial usage through pricing options because two different pricing models would be required. However, you can define the pricing option to specify a number of trial uses, which effectively translates into two rows in the database during the migration.
The following example shows how to implement trial usage:
The DRM type that supports this pricing option is automatically derived from the content type associated with the pricing option.
The following example shows how a vending server can set its own monetary value for a pricing option:
To have content priced using a pricing option instead of with a custom price, the pricing option must be designated to be automatically assigned. When automatic assignment is set to true, the content item is assigned the pricing option when it is determined that the content has the same pricing model and monetary value as the pricing option. The following example shows how a pricing option is set to be automatically assigned:
Version 2005Q4 of the Content Delivery Server offers two ways to identify content offered for free. Suggested, catalog, or retail prices can be free. A price of free can be set using the Free pricing model or by specifying a price value of zero for any other pricing model. During the migration, content that does not have a price value set can be assigned the Free pricing model or to a pricing model of the user's choice and retaining the zero price value. The default action is to select the Free pricing model. To change the default behavior, you can specify the pricing model to use in the content type definition. It is implemented with the <free_price_selector> tag, which can be specified within the <content_type> tag. The tag takes a special code value of 1, 2, 3, or 4:
The terms of the pricing model are retained from source database when a pricing model other than Free is selected.
For a deployment with use cases, when the catalog price value is zero and the retail price value is nonzero, prices must be mapped to a pricing model other than Free. Once the catalog price has been selected using a Free pricing model, the retail price must do the same because the pricing model for the retail and catalog price must match.
The following example shows how to specify pricing models for zero prices:
When the available configuration options are not sufficient to configure content pricing as needed, custom code can be written on a per content item basis. A class written in the Java programming language (Java class) is specified in the migration code that is used to select pricing options, the Free pricing model, and whether custom pricing is used. The class is specified by the <pricing_option_sticker> tag in the migration configuration file:
The class must comply with the com.sun.content.server.migration.PricingOptionSticker interface. See Appendix A for information on the interface. The implementation is used to select a pricing option for a content item, determine whether a pricing option or a custom price is used, and which pricing model is used for content items with a zero price value.
The section describes the decision making process that determines the price of an individual content item. At the beginning of the process, all DRMs, content types, and pricing option dependencies are examined and resolved. The information is obtained from the migration configuration file and the default data available in the latest version of the Content Delivery Server.
Before the price assignment process is started, the content items themselves are processed. If requested, the content types of some items are changed. At this point, when an item is examined, its content type is always considered to be new.
In the previous version of the Content Delivery Server, trials were specified by Vending Manager administrators. In version 2005Q4, trials are part of the catalog price. All source Vending Manager databases are queried to determine if any content items had trials assigned to them. If multiple Vending Managers specify different number of trials for the same content item, the smallest amount (other than zero) is selected for the number of trials for the target catalog price.
The following steps are executed for every content item to decide on suggested or catalog price.
1. Gather the pricing information for all source pricing models: download, subscription, and usage.
2. If the usage price is non-zero, check to see if the content type of the item allows a usage pricing model. If yes, the price is considered selected and execution moves on to Step 8.
3. If the subscription price is non-zero, check to see if the content type of the item allows a usage pricing model. If yes, the price is considered selected and execution moves on to Step 8.
4. If download price is non-zero, check to see if the content type of the item allows a download pricing model. The actual pricing model selected is either Every Download or Recurring Download depending on the price terms. If the selected pricing model is available for this content type, the price is considered selected and execution moves on to Step 8.
5. If a price is not selected at this point and the content item has a non-zero price, issue a warning and force the content to have a price of free.
6. If the price is free, check to see what pricing model is requested. The content type configuration or the custom code is examined to make the determination.
7. If the content type does not support the selected pricing model, issue an error message and stop the migration process.
8. If any trial attempts are requested for this content and its content type does not support the Trial Usage pricing model, reset the number of trials to 0 and issue a warning message.
9. Check the configured pricing options to verify that the pricing option can be assigned to this content item.
10. If all pricing options can be used with this content item, determine which pricing models are compatible with the item's content type. If the custom pricing option sticker is configured, call it to verify the final pricing decision.
At this point, the content item's pricing and whether a pricing option or a custom price is applied has been determined. The data is committed to the database.
11. Continue execution until all content items are iterated.
The following algorithm is run to determine the retail price for every content item:
1. Gather the pricing information for all source pricing models for this content: download, usage and subscription.
2. Gather catalog price information that was assigned to this content item during the catalog database migration.
3. Pick the retail price value that corresponds to the same pricing model from one of the existing pricing models. If the value cannot be determined because the catalog pricing model is specific to version 2005Q4, the catalog price is forced to be the same as the retail price.
4. If the selected monetary price value differs from the intended retail price, issue a warning.
5. If the catalog price is created using a pricing option and the vending version of this pricing option has the same monetary value as the selected retail price, price the content using the pricing option as well.
6. If custom price sticker is configured and the currently selected price is to be set using a pricing option, call the sticker to determine whether the pricing option is used or the process needs to revert back to using custom pricing.
At this point, the price of the content is determined and it is submitted to the database.
7. Continue execution until all content items known to this Vending Manager are iterated.
| Migration Guide | 819-3217-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.