WO2006073543A9

WO2006073543A9 - A system and method of processing entitlement rules, offering and delivering digital content

Info

Publication number: WO2006073543A9
Application number: PCT/US2005/039130
Authority: WO
Inventors: Zack Russel; Steve Salzinger; Dennis Manu; Ubah Yusuf; Jeffrey Sherwin; Takeshi Toyohara; Mike Stanley; Matthew Narrell
Original assignee: Cauldron Solutions Llc; Zack Russel; Steve Salzinger; Dennis Manu; Ubah Yusuf; Jeffrey Sherwin; Takeshi Toyohara; Mike Stanley; Matthew Narrell
Priority date: 2004-12-30
Filing date: 2005-10-31
Publication date: 2007-04-12
Also published as: WO2006073543A3; EP1839259A2; EP1839259A4; WO2006073543A2; CA2596968A1

Abstract

A method of interaction between content providers and consumers on a communication system including the steps of acquiring and managing digital media assets for distribution to consumers through the communication system, where a workflow for distributing the digital media assets is managed through the communication system. Profile and preferences data are acquired facilitating the consumption of the digital media assets, where the digital media assets are transacted upon through the communication system. The management of digital media content and the digital media assets are adjusted by the content providers, for delivery through the communication system based on content provider rules, consumer preferences, media type and the consumer's device.

Description

A SYSTEM AND METHOD OF PROCESSING

ENTITLEMENT RULES, OFFERING AND DELIVERING

DIGITAL CONTENT

REFERENCE TO RELATED APPLICATIONS

This application is related to and claims the benefit of priority from co- pending application Nos. 10/027,574 filed on December 30, 2004; 60/667,789, filed on April 1, 2005; and 60/667,883 filed on April 1, 2005, the entirety of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to digital content delivery. More specifically, the present invention provides a method and system for creating, scheduling, licensing, offering, and managing digital content offers using a rules-driven architecture.

BACKGROUND OF INVENTION

The home entertainment market has been increasingly moving to an on- demand business model that has been fueled by a reduction in digital media distribution costs, an increase in the adoption of broadband access as well as in consumer enthusiasm for digital media. As such, content owners, distributors and producers, (referred to here forth as media providers) have been faced with the challenge of providing flexible methods for customers to purchase and consume digital content while increasing the productivity and efficiency levels of their backend business processes.

To keep up with changing consumer preferences, media providers need to be able to modify business rules quickly and be able to make content packages in their catalogue available at a variety of prices and consumption rights. However, managing the product catalog can be a difficult feat for media providers considering the volume of product information that flows through their internal networks. Added to this challenge is the fact that data is typically recorded in multiple applications, locations and formats. This makes it difficult for media providers to distribute targeted content and appropriately respond to consumer requests within a timely fashion. Further, when these complexities are coupled with a plethora of business information such as rights, pricing and location, the correlation of this data in a catalog is additionally taxing as information increasingly becomes unmanageable.

Moreover, as digital media grows in popularity and the available types of digital content expands; rights information associated with this content also increases. Rights information may be linked with certain customer and/or product attributes. This information has the potential to grow exponentially as the number of attributes (customer and product) and business models increase, the need for tools that help media providers to manage such data in an automated fashion also escalates. OBJECTS AND SUMMARY OF INVENTION

The present invention looks to overcome drawbacks associated with the prior art. It provides guidelines and the means for customizing rules related to creating, scheduling, licensing and offering digital content. The method of the present invention specifically refers to a 2-way communication between media consumers and media providers. The invention of the present invention further provides for automating the steps involved in preparing and delivering digital products and for streamlining the front-end consumer transaction process. The system also includes multiple components that work together to carry out the approach set forth by the methodology described in greater detail below.

It is a first object of the present invention to provide an integrated business process solution (IBPS), incorporating the full-lifecycle of content production and distribution with a simplified process for delivering preferences-based content. The present invention takes into consideration both how content can be offered and consumed. Under the IBPS methodology, steps taken by media providers may include, but are not limited to, creation /acquisition, asset formatting, rights/usage permissions, distribution agreements, catalogue, traffic placement, bundling/re- cataloging, display presentation and reports. On the other end of the spectrum, steps taken by the content consumer within the system and method of the present invention may include, but are not limited to, access attempts, user identification/authentication, viewing of media options, selecting content, media user experience/transactions, media experiences, and reports. The framework facilitates the delivery of digital media based on consumer preferences, simplifies the purchase process by reducing the number of steps required to transact and outlines an automated workflow for editing, validating, scheduling and publishing data. It is another object of the present invention to provide a system for the processing, management and distribution of digital content that automates and simplifies the backend processing of digital media files, and is closely aligned with the IBPS methodology. The system provides an end-to-end solution by furnishing multiple modules that are designed to operate independently or complement each other as each has unique tasks and responsibilities. The system further includes an Asset & Metadata Management module, Schedule Management module, Contract Management module, System Management module and Offer Catalogue Management module, Reports Management module and a Publishing module. An Entitlement Engine (including a Web Rule Builder) adds additional functions to the system's offerings.

One embodiment of the present invention is to provide an Entitlement Engine that is equipped to process all rules surrounding content a consumer may have a right or claim to and the interfaces required for accessing this logic. Entitlement Engine responds to consumer requests with either authorization or alternatives to the desired content. It provides an automated method for managing, filtering and routing complex rules tailored to securely control access and rights to specified content. Also, the Entitlement Engine ensures the integrity of digital media throughout the content ordering process by facilitating a consumer's ability to initiate the order of a digital product or service based on their status (subscriber entitlements), initiating the requirements for viewing and/or purchasing a digital offer or package (offer entitlement), using license parameters associated with a specific piece of content (license entitlement) validating the rules for a transaction (transaction entitlement), posting the transaction policies on purchased services or products (service entitlement) and providing parental-type controls that may be based on a consumer's primary or secondary account status (access entitlements). it is another object of the present invention to provide a Web interface for creating, manipulating and managing entitlement rules in addition to four components. The first component, External Interfaces and Request Handler, includes a set of inbound interfaces that accept entitlement requests. Another component is the Rule Engine which contains the logic necessary for entitlement decisions and is responsible for the processing of all entitlement requests. Additionally, the State Change and Exception Logger is charged with logging application events from the Entitlement Engine. The fourth component is the External Data Source Interface, which provides the Entitlement Engine with interfaces required to appropriately request data from external systems such as a media provider's EIS systems.

It is yet another object of the present invention to provide an Entitlement Engine that processes rules to determine one's right to consume a product or service. As such, the Entitlement Engine is configured to interface with a plurality of modules in order to obtain rules regarding customer access rights to the content requested by the customer portal. The present invention enables digital media providers to track, secure and manage entitlements to digital content.

In one embodiment the present invention provides an Offer Catalogue Management component that automates the offer delivery and content execution process of the present invention. Specifically, it automates the workflow for editing, validating, scheduling and publishing offers to a variety of catalogs and/or programming guides. It tracks each step of an offer's development from creation, and approval, to when the file is published; the file's asset status is updated as it moves through its deployment cycle.

The Offer Catalogue Management enables media providers the ability to quickly and easily offer new products and services to consumers of digital content. It further enables media providers to make available multiple offers across price points, regions, availability dates and usage rules. Further, the Offer Catalogue Management module correlates offers directly to a single piece of content and changes associated attributes on an as needed basis, thereby making it easier to manage frequently changing offers.

