CROSS REFERENCE TO RELATED APPLICATIONS
FIELD OF INVENTION
This application is a continuation of U.S. patent application Ser. No. 10,411,819, filed on Apr. 9, 2003, now pending, the disclosure of which is incorporated herein by reference.
Embodiments of the present invention relate to Digital Rights Management (DRM) and digital asset security. In particular, embodiments of the present invention relate to a computer-implemented method and system for brokering the flow of DRM-protected content in a framework that specifies how the publishers, brokers, distributors and end-users of the content interact for interoperability among incompatible DRM formats.
The internet and other networked computers have dramatically changed the way in which digitized assets such as music, films, books, documents and streams, referred to herein as content, are produced, distributed and consumed. For example, downloading content from the internet has gained widespread acceptance among computer-savvy users because it provides immediate access to content without requiring a trip to a store to purchase physical media containing the content such as a CD or a DVD. However, due to the ease with which content can be downloaded, owners of commercially valuable content are very reluctant to place content on the network in the absence of adequate safeguards for fear that the content would be pirated and used unlawfully.
However, as the market for commercial content evolves and as owners of valuable content explore ways to enable different business models for content distribution to end-users, increasingly the publishers are motivated to place high premium, high-valued content on the networks despite the potential for piracy and unlawful use. In this regard, the publishers are encouraged by the availability of various e-commerce systems capable of encrypting the content in a format that is secure for distribution to licensed end-users. In these e-commerce systems, a critical component is digital rights management (DRM).
DRM is a set of technologies useable for protecting content while allowing the publisher of the content to maintain close contact with end-users. With DRM technology, content is encrypted in a format that allows only for a licensed user to access the content. Generally, access is provided by a decryption key obtained from the publisher under a license. With DRM technology, publishers can place content on the network with some assurance that the content will be secure and that its distribution and sales will be properly administered.
In general, a publisher creates media content using an unencrypted format, e.g. CODEC. The publisher then selects a particular DRM system and its associated encryption key and algorithms for encrypting the content and information associated with the content. For example, the encrypted content is packaged in a meta-data format that includes a reference to a license agreement that authorizes distribution of the content to a licensed end-user. For the end-user to access the DRM-protected content, he must use a DRM-enforcing playback software key obtained from the referenced license.
Presently, many commercial products embodying DRM-protection methods are available for use in protecting content. A common goal of these methods is to provide protection in accordance with rights granted under a license by the publisher of the content. In protecting and distributing content, there is an intricate framework connecting the content with the management of the content including the use of encryption keys, authentication methods, end-user identity, device identity, payment and other electronic commerce functions. Several DRM vendors including IBM, Intertrust, Microsoft and Cisco have published portions of their DRM framework presumably to encourage widespread use of these proprietary DRM-protection methods.
A problem arising with the proliferation of proprietary DRM-protection methods is that since the methods are not based on any common DRM standard, content protected by one DRM method usually cannot be accessed by anther DRM method. This incompatibility has led to a significant fragmentation in the market with the result that publishers and end-users, interested in publicizing protected content as widely as possible are left with an unattractive set of choices.
One possible choice is for the end-users to become familiar with several of DRM-protection methods in anticipation that they will purchase a variety of DRM-protected content; alternatively, the publishers could publish the content under several DRM-encrypting formats in the hope that such coverage be adequate for their target markets. Yet another possibility is that, by consensus the vendors will cooperate to develop DRM-based products that comply with a common DRM standard.
In the present competitive environment it is not likely that a common DRM standard will be evolve in view of the perception that each vendor, besides providing the DRM product, is also seen to be providing a partnering services to assist the publishers to market the content in a target market. For example, in marketing protected content, one DRM vendor may be perceived as more desirable by a publisher because that vendor provides a good design choice for high-value lower-volume content; similarly, another vendor may be perceived as more desirable because it provides good a design choice for low-value higher-volume content for another target market.
- SUMMARY OF INVENTION
Accordingly, in protecting content on computer networks, there is a need for a better way to allow for interoperability such that content protected by a DRM format can be accessed and used under another DRM format without jeopardizing the rights of the publisher, or diminishing the obligations of the end-user.
BRIEF DESCRIPTION OF DRAWINGS
Embodiments of the present invention provide a computer-implemented method involving the use of a broker to transform the DRM-protected content into a plurality of DRM-protected formats for widespread distribution. In one embodiment, the present invention comprises providing a DRM broker to act as a proxy for the publisher interested in publishing the content in a plurality of DRM-protected formats. The content and content information comprising encryption keys, transaction logs, licenses, payments and payments receipts are received from the publisher at the DRM broker. The content and content information is transcoded into a plurality of DRM-protected formats utilizing the DRM broker. The plurality of DRM-protected formats is then distributed. The present invention also provides for a computer-implemented system and a computer-useable medium for practicing the invention.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:
FIG. 1 is a flowchart diagram illustrating steps of an exemplary process for generating DRM-protected content, in accordance with one embodiment of the present invention.
FIG. 2 is a flowchart diagram illustrating steps of a DRM brokering process in accordance with one embodiment of the present invention.
FIG. 3 is a schematic illustrating a database employable in DRM brokering in accordance with one embodiment of the present invention.
FIG. 4 is a block diagram of an exemplary computer system platform upon which embodiments of the present invention may be practiced.
DETAILED DESCRIPTION OF INVENTION
FIG. 5 is a block diagram of an exemplary system upon which embodiments of the present invention may be practiced.
The present invention is a framework for brokering the flows of DRM-protected content and information pertaining to the protected content comprising encryption keys, transaction logs, payments and payment receipts, available initially in either a non-protected format or in a DRM-protected format. The framework specifies how publishers, the DRM-broker, distributors and end-users of the content can interact for mutual benefit using DRM technology to protect and market the content.
FIG. 1 provides a brief, general description of an exemplary process 100 for generating DRM-protected content. Those skilled in the art will appreciate that in practice, process 100 illustrated in FIG. 1 is performed with greater particularity by using, for example, computer-executed software modules that includes routines, programs, objects, components, data structures, etc., to execute particular tasks for generating DRM-protected content. For the present purposes, however, the exemplary DRM-protection process of FIG. 1 includes step 101 whereby a publisher, using generally available coding software e.g. CODEC, creates content in an unencrypted format on a selected media. At step 102, the publisher selects a particular DRM-protection method with its associated encryption key and algorithms, and encrypts the content and information in the DRM-protected format. The encryption includes creating a media encryption key, and encrypting the media using a compatible algorithm and the key, and packaging the content with an meta-data envelope that authorizes the use of the encrypted content. In one embodiment, the DRM-packaged content contains the encrypted content and a header (e.g. the meta-data envelope) containing a URL or other identifying reference. The reference refers to a server on the Internet that operated by the publisher or distributor, wherein the server is operable to interact with the client player (e.g., the end-user) to create a license. It should be appreciated that the meta-data refers to the publisher's licensing authority or license server.
Subsequently, the encrypted DRM-protected content is distributed to end-users, as shown at step 103. In some situations the DRM-protected content is distributed to the end-users before they are licensed; they may never be licensed and may never use the content. In other situations, users get licensed but do not actually take delivery of the license until after they get the DRM-protected content. In others, they may get their license and get the content later. It should be appreciated that an end-user may obtain a license for DRM-protected content at any time, and is not dependent on the distribution of the DRM-protected content itself.
At step 104, a license is granted to the end-user based on a transaction between the end-user and the publisher's licensing authority. In one embodiment, the license comprises a DRM-enforcing playback key. Access to the DRM-protected content (or presentation and display of the content) is performed by some DRM-enforcing software. For DRM-enforcing software to be enabled to provide access to the content, there must also be available a license for the content, and the license normally contains some decryption key. At step 105, the end-user is provided access to DRM-protected content by the DRM-enforcing playback software key provided under the license. Thus, for an end-user to access the DRM-protected content, he must use a DRM-enforcing playback software key authorized under the license.
As an aid in understanding the invention, it is useful to consider further how a proprietary DRM system, referred to herein as “CPX”, is used to protect content. Suppose that CPX is the system that a publisher uses to protect content in a DRM-encrypted format. CPX could be, for example, Adobe's eBook system, or Microsoft's DRM system, or any similar systems. For end-users to access the DRM-protected content they must use a decrypting device authorized under a license. The decryption device, usually in the form of software, is constructed such that at least in the absence of sophisticated piracy efforts, it decrypts the content only if it obtains a decryption key from a local key cache which is loaded with a digital license and is authorized by the publisher consequent upon a payment and licensing transaction between the publisher and the end-user.
While the above-described scenario using CPX will be adequate for those publishers and end-user interested in protecting content in only one DRM-protected framework, for others interested in having the content available under several DRM-protected formats, the above scenario will be inadequate as may be appreciated by considering the following scenarios. Suppose an alternative DRM system, “CPX1”, is widely used in a geographic region to protect content, e.g. Asia or North America. Suppose also that a publisher has initially created a very popular work such as an eBook under the CPX format and is interested in marketing the eBook in the CPX1 format. Unless the publisher's CPX's format is compatible with CPX1, the publisher would not be able to pursue the opportunity in the CPX1 format. Similarly, potential opportunities can be lost if, for example, content is generally published under a DRM system, e.g. “CPX2” that works only with a Microsoft's desktop document display software popular in a particular geographic region, but the publisher's existing computer systems are only configured and prepared to perform DRM-protected publishing in the CPX framework, not in another DRM framework. These examples illustrate a fragmentation problem caused by the proliferation of proprietary DRM systems that leaves publishers and consumers with an unattractive set of choices to make.
As previously noted, a solution to the fragmentation problem is for the end-users to learn a variety of DRM formats for anticipated use with a variety of DRM protected content. Alternatively, the publishers could publish in more than one DRM format depending on the target markets. A third possibility is that DRM system vendors will collaborate to produce products that conforms to a single DRM standard; but, as previously noted, in the present business environment standardization will not likely occur in view of the perception that the value of a DRM vendor's offerings not only provides DRM-protection technology, but also provides a partnering service that enables the publishers to successfully market their content. Hence, none of these solutions is adequate to address the problem of fragmentation and proliferation of incompatible DRM-protected formats.
Embodiment of the present invention address the above-noted fragmentation and incompatibility problem by providing for a DRM broker whose role is to act as a trusted proxy for a publisher interested in creating multiple DRM-protected from one content created in one framework that he understands and is happy with, say CPX1, but wants to address a larger market opportunity for the content than the CPX1 format by itself makes feasible. This objective is achieved by process 200 of the invention as set forth in FIG. 2. At step 201 there is provided for a DRM broker capable of transcoding content from one format into one or more alternative DRM-protected formats. At step 202, the process provides for receiving the content at the broker. At step 203, using the broker transcoding the content into one or more DRM-protected formats. Thus, with the present invention, regardless of the technical limitations of one format, e.g., CPX1 and regardless of the penetration and/or installed-base of CPX1, the publisher of the content can reach end-users interested in acquiring content under a competing DRM-protected format such as, for example, CPX2 and CPX3 using the DRM broker of the invention. For the DRM-broker to provide this function it must address four considerations.
First, the DRM broker must operate concurrently on all the computing systems required for each of the N different DRM frameworks. In one embodiment, the N different DRM frameworks might all run on a single computer. In another embodiment, each system may require several computers in each of several locations, so that the total number of servers involved is large. In another embodiment, there are at least N license servers, one per DRM system, wherein each of the N license servers is configured to communicate with a key-escrow and signing system.
Secondly, since the DRM broker of the invention must ensure a secure, high-integrity key-escrow system, the broker must create and track a variety of keys as required for each of the N DRM systems on behalf of several publishers and their content. In principle this can be achieved using a very secure key-database system with a schema well known in the art for supporting a relational data base system. Such a system typically comprises rows and columns containing information pertaining to several variables of the content, for example, the publisher, the DRM, the keys, the policies of the publisher and other pertinent information. An example of such a relational database table 300 in simplified form is shown in FIG. 3. This table comprises rows and columns wherein Column 1 contains, for example, information as set forth above, and Column 2 contains attributes of this information. It will be appreciated by those skilled in the art that table of FIG. 3 is very simplified representation of well known relational database systems generally available to implement this invention.
In practice, since the publishing keys safeguard a wide range of content belonging to different publishers, some of whom are acting as limited agents of other publishers, authors and musicians, the database will require other tables describing what key-management policy each publisher has requested for each piece of content, what DRM systems the publisher has authorized for that content, and also that the keys are not to be stored in the same database, but rather is stored in some other key-escrow system operated by a different entity who would hold the keys and continuously fulfill the DRM-broker's requests to sign new licenses using those keys. This kind of key escrow would help enable the publisher to audit the broker and comprise procedures that, for example, would ensure that keys are kept in separate, secure databases; that licenses are signed on demand; that every signature action is securely logged; that a trusted auditor, not a DRM broker, operates and vouches for the system's log integrity; and that logs are available for the publisher for license audit, etc.
Thirdly, the DRM broker would likely want to define a common inter-DRM log format system into which all usage transaction logs and payment logs from each of the N DRM systems could be converted. For scalability reasons, the logs from the various systems operated by the DRM Broker would probably never be merged and aggregated together, but each log fragment would be converted into the common format, sorted by publisher-id and/or content-item-id, and then sent to be merged with other log fragments for each of the broker's publisher-customers, then to be converted into the format chosen by the publisher, for example log formats from a particular DRM system, and made available to that publisher. In this system, various DRM systems; log entries can be converted into a common format covering all fields from all DRM systems; however, although the conversion to a single system log is possible, and the publisher can consume content in any format, the conversion may occur with some information loss.
Fourthly, the DRM broker must have a means for taking content from the publisher and re-publishing it in each of the N different DRM systems that the publisher desires. If the publisher trusts the DRM-broker sufficiently, then the content can be provided to the broker in an open format not necessarily a plain text format, but in a non-DRM-protected format. If the content is encrypted, it could be shared by public-key encryption between the publisher and broker. If the broker is trusted and can get the content in open format, then the broker can publish the content into each of the alternative formats using their respective procedures. With presently known DRM systems, the publishing system requires the content be available in open format with some form of identification, an encryption keys, and other meta-data that can, in most cases, be embedded into the DRM-protected form of the content. In this instance the DRM broker will attach the meta-data information identifying himself or a publisher-specific alias of himself as the publisher, and additional meta-data tags referencing the key-escrow database that the broker uses to act on behalf of the publisher, in addition to content-identifying information supplied by the publisher with the content.
To achieve more complete compatibility with the publisher's systems, or to deal with possible distrust of the broker, the broker can accept the content from the publisher in the DRM-protected format used by the publisher. Under these circumstances, the broker will have a fifth problem to solve, which is how to break open the publisher's format to convert it into an alternative format. This consideration, referred to herein as “digital asset security transcoding”, may not be solvable for all source and target formats. However, there are several cases that are feasible and practical, as summarized below:
(1) The format is breakable: Where the publisher's format is known to be breakable through attacks by, for example, brute-force computation, key cracking, known plain-text attacks, or whatever, it is probably useful and practical for the broker to do this as part of the content-conversion service provided to the publisher. For example, the publisher might want the brokering/conversion service precisely because his chosen method, CPX1, is now considered vulnerable and therefore obsolete. Hence, the publisher is not using CPX1 for publishing to consumers, but it is still convenient to do so in business-to-business (B2B) transactions with his broker(s). Since CPX1 is now easy to crack, the broker does this, opens the content, and republishes it in superior DRM format. Similarly, the broker could crack the content and republish it in the framework of CPX1, but using a newer more powerful cipher, or a larger key size. This scenario is analogous to using an SSL-acceleration appliance to use strong ciphers for external SSL, but use weak ciphers for performance reasons and backward compatibility with existing servers in a data center. Examples of candidates for such treatment include Adobe eBook, DIVX, and many other existing low-grade DRM-enhanced formats.
(2) The format is licensable: Where the publisher's format is a public framework, or where its decryption methods are licensable, for example under license, L1, available from a vendor, the broker can accept the content in the publisher's format, then obtain a limited-use license, L2, from the publisher (e.g., the broker's customer), and perform a decryption to obtain the content in open form. In this instance the broker might be violating the terms of license L2, but it would be appreciated that the broker and publisher would want the broker to obtain, in license L1, sufficient permission from the DRM system licensor, to permit a decryption to expose the content in its original digital format. Whether this is possible might depend on competitive aspects of the licensing strategy, but it seems likely to be possible for most formats that aspire to support desktop content consumption, and certainly for any DRM system where the publisher can issue the broker an L2 license for unlimited use including full-fidelity, all-digital content, ability to print, reuse, etc.
(3) If the publisher format, for example, CPX1, and the target format, CPX2, support the same encryption cipher, then the broker can convert the DRM-protected content from one format to another without the necessity of decrypting the content to obtain an open or plain text format. In this instance, only the envelope, meta-data, and key and license details must be re-created for the DRM system in CPX2 format, and doing so may require access to the secret keys used to encode the content into CPX1 format initially. Often, however, the conversion could be done without those keys, but the step of issuing a new limited-use license within DRM system in CPX2 will require access to the master encryption key. In this scenario, the DRM broker could handle the conversion and publishing steps, but have the license-issuing step be performed by a third-party auditor who operates a license-signing system under contract with the broker and according to the broker's specifications, but guarantees access to complete transaction logs any time the publisher wants to audit the broker.
(4) If the broker cannot perform any of the above, the broker could resort to a scheme whereby the broker obtains an unlimited-use license L3 from the publisher, takes the publisher-protected content, CPX1 and L3 together, and puts them through the publishing process for another DRM system CPX2. This will always work, but requires that when a consumer using system CPX2 receives the content, their desktop will have to do a double-decryption, and the broker would have to arrange to configure its CPX2-compatible content packaging to automate the process of doing the CPX1 decryption for the consumer. This complexity could reduce the value of the brokering function, and thus is only be practical on high-performance desktop endpoints. This scenario of double-encrypted content is probably not a preferred operational mode for the broker.
- Exemplary Hardware Upon which Embodiments of the Present Invention May be Implemented
The present invention thus advantageously enables publishers to stick to a favorite DRM scheme in initially formatting their content, but subsequently allows for the broker to re-publish the content in a variety of other formats.
Refer now to FIG. 4 which illustrates an exemplary computer system 400 upon which embodiments of the present invention may be practiced. In general, computer system 400 comprises bus 410 for communicating information, processor 401 coupled with bus 410 for processing information and instructions, random access (volatile) memory (RAM) 402 coupled with bus 410 for storing information and instructions for processor 401, read-only (non-volatile) memory (ROM) 403 coupled with bus 410 for storing static information and instructions for processor 401, data storage device 404 such as a magnetic or optical disk and disk drive coupled with bus 410 for storing information and instructions.
In one embodiment, computer system 400 comprises an optional user output device such as display device 405 coupled to bus 410 for displaying information to the computer user, an optional user input device such as alphanumeric input device 406 including alphanumeric and function keys coupled to bus 410 for communicating information and command selections to processor 401, and an optional user input device such as cursor control device 407 coupled to bus 410 for communicating user input information and command selections to processor 401. Furthermore, an optional input/output (I/O) device 408 is used to couple computer system 400 onto, for example, a network.
Display device 405 utilized with computer system 400 may be a liquid crystal device, cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters recognizable to the user. Cursor control device 407 allows the computer user to dynamically signal the two-dimensional movement of a visible symbol (pointer) on a display screen of display device 405. Many implementations of the cursor control device are known in the art including a trackball, mouse, joystick or special keys on alphanumeric input device 406 capable of signaling movement of a given direction or manner of displacement. It is to be appreciated that the cursor control 407 also may be directed and/or activated via input from the keyboard using special keys and key sequence commands. Alternatively, the cursor may be directed and/or activated via input from a number of specially adapted cursor directing devices.
FIG. 5 is a block diagram of an exemplary system 500 upon which embodiments of the present invention may be practiced. As depicted in FIG. 5, system 500 includes a DRM broker 540 communicatively coupled to publisher 510 and third party auditor 520 via a distributed computer network 530. DRM broker 540 functions as the central communications point for the DRM brokering operations. In one embodiment, DRM broker 540 performs a method for brokering DRM-protected content (e.g., process 200 of FIG. 2). Publisher 510 and third party auditor 520 communicate with DRM broker 540 via the communications protocols of distributed computer network 530, hereafter simply network 530. DRM broker 540 conducts the DRM brokering operations based on the content as received from publisher 510.
It should be noted that the embodiment of the present invention depicted in FIG. 5 (e.g., system 500) is implemented as a software based process executing on the computer system platform of DRM broker 540. The basic components of the computer system platforms are shown in the example computer system 400 of FIG. 4.
Referring still to FIG. 5, network 530 includes well know network technologies. For example, network 530 can be implemented using LAN technologies (e.g., Ethernet, Tokenring, etc.), the Internet, or other wired or wireless network technologies. The communications links between exchange DRM broker 540, publisher 510, third party auditor 520 and network 530 can be implemented using, for example, a telephone circuit, communications cable, optical cable, wireless link, or the like.
While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments but rather be construed in accordance with the following claims.