Note: Descriptions are shown in the official language in which they were submitted.
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
1
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
2
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
3
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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).
4
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
6
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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;
7
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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;
8
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
9
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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 On-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.
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
9. 1 ags: tmbedded 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.
11
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
12
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
13
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
14
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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 3rd 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
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
16
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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 10'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
17
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
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
18
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
19
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
21
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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 us~)ge. 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
22
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
23
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
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
24
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
26
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
27
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
28
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
29
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
31
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
32
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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 ilfustrated 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,
33
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
34
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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:
getSubscriberLicenseEntit/emen ts
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.
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
36
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
37
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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 DemandTM because he/she has
an existing subscription to Showtime BroadcastTM. 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
38
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
39
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
41
CA 02596968 2007-08-03
WO 2006/073543 PCT/US2005/039130
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.
42