BRIEF DESCRIPTION OF DRAWINGS

The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with features, objects, and advantages thereof may best be understood by reference to the following detailed description when read with the accompanying drawings:

FIG. 1 illustrates a high-level block diagram of a system for back-end media distribution, in accordance with one embodiment of the present invention;

FIG. 2 illustrates a high-level block diagram of a system for front-end media distribution, in accordance with one embodiment of the present invention;

FIG. 3 is a flow chart for a content provider process, in accordance with one embodiment of the present invention;

FIG. 4 is a flow chart for a content consumer process, in accordance with one embodiment of the present invention;

FIG. 5 is a high-level diagram of a 2-way communication stream for the process of figure 4, in accordance with one embodiment of the present invention;

FIG. 6 is a flow chart for an integrated content consumer and provider process from figures 4 and 5, in accordance with one embodiment of the present invention; Figure 7: is a high-level diagram of the Entitlement Engine and its environmental architecture, in accordance with one embodiment of the present invention;

Figure 8: is a diagram of the components of the Entitlement Engine from Fig.

7, and associated interfaces, in accordance with one embodiment of the present invention;

Figure 9: is a diagram of workflow request states, in accordance with one

embodiment of the present invention;

Figure 10: is a flow chart of a content request and approval process, in

accordance with one embodiment of the present invention;

Figure 11: is a flow chart of an authorization to download content scenario, in

accordance with one embodiment of the present invention;

Figure 12: is a diagram depicting the process of creating/modifying rules in the Rule Builder, in accordance with one embodiment of the present invention;

Figure 13: is a flow chart of a service entitlement request by the license server, GetSubscriberLicenseEntitlement Structured API, in accordance with one embodiment of the present invention; FIG. 14 is a block diagram illustrating the elements of a digital product offer, in accordance with one embodiment of the present invention;

FIG. 15 is a flow chart of the process of creating and modifying an offer as in Fig.14, in accordance with one embodiment of the present invention illustrating the offer creation and modification process;

FIG. 16 illustrates the sample fields from a single purchase offer, in accordance with one embodiment of the present invention;

FIG. 17 provides an illustration of an offer's workflow state, in accordance with one embodiment of the present invention.

DESCRIPTION OF TERMS

The following terms are provided to establish an understanding of the invention:

1. Media Provider: content provider, content owner, distributing or reselling digital content, such as cable or wireless service providers.

2. Customer: consumer of digital goods and services.

3. End-user: person using an application, system or method. For the purpose of this invention, the terms end-user and media provider are used interchangeably.

4. MSO: Multiple System Operator - for example, a cable television corporation with more than one network is an MSO.

5. VOD: Video On Demand - also referred to as 0n-demand Programming, Live-streaming, Internet-on-Demand Video or IP-based Video, in addition to a number of other terms. The service enables e.g. television viewers to select a program and have it sent to them via a network such as a cable or satellite TV network.

6. DRM: Digital Rights Management - security-based technologies that enable content owners to have control over how their content is distributed.

7. Package: for the purpose of this invention, a package pertains to an image, metadata, and video (or any other type of digital media) file all wrapped up into a final distribution format.

8. XML: Extensible Markup Language - a flexible way to create common information formats and share both the format and the data on the Internet, intranets, in digital cable infrastructure and elsewhere. y. l ags: bmbedded information keys, such as HTML or XML embedded keys, for customer specific values which can be agreed upon at time of Provider/Vendor agreement.

10. Dialogs: Interactive user interface objects displayed by the browser (such as text fields, text areas, check boxes, radio buttons, and list boxes).

11. CE: In the context of this document, CE refers throughout to Computer Electronic devices, generally small hand-held devices such as PDAs (Personal Digital Assistants).

12. PIN: Personal Identification Number, used to authenticate an end-user.

13. UI: User interface is everything designed into an information device with which a human being may interact.

14. Local cache: a place to store something temporarily, for example, when returning to a page recently visited, the browser can obtain the Web site address from the cache rather than from the original server, thus saving the end-user time and the network, the burden of additional traffic.

15. EIS: Enterprise Information Systems: existing data sources and technology applications within the media provider's infrastructure which may store information related to billing, customer and product information.

16. IP: Internet Protocol: specifies the format of packets (also called datagrams) and the addressing schemes. 17. Digital Media/Content: for the purpose of this invention, digital media or content refers to advertisements, games and audio/video content.

18. URL: Uniform Resource Locator: a unique address for a file, page or program. The URL contains the name of the protocol to be used to access the resource, a domain name that identifies a specific computer on the Internet, and a pathname, as well as a hierarchical description that specifies the location of a file in that computer.

19. Encryption: encryption is the conversion of data into a form called a ciphertext that cannot be easily understood by unauthorized people.

20. OSS: Operational Support System: As defined by whatis.com, an OSS is a set of programs that help a communications service provider monitor, control, analyze, and manage problems with a telephone or computer network.

DETAILED DESCRIPTION OF INVENTION

The present invention is both a method and system for delivering digital content. Using a rules driven architecture, it facilitates the process of creating, scheduling, licensing, offering, packaging, delivering and transacting with digital content.

The present invention establishes and maintains bi-directional communications between content consumers and content providers involved in electronic transactions. Turning now to the description of the figures, where like elements are numbered the same throughout, in one embodiment of the present invention, as illustrated in Fig. 1, system 10 depicts the content distribution system that content providers 50 and their affiliates 52 undertake. The system provides guidelines for managing, scheduling, licensing, offering, publishing, transacting, and reporting on digital content on behalf of media providers.

System 10 maintains an asset and metadata management module 23 that provides the ability to create and manage content assets and asset metadata. Schedule Management module 24 schedules the delivery of these assets and Contract Management module 29 tracks associated licensing information for the assets. Offer Management 20 module processes content offers. Also, Reporting module 25 enables media providers to view and manipulate reports. Additionally, combined publishing module 25 distributes asset information and asset packages to distributors, e.g. MSOs. Further, System Management module 22 includes functionality for administering System 10 and provides access control capabilities, royalty/licensing administration and billing functions. System 10 may include an encoding and compressing module with DRM components 27 for encoding, compressing content received in multiple formats and associating the appropriate usage rights for content stored in database 28a. The various modules of the system are inter-related and often share information. Each module is presented in a separate paragraph describing its distinct functionality and how the particular component fits into the overall system.

The first addressed is Asset and Metadata Management module 23 which manages multiple types of assets, including audio, video and images. It provides a multi-role, multi-permission, metadata management tool for the development of content assets. Additionally, Asset and Metadata Management module 23 provides end-users, such as content providers 50, with the ability to import and validate asset and metadata from pre-defined templates. This information may be added to, modified, deleted or archived.

Asset and Metadata Management module 23 is responsible for managing the workflow surrounding the development and approval of digital assets and associated metadata. Assets and associated metadata may be entered in the system either manually (via an admin interface) or via a predefined feed. The new data stream may be automatically recognized by the system (it can determine whether or not an asset is incoming or outgoing in the process) or the end-user/content provider 50 may manually select the specific offer or package to apply to it. In either case, the new asset file is transported to the content delivery system. As the digital asset goes through its lifecycle, the system acknowledges all steps in the work status and automatically updates the work order status. Additionally, end-users may monitor, update and manage asset status information (including data on assets that have been archived or deleted). Once a change is made, it is reflected immediately in the system.

In one embodiment of the system, Schedule Management module 24, illustrated in Fig. 1, allows for the scheduling of assets and tracks data associated with contract information. Schedule Management module 24 manages any and all objects that are schedulable including, contracts, encoding times, DRM wrappers and content offers. This module also manages the availability of attributes pertaining to when multiple types of schedulable objects or digital content should be made available to targeted locations.

Schedule Management module 24 also provides a centralized view of asset information for all time periods and enables end-users to assess which assets should be delivered live, which should be launched and which were previously scheduled. Varying hour clusters indicate different time periods in which an asset can be included in the programming of a service. This enhances flexibility as one channel can offer multiple assets simultaneously with different customer rights options, rather than in a linear fashion, as in traditional broadcast schedules.

The Contract Management module 29 handles agreements with media providers that outline the terms for distributing content. Contract Management module 29 enables media providers to add, edit, archive and delete any data related to contracts. It includes functionality for managing, validating and packaging digital content that has been licensed by content providers 50 from 3^rd party content providers/producers. Licensing and contract information that is collected may include (but is not limited to) royalty minimums, total licenses, total expired licenses, license start and end dates in addition to specified limitations on the distribution of content. Rules can be set to enable notifications to be sent when a license is near its expiration date. Scheduling and licensing information are interrelated in such a way that each time the schedule is edited, revenue figures are recalculated, thereby e.g. enabling media providers to calculate total revenue figures based on scheduled assets and asset usage data in licensing agreements.

Also illustrated in Fig. 1, Reports Management module 25 allows end-users to create and generate reports based on stored asset information. Reports include data that may be relevant to all aspects of the digital asset management process such as the number of available assets, the status of an asset or a customer's usage history. This module enables media providers to build reports on any asset data or offer- related activities in the system. The Reports Management module 25 supports both canned and custom reports.

System Management module 22 includes administrative tools that are offered via a series of Web forms. It enables employees of content provider 50 with the appropriate level permissions to manage rules surrounding services, roles and access privileges. In particular, it enables end-users/content providers 50 to change the status of a title, including the ability to archive, restore or delete them. Further, content providers 50 may conduct searches on assets or view archived assets. System Management module 22 also provides the ability to add, edit and remove users. Information such as a system user's name, role, identification and contact information may also be managed within this module.

The Offer Catalogue Management module 20 provides a rules-driven listing of available digital product offerings. It facilitates the creation, management and distribution of content offers. Digital offerings are maintained in a central repository. Media providers have the option to modify, delete or archive these offers. Once an offer has been created, it is made available to any asset or product that is available for purchase. Offers include data relevant to making purchase decisions such as availability, assets, rights and pricing features. This information may be saved and used as templates for future offers. The Offer Catalogue Management module 20 makes it possible to cross-relate existing offers directly to a single piece of content and change associated attributes (as discussed above: availability, assets, rights and pricing) as business needs warrant. Further, the ability to correlate these offers back to a specific piece of content makes it possible for media providers to determine the success rate of their offerings.

The Publishing module 25 makes it possible for media providers to publish content to multiple locations (in one step). It includes a Physical Asset Repository (PAR) 27a that handles the physical ingestion involving the moving, renaming, and encoding of media assets and a Packaging and Distribution component 27b that uses a Digital Rights Management (DRM) packager to create a license for Internet Protocol (IP) based distribution of on-demand media. Publishing/reporting module 25 may be combined into a single module 25 as shown in Fig. 1 or may be separated into two separate and independent modules.

It is understood that the above described modules and components are considered exemplary and are in no way intended to limit the scope of the present invention. Any similar system using similarly functioning modules arranged to achieve similar communications is within the contemplation of the present invention.

The remainder of this document delves into two unique software inventions, one concerned with creating and processing entitlement rules (Entitlement Engine) the other used to create and modify content offers (Offer Management). Each of these inventions plays an integral role in System lO's architectural environment and consequently helps to drive the IBIS framework.

The above described framework of system 10 takes into consideration both the manual and automated support of the state of asset collections. In one embodiment of the present invention, it provides for at least five states for an encoded asset, including but not limited to "ready to encode", "sent to encode", "encoded", "delivered-inactive", and "live". "Ready to encode" means that the encoded asset tape or file has been received; the DRM component is specified and ready to be encoded. "Sent to encode" means that the encoded asset tape or file has been sent to the encoding facility. "Encoded" means that the encoded asset is digitized and the file was encoded in the appropriate format. "Delivered-inactive" means that the encoded asset file has been delivered in an inactive state to System 10 and "live" means that the encoded asset file is live on a server in System 10. A rule engine component 26 provides the ability to add new states with additional operations.

The IBPS framework alleviates the need for content providers to manage state and dispatch code on a user/session level. The framework makes adjustments to workflow simple and straightforward, for example, system 10 operators or administrators can determine what the required workflow should be and design the appropriate changes to the interface. The ability to change rules in the workflow introduces flexibility to a process that is typically derailed each time a change occurs in the way business is conducted. Moreover, multiple roles in the workflow of the asset distribution process can be supported. Preferably, only those logged on as administrators can authorize or restrict access to certain functions by assigning roles to end-users; however the invention is not limited in this respect.

Since the asset workflow varies based on company size, industry and success level, it is necessary to enable a variety of players to participate in the content distribution network. For example, there may be as many as eight or more roles in the typical VOD distribution environment. These roles can include but are not limited to: a content provider 50 (to create new assets), a scheduler (to manage and finalize assets schedules) a marketer or marketers (to accept and/or modify titles and descriptions), administrator (to generate transmission lists and XML for MSOs, administer rights and privileges as well as maintain category information), legal person (to create and modify contracts for assets in the schedule), librarian (to manage the storage of content assets), basic end-user (who is privy to read only access of certain asset data and schedule data), and finance officer (to view, edit and calculate revenues and revenue splits bound by the asset licensing agreements).

In one embodiment of the present invention, Fig. 2 demonstrates a second set of integrated feature elements for system 10 for transactions with affiliate sites 52 by content providers 50 via a proxy server 40 to DSTB 96 or a wireless device 98 or via web server 38 to PC 94. Content is stored on a central database 44, that houses profile management module 16, commerce transaction module 18, and a digital wallet module 19 that together, facilitate the process of transacting and consuming digital products on CE devices.

Customer data is received directly from the registration process or through interactions on System 10. In the case of the latter, a proxy server 40 communicates with the transaction module 18 and profile module 16. Proxy server 40 receives requests from customers, parses and modifies the received information and incorporates it with the consumer profile data that corresponds with tag markers 42. Consumer profiles are automatically updated based on customer interactions, thereby enabling content provider 50 to send to a local cache 50a, content that is in sync with the customer's'changing interests. Tags 42 enable content providers 50 to modify the page layout, workflow and content without breaking integration points in System 10.

The type of profile information that is collected includes but is not limited to customer name, credit card, billing and shipping address. When the customer 60 returns for another transaction, customer data is automatically filled in if there is only 1 choice or if the customer has already made this selection in the past. If on the other hand, the appropriate data cannot be easily determined, a data entry page that aims to collect the missing information is provided to customers 60. In such cases, dialogues may be displayed to customers 60 that are designed to ease the process of entering data. Dialogs employing radio buttons, check boxes and menu bars are utilized in order to simplify the workflow for end-consumers 60 as this can be a barrier to a transaction when entering personal data in an input restrictive CE device.

The types of dialogs that are presented to customer 60 may be modified according to their preferences or to merchant transaction policies. Further, customers 60 using limited input devices have the option to manage their profile information on the Internet. The authentication process is tied to account information, device, or to a federated identity system, thus allowing for simplified profile management and fewer forgotten passwords.

It is noted that the following described process is presented in a particular order however; this is in no way intended to limit the scope of the present invention. In one embodiment of the present invention as illustrated in Fig. 3, at step 200, the content provider process via system 10 begins with creating or acquiring a digital asset that content provider 50 has the right to redistribute and sell. The content provider 50 may create and distribute digital media themselves or, alternatively they may purchase it from another content producer. In a third manner, content provider 50 may simply receive the rights from a second content provider 50 who owns the license on a particular asset in cases where content provider 50, a contract or distribution agreement is established between the content creator and content licensor at step 206.

Once the legalities are in place, whoever has the necessary permissions to use the content can modify it as they desire. In step 202, content providers 50 may modify the asset in multiple ways including formatting (or reformatting) 202. Formatting step 202 consists of encoding the content, creating associated metadata, storing the content and making it available for packaging, distribution or resale. By enabling content providers 50 to reformat based on content, DRM and device type, a flexible environment for conducting business with partners who have invested in incompatible or competing technologies is created. This enables content providers 50 and sellers to collaborate regardless of disparities that may exist in business models, physical location or technical equipment. As a result, the level of effort required to add new assets and new partners is decreased.

In one embodiment of the present invention, rules may be established that govern how one can use or sell content and how long content can be offered for purchase. At step 204 rights/usage permissions or rules are generated that consider portability permissions, previewing and playing capabilities as well as access rights, and DRM (including copyright rules that govern how one might share a digital product). Additionally, a variety of rules-based price structures may be implemented, for example, 'for the month of December buy two products and get a third free'.

Next, at step 208, the present invention utilizes a cataloguing step consisting of the generation of an inventory of all content provider assets and associated information in a central location. The central location may be handled by System 10 or it may be handled locally by content provider 50. Cataloging step 208 makes it possible to bundle or re-catalogue at step 212, quickly as it enables content to be stored in a digital, searchable library that alleviates the time and effort required to search in different locations. Also, content providers 50 can set guidelines for how media offerings can be packaged, e.g. as a subscription or on a standalone basis. Content may be packaged and repackaged based on marketing campaigns and special promotions. It can also be arranged as a compilation for example, in the case of music or perhaps as a digital audio and video bundle.

At traffic placement step 210, the placement of an asset can be determined and the location in which it can be purchased can be specified. This step serves as a dashboard that organizes and presents content in a manner that is easy to read. Information may be placed in a certain promotional area or in particular categories for searching purposes. Content providers 50 may track the location and view the status of an asset in the distribution process via the traffic placement step 210 as information from multiple components are integrated into a unified display. Also, in order to influence how content is consumed, providers set rules that impact display presentation during a presentation step 214. For example, rules may be set to impact the look and feel options that can enhance the end-customer's 60 overall experience.

Next at step 216, the reporting of asset data is conducted. Metadata sent either inside or outside of the network is captured and may be reported on. Content providers 50 may create reports that, for example, analyze data on the popularity of certain media products. Moreover, reports generated at step 216 may provide value-added information on customer behavior and usage. Also a hybrid of canned or user definable reports can be downloaded to another program (e.g. Excel).

It is understood that the above description of a content provider's 50 process is exemplary and is in no way intended to limit the scope of the present invention. Any similar system using similar functions and/or steps are within the contemplation of the present invention.

In one embodiment of the present invention, as illustrated in flow chart Fig. 4, a content consumer's 60 process via system 10, is shown, displaying the front-end consumption of digital goods. This process preferably occurs in sequential order described below, but is not limited in this respect. At step 300, consumer 60 attempts to access a device, e.g. PC, TV, game console (such as CE devices 94 and 98), to gain access to digital media such as video, audio, forms, applications, data and games. Consumer 60 selects the desired content (via mouse, keyboard, remote control or device). Next, at step 302, the hardware customer 60 is using is automatically identified. If customer 60 is an existing one, when he/she enters the username, password and personal identification number (PIN), profile management module 16 identifies customer 60 via a secure communication between device (94, 96 or 98) and profile management module 16.

Customer 60 is given the ability to review descriptions of available content irrespective of his/her customer status (new customer or existing customer). Customers can view available media options at step 304, and access content or preview materials on sale. Faced with such an option, customer 60, at step 306, selects from available content using categories, menu items and list boxes. If customer 60 is new, he/she would first register prior to having access to the information from catalogue step 208 described above in the content provider context.

Available content may be based on customer's 60 previous selections or on the recommendation of system 10. At a next user experience/transaction step 308, customer 60 completes a transaction; all actions required to fulfill, complete and approve a transaction are part of this step.

As can be seen from the previously described steps, the present invention simplifies the transaction process by reducing the number of steps required for an end-user/customer 60 to interact with a media service. Customer profiles 16 are captured to enable the automatic pre-fill of customer data based on historical data. Customer 60 can have multiple profiles tied to different addresses or credit cards (debit cards, checks or pre-paid cards). This information is stored in System 10 and is submitted to commerce transaction module 18 at transaction user experience/transaction step 308. Preferably, customer 60 only needs to select the appropriate address and confirm the method of payment at the time of the transaction. When the transaction is complete, a confirmation is received by customer 60. Expediting the consumption process serves to lower hurdles to transacting via a remote or wireless device 98 in particular. Available content may be based on customer's 60 previous selections or on the recommendation of system 10. At a next user experience/transaction step 308, customer 60 completes a transaction; all actions required to fulfill, complete and approve a transaction are part of this step.

As can be seen from the previously described steps, the present invention simplifies the transaction process by reducing the number of steps required for an end-user/customer 60 to interact with a media service. Customer profiles stored in customer profile module 16 are captured to enable the automatic pre-fill of customer data based on historical data.

Customer 60 can have multiple profiles tied to different addresses or credit cards (debit cards, checks or pre-paid cards). This information is stored in System 10 and is submitted to commerce transaction module 18 at transaction user experience/transaction step 308. Preferably, customer 60 only needs to select the appropriate address and confirm the method of payment at the time of the transaction. When the transaction is complete, a confirmation is received by customer 60. Expediting the consumption process serves to lower hurdles to transacting via a remote or wireless device 98 in particular

The present invention looks to enhance customer's 60 overall media experience so that he/she returns to consume more digital products. As such, media experience/consumption step 310 pertains to the customer's actual media usage experience. In this step, attributes related to customer preferences are captured, thereby enabling the personalization of the information stored in the catalogue step 208 (as it consists of choices selected by customer 60 as well as recommendations made by System 10 that are based on customer's 60 prior selections). As a result, rather than having to sift through potentially thousands or even hundreds of thousands of content, media offerings are reduced to only those that match customer's 60 desires, needs or interests. At step 312, reports can be generated that enable customers to review a history of a single transaction or view all transactions across content providers.

It is understood that the above description of a consumer 60 process is exemplary and is in no way intended to limit the scope of the present invention. Any similar system using similar functions and/or steps is within the contemplation of the present invention.

In one embodiment of the present invention, a 2-way communication stream is provided between content providers 50 and content consumers 60. Figure 5 illustrates a two way transmission pathway 102 of customer preferences to the supply side of the content exchange and the subsequent bi-directional distribution pathway 104 of content to consumers 60 that matches their explicit and implicit preferences. IBPS 100 is preferably carried out on system 10 as described above or entirely in the content provider's 50 framework.

Each resulting interaction along these pathways 102 and 104, create more efficient distribution between consumers 60 and providers 50. For content consumers 60, this invention responds with a simplified purchase process once their preferences are made available to content provider 50. Also, once a content consumer 60 transacts for the first time, his/her transaction history results in a more personalized experience. Further, content providers 50 can create business rules that result in a more efficient workflow. The more content that is pushed through the present invention, the more results data that content provider 50 will have on their distribution process and consumer 60's transactions.

In one embodiment of the present invention, content consumer's 60 process, as shown in Fig. 3, and content provider's 50 process, shown in Fig. 4, share common steps as illustrated in the flow chart Fig. 6. Content providers 50 create rules for using and selling content via a rules based engine 26; these policies serve as touch points for rules pertaining to a consumer's 60 rights/usage permissions as illustrated in step 204 of the content provider process.

It is understood that content provider steps 200-216, from Fig. 3 are the same as described above. Likewise, consumer 60 steps 300-312 from Fig. 4 are also essentially the same as described above. Fig. 6 illustrates the flow diagram of cross over points between these two processes.

At a first crossover point, a rights management 400 step is provided; content provider's 50 packaging rules from step 204 are generated based on the customer's 60 desired content from step 304. Likewise, options available to customer's 60 at content step 306 are provided based on bundling/re-cataloging step 212 via a catalogue management crossover step 402. Thus, the options available to customer 60 at step 306 are based on knowledge of their interests.

At a next cross over step 404, this knowledge from display presentation step 214 is used to determine user interface (UI) requirements that provide a targeted end-user/customer 60 experience at media experience/consumption step 310. Moreover, at reports crossover step 408, both customers 60 and content providers 50 may utilize reports generated at step 312 which are delivered from System 10 directly to consumers 60 as well as directly to content providers 50. Although reports crossover step 408 is featured at the end of the crossover process, they may be generated at anytime content provider 50 and content customer 60 wish to do so.

It is understood that the above description of a crossover steps shown in Fig. 6 are exemplary and is in no way intended to limit the scope of the present invention. Any similar system using similar functions and/or steps is within the contemplation of the present invention.

The present invention as illustrated in Fig. 1, further supports the processing, management and distribution of digital content. Processing, management and distribution system, System 10, is configured to automate and simplify the backend processing of digital media files on behalf of content providers 50 and their affiliated Web sites 52. The digital content may be supplied to a customer 60 for example, on a DSTB 96 or home computer 94.

In another embodiment of the present invention, as shown in Fig. 7, an Entitlement Engine 17 is provided to work in conjunction with the above described system 10. Entitlement Engine 17 drives a rules creation and management process that enables consumers to access, view and/or purchase a variety of digital media. It interacts with a number of external applications including those that issue requests to access content, licenses and bandwidth. As shown in Fig. 7, the Entitlement Engine 17 may be configured to couple with a media provider's EIS System 12. In this scenario, the media provider's EIS system 12 consists of Billing 14, Operational Support System (OSS) 8 and Customer Relationship Management (CRM) 4 systems. Additionally, Entitlement Engine 17 interacts with a number of other applications including a customer Web Portal 92, digital set top box (DSTB) 96, License Server 95 and Provisioning Server 15, and offer data 11.

As depicted in Fig. 8 the Entitlement Engine 17 preferably includes, but is not limited to, four components, each playing its own role in executing a consumer's entitlement rights. The External Interfaces and Request Handler 500 serves as the inbound interface, the Rule Engine 512, acts as the heart of the invention and consists of 2 sub-components, Controller 502 which is responsible for the engine's workflow and the Validator 504 which is tasked with validating entitlement rules. Additionally, State, Change and Exception Logger 506 records all inbound and outbound requests, and finally the External Data Source Interface 508 handles communications with EIS Systems 12.

External Interface and Request Handler 500 is a set of inbound interfaces that accept entitlement requests. This component supports all protocols related to integrations with other computer applications and parses the entitlement request thereby extracting incoming data parameters. Further, it appropriately marshals and un-marshals each request and responses using the internal common request object that is employed throughout the Entitlement Engine 17. Since Entitlement Engine 17 uses this common data format, it can be configured to listen to and accept requests using any technology protocol.

The second component is Rule Engine 512. This component is responsible for the processing of all entitlement requests. It contains the logic necessary for entitlement decisions as well as the logic that dictates the steps required to gather data for an entitlement decision. Rule Engine 512 encapsulates two logical subcomponents: Controller 502 and Validator 504. At the core of each subcomponent is an internal Rule Engine that provides centralized storage and management of critical business logic. Controller 502 subcomponent uses information on the current state of a request and any available contextual data to determine which step to take next in the workflow.

As illustrated in Fig. 9, there are six workflow states. The starting state 600 is NONE. This is the state of the Entitlement Engine Context object that occurs prior to the setting of any subscriber token data or request-identifying information. The Initialization state 602 is INIT; this is the state of the Entitlement Engine Context object that occurs after the subscriber token data and request-identifying information has been added. Next is the PREVALIDATION state 604; this state of the Entitlement Engine validates the presence and structure of the subscriber token data and request-identifying information it retrieves data from EIS 12 systems. Also, when signifying that data is ready, the READY state 606 is invoked. This state occurs after all data points required for entitlement decisions have been retrieved. Additionally, when a request is processed, the PROCESSED workflow state 608 is generated. Finally, ERROR state 610 is invoked when a processing error occurs during the workflow. In order to make an entitlement decision, Validator 504 subcomponent tests the validity of the request's parameters including any data that was collected in previous steps 600-612. Validator's 504 Rule Engine changes the state of the request based on the results of the validation. If the state of the request is ERROR state 610a or PROCESSED state 608, control is returned to the request handler that initially called the CLE; otherwise, control is passed back to Controller 502 for further workflow processing.

An example of a rule where the state of the request is checked is one that fetches data pertinent to making an entitlement decision. If the request is in the INIT state 602, the request type may be "hasServiceEntitlement," this workflow rule would dictate that the engine first make a request to the consumer profile database to obtain the consumer's entitlement data. Controller 502 would then decide on what other EIS Systems 12 it needed to connect to in order to gather all the data necessary to make the entitlement decision. Controller 502 would finish its execution of this step in the workflow and pass control to Validator 504.

At this time, Controller 502 would be stateless and requests would transition sequentially from an INIT state 602 to a PROCESSED state 608. It is contemplated that such workflow sessions could be modified to support the option of continuation.

Validator 504 may modify or even create data that is returned to the caller. For example, consumer data retrieved by Controller 502 may be examined for rules that determine whether or not the consumer is entitled to view a video at high resolution. If the consumer's data points did not fall within the proper thresholds (as dictated by the rules) the Rule Engine would modify the response so that it contains the URL for a low-resolution version of the requested video. In such a case Entitlement Engine 17 would not provide a simple "yes" or "no" answer; instead, it would add value by providing an alternative response to the consumer's request. Another component of Entitlement Engine 17 is the State Change and Exception Logger 506. This component is responsible for logging application events (asynchronously) from Entitlement Engine 17. State Change and Exception Logger 506 can be configured to accept certain messages or to simply ignore them. If it receives a message, the message is stored in a database. It can also be configured to send messages for any type of event including but not limited to: 1) incoming requests and responses; 2) requests and responses to EIS systems 12; 3) requested state changes; 4) rule engine firings; and 5) application exceptions.

Finally, External Data Source Interface 508 provides the Entitlement Engine 17 with the interfaces required to appropriately request data from the media provider's EIS systems 12. The component handles any necessary session pooling to data sources and maintains the physical connections. It is the only component that adjusts with changes to EIS-specific protocols, their data models and/or integration with additional EIS data stores. Information acquired from EIS Systems 12 is un- marshaled into objects and returned to Rule Engine 512.

Using the components set forth and described above, the present invention aggregates data from a diverse set of applications. It processes entitlement requests based on this data and transfers relevant information back to the requesting application. It securely responds to requests from external applications using flexible adapters and EIS drivers. Further, the present invention is capable of initiating requests for information, e.g. to maintain up-to-date information on entitlement privileges.

In one embodiment, the present invention interoperates with multiple systems; an example situation is one wherein the consumer's DSTB 96 checks with Entitlement Engine 17 to ensure that the consumer is authorized to access content he/she requested. Entitlement Engine 17 requests a license key from License Server 95. License Server 95 takes on the task of requesting additional information about the customer's license rights and generates a license key. The present invention take a consumer's session id and entitlement request and cross-checks this information with entitlements, available offers and licenses in addition to authenticating the consumer's attributes with available EIS Systems 12. It then responds to the consumer's request with an authorization, alternative or decline to each request.

Figure 10 depicts an example of such an entitlement request and approval process.

In a first step 700, a Customer Portal 92 requests content. Next, at an access authorization step 702, the system queries user and account verification information. If access is not authorized, the Customer Portal ^:92 is informed of the denial at step 704. Alternatively, if access is authorized, then at step 706, Customer Portal 92 is allowed to view a menu of entitlements.

Next, at step 708, the customer selects the desired content, a subscriber token is sent and a license key is requested from License Server 95 at step 710. At step 712, Entitlement Engine 17, determines whether or not the consumer is entitled to view the requested digital content. If so, then at step 714, the requested content is delivered. If not, then at step 716 alternative content is explored. If alternative content is desirable/available, then at step 718 it is delivered to Customer Portal 92. Otherwise, a message indicating that the content is unavailable is delivered at step 720.

It is noted that dotted line 722, indicates an alternative scenario whereby Entitlement Engine 17 generates the license or otherwise bypasses License Server 95. Furthermore, it is noted that in one embodiment of the present invention, menu of entitlements from step 706 may not be required for the operation of this process.

The present invention uses a combination of data access and rule engines to ensure that digital content is appropriately presented to the right consumer for purchase; it confirms the purchase of the content and securely protects it from the time of its request to the fulfillment stage. In one embodiment of the present invention, Figure 11 illustrates how a consumer may access entitlements and then obtain the necessary authorization to download the desired content. Actions that can be performed by consumers include, viewing entitlements, downloading content, playing content and adjusting bandwidth.

At a first step 800, the consumer logs onto a portal where he/she may access digital media. Next, at step 802, the consumer's ID and password are validated. At step 804, the Customer Information database or the service provider's billing system 14 is queried to evaluate the customer's entitlements.

Next, at step 806, a menu of the individual entitlements is displayed to the consumer. At step 808, the consumer selects the desired content by clicking onto a URL in the portal menu. At step 810, the Content Delivery system directs the request to the appropriate Content Store. Next, at step 812, using the URL and source IP, the Content Store enables the consumer to download the content, which is downloaded by the consumer at step 814.

Although it is noted that the above-described processes are presented in a particular order, this is in no way intended to limit the scope of the present invention. Any similar group of steps performed in alternate sequences is also within the contemplation of the present invention.

Thus, in one embodiment of the invention consumers are armed with the tools necessary for accessing personalized content and associated entitlement information. For example, it enables consumers to predefine content and schedule it for future consumption. The invention not only tailors authorizations to the type of device, content and/or customer account being utilized, but it is also capable of intelligently suggesting alternate content offerings to a consumer if his/her account is denied access to a particular service or product. Alternate suggestions may be based on product attributes, consumer preferences or other types of configurable information.

In one embodiment of the present invention, as illustrated in Fig. 12, access to built-in context sensitive rule-sets via an intuitive Rule Builder 514 is provided for authoring entitlement policies and collecting customer/product attributes. Rule Builder 514 exposes a subset of the entitlement rules that may be accessible via an extensible and configurable Web-based rules management interface. The rules are written in high-level business language and consist of a list of parameters needed to make a decision. End-users (e.g. a media provider's Systems Administrator) may use existing rules, customize them, add their own conditions if suitable ones do not exist and/or incorporate information from various backend data systems into the rules of Entitlement Engine 17. Entitlement rules may be modified, deleted or saved as templates for future use. Additionally, end-users may set priorities for processing entitlements. Furthermore, these rules may be searched and/or archived based on either predefined or user-defined categories.

Figure 12 illustrates the process of creating an entitlement rule. At step 900, the end-user navigates to the login page of the Web-based rule management console, where he/she at step 902 enters his/her login credentials and selects a rule repository to access. Rule Builder 514 at step 904 authenticates the end-user's credentials against its data store (or rule repository) 516. If authentication succeeds, then at step 906 Rule Builder 514 checks whether or not the end-user has the proper authorizations to access the requested repository. Next, at step 908, Rule Builder 514 retrieves references to rule repository 516 and initializes the Web components at step 910, thereby redirecting the end-user's browser at step 912 to the proper repository viewing JSP page. The end-user is able to modify rules according to his/her permissions. When the end-user is ready to Save, the Save Request step 914 triggers Rule Builder 514, which in turn makes the appropriate API calls at step 916 and stores the changes in rule repository database 516 at step 918.

System 10 of the present invention is designed to support the creation, management and processing of any type of entitlement rule. Typically, an entitlement rule may determine whether or not a customer is eligible to consume a digital file. In one embodiment of the invention, six types or instances of entitlement rules may be created. These rules may or may not share a common set of rules. Also, each instance of entitlement can be managed and administered individually or collectively. Subscriber Entitlement is one such entitlement rule; it is concerned with rules that determine a consumer's eligibility and the right to access based on a subscriber's status at the start of the ordering process. On the other hand, License Entitlement rules are used to determine license parameters that are associated with a specific piece of content. Also, an entitlement rule that may be invoked frequently is an Offer Entitlement as it deals with business rules pertaining to perquisites necessary to view and/or purchase a specific service or product offer, e.g. a sports package specifically tailored to subscribers in a particular geographic location. Transaction Entitlement is another example of an entitlement rule; it may be used to determine whether or not a particular account is capable of making a transaction and/or a purchase. When the request is made for delivery, the Entitlement Engine 17 triggers the logic that fulfills the funding obligation of the consumer. Additionally, Service Entitlement is a rule type that is concerned with accessing content or licenses on previously purchased services and products. This instance of entitlement decides on one's right to ultimately play and consume content. Finally, Access Entitlement may be used by end-users for setting parental-type controls based on the consumer's primary or secondary account status.

To process the rule, information about the consumer (subscriber), the file that was requested (URL) and the type of license that was requested (one-time) is used by the invention. As illustrated in Fig. 13, Entitlement Engine 17 responds to content requests with a (Return Value) and assesses the state of the request (Status) in order to determine whether or not the customer should be given access to the desired content. If the status is granted, the terms under which access was granted is provided; otherwise, the reason why access was denied is explained:

getSubscriberLicenseEntitlements

Arguments

Subscriber: Authentication Token

File: URL

License type requested: Online, portable, one-time, etc.

Protocol: Not required Return Value

Status: denied, granted

Terms: online only, portable, number of plays, expiration date, expiration past, first play

Reason: string.

Security is an integral part of the present invention. The invention is designed in such a way that an end-user's capabilities and performable actions are based on his/her permissions. Thus access to information is based on the identity of the requester and the content. Additionally, data associated with entitlement requests is encrypted while being transferred to and from other applications. Therefore, in view of the forgoing structure and processes, it is understood that that the present invention is responsible for 3 key tasks: enabling entitlement rules creation, processing entitlement requests and furnishing the interfaces for communicating with multiple sources of information in a secure manner. It is a configurable tool that automates the rules management process on behalf of those distributing digital content. The invention's core responsibility is to gather a collection of attributes from a variety of data stores and execute them via defined rule-sets. It provides flexibility in the ways in which rules for content offerings are structured and makes it possible for media providers to easily integrate their applications with external applications while maintaining data integrity. The invention uses its access control, filtering, and intelligent routing capabilities to offer fine-grained content availability based on caller context such as account status, transaction history, content meta-data, and other external business conditions.

Furthermore, the present invention facilitates the creation and management of business rules that determine if a consumer or his/her device has a right to claim the requested offer, digital media, or play capabilities. It provides the mechanisms necessary for end consumers to view entitlement rights as well as access, order and consume content on their own terms. The invention provides increased variety to consumers as it facilitates flexibility in content type, price plan and accessing device. Additionally, it enables them to receive content based on their preferences as well as receive alternate offerings that may be based on criteria deemed valuable to them.

While only certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes or equivalents may be devised by those skilled in the art. It is therefore, to be understood that this application is intended to cover all such modifications and changes that fall within the true spirit of the invention. One embodiment of the invention consists of an Offer Catalogue Management module 20 that provides the mechanisms for creating and managing content offers in a variety of business models. An offer may include none, one or multiple rights and price matrices that may be edited, deleted or otherwise manipulated by end-users. Each offer has attributes that describe how it can be redeemed and what prequalification checks are required for sale. Specifically, an offer consists of an asset, a license (possibly free), a price and an offer availability window.

Fig. 14 illustrates the variables that make up an offer 1000. By building rules around these variables, media providers/content providers 50 are able to govern how their content is used and consumed. For example, they may create limits on assets that are offered, configure bundled offerings, determine the order in which content is played, and/or provide consumers with the ability to transfer content to a selection of pre-authorized devices. This information may be modified to for example, target offerings to particular customers at certain locations. Moreover, consumed offerings (and their associated data) may be traced back to a particular content to assess the long-term salability of the offered content.

ASSETS

An offer 1000 begins as a collection 1002 of titles or assets, such as digital games, movies, music or other such digital content (as illustrated in Fig. 14). For the purpose of this invention, a collection of assets is a group of one or more assets that are combined with relevant metadata (such as an asset's description). Assets and metadata are created and managed in the Asset and Metadata Management module 23 and System Management module 22, described above.

AVAILABILITY

Digital assets are made available within a particular scheduled window. A collection of assets may be locked according to a predetermined schedule or a rotating schedule list may be maintained within the package itself. Prior to setting the availability dates, media providers 50 may use the application's matching capabilities to target digital content to intended consumers or they may base content availability on attributes that are relevant to a subscription to a particular service for example, enabling a consumer to view Showtime On Demand™ because he/she has an existing subscription to Showtime Broadcast™. In either case, every offer requires an availability date; a table of availability dates 1004 is attached to the offer via Schedule Management module 24.

PRICE

Offer 1000 contains data necessary for extracting revenue from content. In one embodiment of the present invention, end-users/content providers 50 can create or modify payment rules and attach them to content offerings or they may select from a variety of modifiable, prepackaged payment rules. Payment rules may be edited, saved or archived. Further, content provider 50 may exercise flexibility in setting up price structures 1006 as illustrated in Fig. 14. Some offers 1000 may for example, allow the digital content to be viewed during a given time period for a fixed price while others may impose restrictions such as limiting the overall number of times content can be played during a specific period of time. On the other hand, some may require consumer 50 to acquire a new license to view a video or allow him/her to view many videos for a flat fee. Offer Catalogue Management module 20 also supports multiple layers of price points within a given offer 1000. Prices may be based on for example, content type, total cost of transaction, consumer's 60 rights and/or date of request. Moreover, it enables end-users/content providers 50 to offer multiple payment methods including credit card, cable bill and online payments.

In one embodiment of the present invention, Offer Catalogue Management module 20 supports a variety of business model templates that can handle a collection of assets 1002 ranging from single point purchases to weekly subscriptions. Supported templates may include: one-time purchase of specific asset/digital content, one-time purchase of asset/digital content where the asset may be executed over a specific number of times, one-time purchase of asset/digital content where the asset may be executed during a specific period of time, one-time purchase of a set package of multiple assets. Further, it enables end -users/content providers 50 to provide offers 1000 that may include details such as:

The option to order a title for a predetermined fee.

For one flat fee: unlimited access to order any title in the catalogue for 30 days.

For one flat fee: unlimited access to order all titles with DRM allowing a 24- hour shelf-life based on download completion time.

Free access: to a subset of titles, including previews of pay per view titles. Free access: to a subset of titles if the customer subscribes to a related media service.

For one flat fee: unlimited access to order a subset of titles for 30 days. For one flat fee: unlimited access to order a theme, genre or series package during a 24-hour period.

For one flat fee: subscription to a sequence of titles delivered 1 or 2 times a week for a set number of weeks. The option to copy selected media to another device.

RIGHTS

Offer Catalogue Management module 20 further enables media providers 50 to employ multiple security and rights layers 1008. Offer Catalogue Management module 20 supports both non-DRM and DRM-based businesses. In the case of the latter, all metadata required for encryption within a DRM system is handled by the present system. End-users/content providers 50 may add, modify, delete or archive rights data. This information may be used to for example, lock available titles so that only those who are entitled may access the desired digital content, end- users/content providers 50 may opt to provide those lacking appropriate access rights an alternate method of subscribing to or accessing desired content. Rights data from rights listing 1008 may be imported from DRM packages or may be selected from a list of preset commands, e.g. allowplay, allow burn and expirationstore.

In one embodiment of the present invention, Fig. 15 is a flow chart of the process of creating and modifying an offer by Offer Catalogue Management module 20, such as offer 1000 discussed above. As a first step, 1100, content provider 50 schedules assets using Schedule Management module 24. This step entails setting up specific date and time intervals to publish assets. Next, at step 1102, whether content should be made available to all users or to specific users is defined by content provider 50. Then at step 1104, the purchase type is selected, content provider 50 may choose from either recurring purchases (subscription-based) or a 1- time purchase. At step 1106, once assets are attached with availability data, content provider 50 selects from a collection of fields representing the flag structures for consumption rights (e.g. canPlay, canBurn).

As a next step, 1108, the price for the offering is determined. At this point in time, content provider 50 is given the option to save the offer as a future template at step 1110 or simply save at step 1112. The offer is then either approved at step 1114 or if further changes are required, the offer is edited at step 1116. Upon approval, Offer Catalogue Management module 20 prepares to aggregate and publish the offer. The necessary licenses are generated at step 1118, then the offer and associated data (content, rights, price and entitlements) are encrypted in step 1120. Finally, after completing the offer, Offer Catalogue Management module 20 delivers the offer to an offer authorization system in step 1122.

Fig. 16 provides an example of an offer 1200 for a single title of a digital content that can be played within 24 hours of downloading; in this scenario, a standard price for all consumers is employed, the content is locked and nontransferable. As illustrated in Fig. 15, sample offer 1200 maintains an availability field 1202, order field 1204, A DRM field 1206, a price field 1208, a time window field 1210 and a content locked field 1212.

The offer modification process, step 1116, is similar to that of the offer creation process, as the same subsequent actions are triggered except instead of entering new offers; the existing data elements are updated. For example, when an offer is updated, Offer Catalogue Management module 20 triggers a series of events: licenses are generated (same as step 1118 and stored, the files are encrypted (same as step 1120) and uploaded to the distribution server, including entitlements, and then the file is made available for public consumption (same as step 1122).

In one embodiment of the present invention, workflow states symbolize an offer's rate of progress as illustrated in Fig. 17. The first is the Available state 1300 which refers to when a new product or digital asset is made available to customers, although it is not assigned to an offer (such as offer 1000). Next, Assigned state 1302, pertains to when a product or digital asset is assigned to an offer (such as offer 1300) but is not available to customers 60. Additionally, Live state 1304 describes a scenario where a product or digital asset is assigned to an offer, is live on System 10 and made available to customers 60. Finally, Expired state 1306 refers to a state in which an offer (such as offer 1000) is no longer live and/or available to customers 60. Offer Catalogue Management module 20 enables media providers to create, edit, duplicate or delete offer workflow states 1300-1306 illustrated in Fig. 17.

Processing, management and distribution system 10 in its entirety, automates and simplifies the backend production and distribution of digital content and enables media providers 50 to manage the digital distribution process from the beginning to end. Offer Catalogue Management module 20 of System 10 allows media providers 50 to define, edit, archive or delete digital content offerings and associated data. Further, it enables the tracking of the lifecycle of digital offers and allows end- users/content providers 50 to manage and securely distribute targeted digital media offerings using a rules-based architecture.

Offer Catalogue Management module 20 provides built-in mechanisms for making available multiple offers, across price points, availability dates and usage rights; further, it simplifies the process of modifying these offers, thereby making it easier to manage high-volume content offers. Moreover, the ability to correlate existing offers directly to a single piece of content gives media providers a level of abstraction required to report on offers. As such, Offer Catalogue Management module 20 enables media providers to manage the complexities that are inherent in creating, selling and supporting content offers in today's digital entertainment market.

While only certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes or equivalents may be created by those skilled in the art. It is therefore to be understood that this system and method is intended to cover all such modifications and changes that fall within the true spirit of the invention.

Claims

1. A method of interaction between content providers and consumers on a communication system, said method comprising the steps of: acquiring and managing digital media assets for distribution to consumers through said communication system, wherein a workflow for distributing said digital media assets is managed through said communication system; acquiring profile and preferences data facilitating the consumption of said digital media assets; wherein said digital media assets are transacted upon through said communication system; and adjusting said management of digital media content and said digital media assets by said content providers, for delivery through said communication system based on content provider rules, consumer preferences, media type and said consumer's device.

2. The method as claimed in claim 1, wherein said step of acquiring and managing digital media assets includes said content provider's agreement to redistribute or sell digital media assets themselves wherein said content providers acquire said digital media assets from a third party for the purpose of re-licensing and redistributing through a direct communication channel.

3. The method as claimed in claim 1 , wherein said step of acquiring and managing digital media assets further comprises the step of formatting, encoding, compressing and securing said digital media assets, creating or modifying metadata, and the storage of said digital media assets.

4. The method as claimed in claim 1, wherein said step of acquiring and managing digital media assets includes scheduling and licensing of said digital media assets using said communication system so as to deliver said digital media assets to said consumers based on consumer preferences and rights/usage permissions.

5. The method as claimed in claim 4, wherein said rights and usage permissions for purchase, download, and using said digital media assets are enforced by either one of a single or a multiple network device that executes content provider or operator's specific business requirements and data, wherein said digital media assets are subject to license restrictions that are communicated to any one of a license, certificate, or media server.

6. The method as claimed in claim 1, wherein said digital media assets are available through catalogue options, including bundling or re-cataloguing of said content provider's digital media assets based on packaging rules, said packaging rules being based on said content provider's business model, marketing campaigns and promotions.

7. The method as claimed in claim 6, further comprising the step of cataloguing of said digital media assets such that varying catalogue options are provided to said consumers by said content providers based on consumer preferences and a history of their selections.

8. The method as claimed in claim 7, further comprising the step of determining how said catalogue options are displayed and arranged thereby creating a targeted consumer experience that affects how said digital media assets are consumed and transacted upon by said consumer.

9. The method as claimed in claim 1, wherein said step of acquiring and managing digital media assets includes the organization and location of said digital media assets in a distribution process so as to facilitate said content provider's ability to review search and categorize offerings of said digital media assets.

10. The method as claimed in claim 1, wherein said step of acquiring and managing digital media assets includes the organization and location of said digital media assets in a distribution process so as to facilitate said content provider's ability to communicate and interact with external systems and processes.

11. A system for managing digital content comprising: an entitlement engine, said entitlement engine having an external interface and request handler configured to handle inbound entitlement requests, parsing them to extract the necessary entitlement data parameters of the request; a rule engine, coupled to the external interface and request handler, configured to review and make entitlement decisions regarding the availability of a particular digital content that has been requested; and an external data source interface configured to interface with subscriber profiles at said media provider to equip said rule engine with the necessary information to process said entitlement request.

12. The system as claimed in claim 11 , wherein said entitlement engine further comprises a request, state change and exception logger configured to record entitlement request operations including any one of incoming requests and responses, requests and responses to EIS systems, requested state changes, rules engine firings, and entitlement application exceptions.

13. The system as claimed in claim 11, wherein said rule engine further comprises a controller configured to utilize information on a current state of an entitlement request to determine which step to take next in an entitlement request process.

14. The system as claimed in claim 11, wherein said rule engine further comprises a validator configured to change the state of the request from pending to accepted based on the results of the validation.

15. A method for managing digital content, said method comprising the steps of: at a offer catalogue management module, determining what digital content assets to offer to consumers based on information from content provider; scheduling said digital content assets using a schedule management module in order to set up specific date and time intervals for said digital content assets; determining the availability of said digital content from said content provider; determining the price of digital content from said offer obtaining approval of said offer from said content provider; publishing said offer; and delivering said offer to said consumer for possible purchase.

16. The method as claimed in claim 15, further comprising the step of, after obtaining approval of said offer, said content provider saving said offer as a template for future offer generation.

17. The method as claimed in claim 15, further comprising the step of after publishing said offer, obtaining the necessary licenses for distributing the digital content assets in said offer.

18. The method as claimed in claim 15, further comprising the step of prior to delivering said offer, encrypting said offer and said digital content assets and all related data.