KR101350104B1 - Method, system, and device for license-centric content consumption - Google Patents

Abstract

To access the data in order to govern the use of the content and to communicate with the unique interface of the existing DRM system, with an existing digital rights management (DRM) system having a unique interface to its own repository of data to govern content usage. A configured shared license repository, configured to interact with the existing DRM system, and configured to allow a user to send a license associated with the content from the shared license repository to the existing DRM system or another shared license repository. Disclosed are a method, system, and apparatus for license-driven content use or distribution that includes a user interface.

Description

METHOD, SYSTEM, AND DEVICE FOR LICENSE-CENTRIC CONTENT CONSUMPTION}

FIELD OF THE INVENTION The present invention relates generally to digital rights management and, more particularly, to methods, systems, and apparatus for storing, accessing, and managing licenses for digital content.

In the early days of computer use, the consumer's mindset was an "application oriented" way. For example, when a consumer wants to consume digital content, the consumer first opened a suitable application such as a word processor. After that, the consumer has accessed the content that he wants to consume from within the application.

The current state of the art is creating a "content-oriented" mindset. For example, when a consumer wants to consume digital content, the consumer double-clicks a file containing the content in his file system explorer to launch the associated content consumption application. The right to consume content is tied to the specific implementation of such content. For example, the right to watch a movie is associated with physically owning a DVD. If the content is protected by a Digital Rights Management (DRM) system, the use of that content is based on using the particular DRM system originally used to protect the content. For example, if a consumer has purchased a license for content from Company A, the consumer must have Company A's DRM system installed on the consuming device to consume that content.

[0004] Most DRM systems on the market today have one thing in common: the content owner or content distributor enforces usage rules as outlined in the license. The license may be embedded in the content or may be a separate license that is readable by a machine or person, such as clicking through through a license agreement or legal agreement. The DRM system understands the license to see how the consumer is allowed to process the content and restricts the consumer from doing things that are not allowed. The mechanisms that various DRM systems use to implement such tasks are very different. For example, many DRM systems express, store, and maintain licenses exclusively. Typically, a consumer acquires a DRM system and requests content that is supplied to that system. The content instance is then prepared by encryption or formatting that allows the content instance to be used only with a particular DRM implementation in conjunction with other trust and security techniques. In the case of a digital license, the license is typically stored in a proprietary repository of the DRM system or as part of the content.

Associating the consumption of content with a particular combination of consuming application, consuming device, and / or DRM system places a limit on the consumer's buying and consuming habits. However, consumers may choose different formats (e.g. DVDs, redbooks, etc.) for various devices (e.g. PCs, home media centers, set top boxes, car stereos, mobile phones, portable media players, devices that establish networks with remote points, etc.). Redbook audio, computer DVDs, streaming, and the like are desired to be purchased from a variety of sources (eg, brick and mortar stores, satellite / cables, internet downloads, etc.).

[0006] The DRM system protecting the content does not exist in the future (eg, for an expired DRM system), the company goes bankrupt, or the DRM system is incompatible with the device the consumer wants to use to consume the content, or (Eg, in the case of a platform limited DRM system), the consumer may be reluctant to purchase the content. There are many cases where a consumer has a device capable of rendering content but that device may not have the required DRM system.

Also, the consumer may be reluctant to purchase the content because a format or medium that may currently use the content may be replaced by a higher format or medium (eg, the DVD may be replaced by a higher definition DVD). However, consumers do not want their purchases to be outdated and need to repurchase the same content in the future.

A consumer must install, manage, and interact with a combination of consumer devices, consumer applications, and DRM systems in order to use their content, which is a heavy burden on the consumer. For example, the consumer's experience in using such content whose rights to the content are managed by a particular DRM system is unique to that DRM system. Since each license is stored in the private storage of the DRM system that generated it, the consumer cannot get a list of all the licenses he has purchased. If a consumer has licenses built for four different DRM systems, that consumer has four unique experiences in interpreting, managing, and using those licenses.

The consumer also wants all content to be available to any suitable device capable of rendering that content. The consumer also wants to purchase the content once and then be able to use the content at any time in the future. The content owner wants to make his content accessible to the consumer according to the usage rules specified in the license. Content owners and consumers do not want to be tied to a specific DRM system. DRM should not be a barrier to that goal. The fact that current "content-centric" mindsets create such a barrier is damaging to content owners because it limits consumers' intention to purchase content.

In an effort to address some such issues, attempts are currently underway to promote interoperability between DRM systems. Interoperability between DRM systems allows consumers to access content in their chosen location, time of day, and the format of their device, provided that such rights are granted by the content owner or content distributor as long as it is successfully implemented. something to do. Consumers feel like they own the digital content they purchased because they can use it anywhere at any time, regardless of the DRM system or version used to enforce that license. However, there are some barriers to implementing DRM interoperability in an ad hoc fashion. For example, with regard to multiplicity, establishing a proprietary relationship between several DRM systems becomes a matter of N-factorial for every permutation.

With regard to security, the DRM system provides different levels of enforcement. If the content can be moved to any compatible DRM system, there is a potential for security issues. Consumers may move all their content to the least secure system to take advantage of low-level enforcement. It promotes the environment in which the least secure DRM system is most widely used.

With respect to usage rule support in a license, the DRM system enforces various sets of licensing conditions. Again, if the content can be passed to any compatible DRM system, there is a potential for security issues. For example, a consumer may move content from a DRM system that allows for a daily rental to use the content beyond the daily rental to a system that does not support the daily rental constraint.

Regarding the presentation of usage rules, the DRM system uses a different mechanism to specify the usage rules specified in the content. For example, some DRM systems may apply a fixed set of rules to all content types and / or instances, and some DRM systems may apply usage rules to content on a per instance basis. DRM systems that apply usage rules to individual content instances differ in their ability to express the type of usage rules. For example, a DRM system called A may allow a content owner to specify that content can be viewed but not copied. On the other hand, a DRM system called B may provide the same capabilities but allow the content owner to specify that the content can be played only once. The DRM system, called C, can also use the language to provide more flexibility in the representation of usage rules. Differences in the requirements and capabilities of different DRM systems in expressing usage rules make implementation of interoperability difficult.

Regarding the user experience, each DRM system has a proprietary user interface that the consumer uses to interpret, consume, and catalog the content that they have accessed. Thus, the user experience is inconsistent throughout the DRM system.

With respect to license acquisition, when a consumer wants to license a content, the license provider must know the DRM system, format, to provide content that is compatible with the combination of content, device, and DRM system.

By creating interfaces, including standard DRM systems, content formats, client / server communication protocols, content protection methods, content identification methods, rights expressions, and interoperable points that allow content to be exchanged between various compatible DRM systems. There are standards groups such as ISO MPEG-21 and Open Mobile Alliance (OMA) that wish to implement DRM interoperability. ISO MPEG-21 REL Working Group, TV-Anytime Rights Management and Protection Group, ISO, which focuses on establishing a common rights expression (REL) as the primary means of implementing interoperability. There are other standards groups such as SC36, the IEEE Learning Technology Standards Committee, and the Open eBook Forum (OeBF) Rights and Rules Working Group. Standardization of the REL is similar to standardizing a common message exchange format. The advantage is that all compatible systems can communicate with each other in an interoperable manner, exchanging and sharing licenses, and that the compatibility cost is lower than that of a complete DRM system, and that the message (REL) is distributed to platforms, designs, and implementations. Neutral and do not define them specifically. Such an approach allows technology providers with different platform agendas to compete with the same qualifications while maintaining sufficient interoperability.

While it is true that such various standardization efforts can address some of the major barriers listed above, many major barriers still remain. For example, with regard to establishing standards, it is necessary for standardization that all participants in the value chain, from content owners to rendering device manufacturers, to agree on system requirements, which is complicated to derive. It is very difficult to create a DRM system. Each content owner has its own requirements for security level, usage rules required for licensing, and so on. Device manufacturers may be reluctant to enforce licenses because the inconvenience may impede their willingness to purchase. It may also limit the functionality that differentiates its manufacturer from other competitors. In addition, not all business models require the same level of security or usage restrictions. For example, commercial commercial content requires watching embedded commercials, while distribution of audio MP3s requires restrictions on duplication. Although standards are established, they will tend to address market segments that share common security requirements. Ad hoc interoperability across market segments will continue to be a problem.

Regarding international support, it is almost impossible to create a standardized DRM system globally, as it is difficult to create a standardized DRM system for one country and its intellectual property laws. To do so, it is necessary for all countries to agree on intellectual property laws and processing laws.

Regarding the life cycle, like most digital entities, the license has a life cycle. Licenses are created, used to create new licenses, become invalid, expired, revoked, exercised, transferred, shared, and so on. While expressions of interoperability rights are useful in creating interoperable DRM systems, they do not provide the necessary functionality to enable such systems to participate in the full lifecycle of digital licenses.

Due to such and other difficulties, the best thing to expect is to create a DRM standard for a given market in a given country (eg, a DVD movie in the United States). Thus, in current DRM system implementations, consumers have no choice but to deal with multiple DRM system and DRM interoperability issues.

Accordingly, a method and apparatus are needed to address the above and other problems in accordance with conventional content centric systems and methods.

Such and other needs can be effectively utilized and methods, systems, and devices that can significantly improve the consumer experience by promoting a "license-centric" approach to digital content distribution and rights management. Provided by exemplary embodiments of the present invention. The example shared license repository can be configured to implement a sufficient set of lifecycle functions (eg, including peer-to-peer license transfer, renewal, retrieval, acquisition, switching between DRMs, etc.). have. Exemplary embodiments allow consumers to choose from a variety of repositories such as handheld devices or web services based on their preferences. Exemplary embodiments improve the user's experience in handling multiple heterogeneous DRM systems by providing a mechanism and interface that allows a shared license repository to interoperate with proprietary DRM systems.

Thus, in exemplary aspects of the present invention, an existing digital rights management (DRM) system having a unique interface to its own repository of data to govern the use of content, and governing the use of the content and the existing A shared license repository configured to access the data to communicate with a unique interface of a DRM system, and configured to interact with the existing DRM system and allow a user to license a license associated with the content from the shared license repository. A method, system, and apparatus for license-driven content use or distribution comprising a user interface configured to allow sending to a DRM system or another shared license repository is provided.

According to one aspect of the invention, a computer-implemented method for rendering content licensed to a user is provided. The method includes receiving a license at a user computer that permits the same content to be rendered to different instances by a plurality of content-consuming applications, respectively; Displaying an icon representing the received license on the user computer; And operating the displayed icon on the user computer, whereby a desired application can be selected from the plurality of content-consuming applications.

Furthermore, it is preferable that the method operates the drag-and-drop method for manipulating the displayed icon.

Just by showing a number of exemplary embodiments and implementations, including the most suitable manner intended for the practice of the invention, it is easy to take further aspects, features, and advantages of the invention from the following detailed description. You will know. In addition, the present invention enables other different embodiments, and some of the specification of the present invention may be changed in various aspects without all departing from the spirit and scope of the present invention. Accordingly, the accompanying drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

According to the invention, the user can transfer the license to the desired playback device using the same token.

In addition, it is possible to play a desired content instance by selecting a desired content consumption application by manipulating an icon representing a license on a computer. This makes it much easier for consumers to consume content.

Embodiments of the invention are shown by way of example and not by way of limitation in the figures of the accompanying drawings in which like reference numerals indicate like elements. Among such attached drawings,
1 is an illustration of an example system for describing interactions between example components;
FIG. 2 is a diagram providing an overview of an example process for using the shared digital license repository of FIG. 1;
FIG. 3 is an illustration of an example system for describing a shared license repository that provides a base level of interoperability between proprietary DRM systems; FIG.
FIG. 4 is a diagram of an example system that includes only some of the components shown in FIG. 1. FIG.

The present invention implies the perception that in the current state of digital content consumption, a "content centric" approach associates content being consumed with a particular consuming application. For example, when a consumer wants to consume digital content, the consumer double-clicks a file containing the content in his file system explorer to launch the associated content consumption application. The right to consume content is tied to the specific implementation of such content. For example, the right to watch a movie is associated with physically owning a DVD. If the content is protected by a DRM system, the use of that content is based on using the specific DRM system originally used to protect the content. For example, if a consumer has purchased a license for content from Company A, the consumer must have Company A's DRM system installed on the consuming device to consume that content.

Example embodiments improve the content centric model by introducing the concept of "license centric" digital rights management. Consumers want to focus on having the right to use content. Consumers want to be able to easily manage those rights. Consumers do not want to use content that is limited to a particular combination of content medium or format, consuming application, consuming device, and DRM system. In the context of the example embodiment, the license may include an indication of usage rules that are captured using the rights expressions. The license may convey the full context of the granted rights. The information captured in the license may include the grantor of the rights, grantee of the rights, content, authorized use, and related terms. The expression of rights may include a digital surface of rights. Examples of rights expressions may include rights based on XML-based rights expression languages such as ISO MPEG REL, XrML, SAML, XACML, ODRL, OMA REL, data structures, bit fields, and the like.

In an example embodiment, the consumer acquires a license for the content (eg, purchases, rents, exchanges, and subscriptions), and the DRM used to enforce the consuming application or device used, the content distribution medium, the licensing terms. The license can be used (eg, consumed, rented, distributed, and shared) regardless of the system or the like. For example, a consumer may purchase a license to watch a movie, which license need not be associated with specific implementation of the movie, such as a DVD. If the same movie can be obtained from another medium, such as a pay-per-view broadcast or a high-definition DVD, the consumer's license will still be available for viewing the movie, provided that the license permits the performance. Valid. In yet another embodiment, the consumer obtains a license to play the movie on any device in his home area. Such a license may be displayed as an icon on the consumer's desktop. When dragging the license icon to DRM player I (e.g., a real player), the movie is played on the consumer's PC monitor. If you drag the same license icon to DRM Player II (eg, Windows Media Player), the movie is also played (eg on a large screen TV driven by DRM Player II). Those DRM players fetch license-related content appropriate for the rendering environment (as required). By the same token, if a license is transferred to a mobile phone or a portable player, those devices can also fetch and render content (as required) as long as they belong to the home area. It is much more convenient for consumers compared to prior art DRM systems.

An example embodiment enables a consumer to access his or her purchase license list irrespective of his location, consuming application or device, or the reason for creating the license. An example embodiment includes an example license repository that provides a single point of access to a consumer so that the consumer manages all of his licenses. The exemplary license repository provides a consistent user interface for the heterogeneous DRM systems while facilitating interoperability. Example embodiments include an interface that provides storage and management of digital licenses and access to those licenses.

Thus, unlike systems available on the market today, the exemplary embodiment employs a "license-centric" approach to DRM enabled digital content distribution. A consumer may use the content under a license, regardless of the consuming application or device used, the content distribution medium, the DRM system used to enforce the licensing terms, or the like. For example, a consumer can purchase a license for a music track, which need not be associated with the specific implementation of the movie, such as a CD. If the same music can be obtained from another medium, such as a downloadable MP3 file, the consumer's license is still valid and applicable, provided the license permits playing.

In order to enable such a "license-centric" approach, an example embodiment improves the user's experience by allowing the consumer to focus on the license instead of the instant of the content. Exemplary embodiments may enable consumers to better interpret and exercise their licenses to implement lifecycle functions such as acquisition, peer-to-peer transfer (eg, balance, sales, etc.), search, update, archive, inventory, and the like. To improve the consumer experience. Exemplary embodiments use all licenses regardless of the consistent user experience and location of the consumer, the consumer device, or the entity that created the license (e.g., proprietary DRM system, content owner, content distributor). And provide a single point of contact for management. The example embodiment provides a minimum and sufficient level of interoperability between different DRM systems, between different instances of the same DRM system, and between different versions of the same DRM system.

To provide such advantages, an example embodiment provides mobile access to a shared digital license repository and provides lifecycle management for stored licenses. An example embodiment includes storage of a digital license and an interface that provides access to that license.

[0036] With reference now to the accompanying drawings, wherein like reference numerals designate the same or corresponding parts throughout the several views, in particular with reference to FIG. 1, a system according to an exemplary embodiment for license-driven content consumption ( 100 is shown. In FIG. 1, example system 100 for license-driven content consumption includes licenses 106, 108, 128, 130, 132, 134 that represent usage rules for content. The format of the licenses may be standardized as in licenses 106, 128, 130, 132, or may be proprietary as in licenses 108, 134. Some proprietary licenses may be legal terms that a consumer agrees to when they acquire the content, which is the basis of the private license that the content exists in the proprietary DRM system and that the terms are known. Example system 100 may be used by one DRM system and / or an instance of a DRM system or between multiple DRM systems 136, 138, 140 and / or instances of DRM systems 136, 138, 140. It includes a shared digital license repository 142 that can be shared between.

The shared license repository 142 is a repository of private DRM systems 136, 138, 140, programmatic interfaces 122, 124, 126 of private DRM systems, and / or a DRM system. One or more programmed interfaces 110, 112, 114 that interface with one or more of the DRM systems 136, 138, 140, including the devices themselves. The programmed interfaces 110, 112, 114, 122, 124, 126 are logical functions. They can be implemented as part of the license repository and private DRM systems or externally as separate glue modules. The shared digital license repository 142 is configured to manage licenses and further comprises one or more license management user interfaces configured as part of the shared license repository 142 and / or as part of proprietary DRM systems 136, 138, 140. 104).

The private DRM systems 136, 138, 140 may include DRM license repositories owned by each DRM system, programmed interfaces 122, 124 between instances of the shared digital license repository 142. 126 is configured to enable license transfer between them. Private DRM systems 136, 138, 140 may also include license management user interfaces 116, 118, 120 configured to manage license transfer between instances of a shared digital license repository. Private DRM systems 136, 138, 140 obtain a license from each service provider and store the license in the shared digital license repository 142 between each service provider and the shared digital license repository 142. It may include programmed interfaces 122, 124, 126. License management user interfaces 116, 118, 120 may be configured to manage obtaining new licenses from service providers and store the licenses in shared digital license repository 142.

The shared digital license repository 142 may include an authentication element 144 that provides authentication of the user / owner of the shared digital license repository 142 itself and / or the shared digital license repository 142. The shared digital license repository 142 may be configured as a repository of digital content. The example system 100 need not include all of the components described above as another example embodiment may include only some of the components described above with respect to FIG. 1.

At the heart of the example system is a digital license repository 142 that can be shared among a number of proprietary DRM systems 136, 138, 140. The repository 142 may store, retrieve, and interpret the licenses expressed explicitly or by context (eg, ownership of a CD entails a license to play that music). Such license may be displayed in a form specific to the repository 142. To facilitate access to licenses in the digital license repository 142 from any suitable location or device, the repository 142 may be a mobile physical device that a user can carry, a PC linked to a network or linked to a domain control device, Set top boxes, and devices such as game consoles, software applications running on standard platforms, services that can be accessed from multiple locations, and the like.

[0041] Shared digital license repository 142 allows multiple agents to participate in the life cycle of a license, where multiple agents preferably do not need to know the reasoning representation of such a license. The interfaces 110, 112, 114 of the shared digital license repository 142 may be configured to perform license retrieval, license acquisition, peer-to-peer license transfer, license renewal, license switching between proprietary DRM system formats, and the like. .

For interaction with the user, the shared digital license repository 142 allows the user to understand the contents of the repository 142, back up the licenses stored in the repository 142, obtain new licenses, transfer licenses, licenses, and the like. Life, such as searching, reporting license status, status, and list, renewing licenses, retiring obsolete licenses, issuing licenses, converting licenses to standard formats, converting licenses between proprietary formats, and archiving licenses in documents or other digital forms. A license management user interface 104 is provided that enables performing a cycle function.

For interaction with private DRM systems 136, 138, 140, the shared digital license repository 142 stores, browses, searches, and rights specific to a particular DRM system 136, 138, 140. Provides programmed interfaces 110, 112, 114 to enable other license lifecycle functions including a representation. Those interfaces 110, 112, 114 preferably have their DRM systems 136, 138, 140 without requiring the DRM systems 136, 138, 140 to interpret the representation of the rights of each other DRM system. Enable interoperability between them. The shared digital license repository 142 may, for example, be configured to prove the identifier feature via an authentication element 144 that allows private DRM systems 136, 138, 140 to authenticate the user.

The shared digital license repository 142 may interact with other digital license repository 142. Each shared digital license repository 142 is configured to provide standardized interfaces (eg, physical interface, programmed interface, wireless interface, multiple interfaces, etc.) that allow the shared digital license repository 142 to exchange licenses. Can be configured. The ability to interact with other shared digital license repositories 142 allows a user to select a repository or transfer licenses between repositories based on their preferred experience to comply with the license. One or more shared digital license repositories 142 may be implemented within a single computing entity. For example, the license repository service may provide a shared digital license repository service to multiple users.

The shared digital license repository 142 may employ a proprietary interface provided by that particular DRM system to interact with that particular DRM system. It allows the shared digital license repository 142 to interoperate with a DRM system that does not support the native programmed interfaces 110, 112, 114 provided by it.

FIG. 2 provides an overview of example steps of using a shared digital license repository 142, where a user obtains and configures a shared digital license repository 142. Unlike conventional DRM systems, which are limited to private storage, the exemplary embodiment allows a user to select a storage from third parties. The shared digital license repository 142 may be a device such as a portable device that a user purchases, a software application running on a standard platform, a widely available service such as a web service or a service available for a mobile phone. Since such various implementations of the shared digital license repository 142 may provide different user interfaces, each user may choose from among the available shared digital license stores 142, for example, based on the user's preferences and the like. The user can then manage all his / her licenses regardless of the DRM system that created the license using the selected shared digital license repository 142.

In steps 204 through 206, the shared digital license repository 142 preloads a set of licenses or interacts with other shared digital license stores 142 or various proprietary DRM systems 136, 138, 140. To obtain the license of the pre-acquired user. The user can actively license or passively license as part of other activities such as content purchase or program rendering. The shared digital license repository 142 can interact with the DRM systems 136, 138, 140 using the proprietary interfaces 122, 124, 126 of each DRM system 136, 138, 140. The shared digital license repository 142 may store copies of all licenses of pre-purchased users. The shared digital license repository 142 may be configured to copy a user's license from each DRM system 136, 138, 140 (eg, via a pull process), or the DRM systems 136, 138 140 may be configured to copy the user's license to the shared digital license repository 142 (eg, via a push process). The license may be explicitly expressed or implied from the consuming DRM system context (eg, ownership of the DVD entails a license to play the video encoded thereon).

The shared digital license repository 142 enables the use (eg, render, consume, duplicate, and distribute) content using any suitable DRM system by providing the necessary licenses in a proprietary format for the consuming DRM system. can do. To use the content, that license may be provided from the user's shared digital license repository 142 to the consuming DRM system. Shared digital license repository 142 may be used, for example, to authenticate a user consuming content via authentication element 144. Depending on the implementation of the shared digital license repository 142, authentication may include the use of encryption keys, biometric mechanisms, and the like.

In steps 208 through 216, the shared digital license repository 142 may provide an integrated license user interface that provides numerous functions to use and manage licenses throughout the license lifecycle. Users can choose from the available repositories based on their preferences, and manage their licenses independently of the various DRM systems that originally created them. Exemplary embodiments allow the shared digital license repository 142 to implement a sufficient set of lifecycle functions, including license transfer (eg, peer-to-peer transfer), renewal, retrieval, acquisition, switching between DRMs, and the like. .

In another example embodiment, a trust mechanism such as a digital signature provided by an originating DRM system may be preserved when the license is stored in the shared digital license repository 142. If the proof of authenticity of the license cannot be extracted from the founding DRM system or provided to the consuming DRM system, the shared digital license repository 142 can be used to prove the authenticity of the license.

The example embodiment provides a number of advantages over conventional DRM systems. For example, with respect to user experience consistency, an example embodiment allows a consumer to perform license management tasks using a single user interface. Thus, in an exemplary embodiment, the user is not allowed to use the license storage location, the entity that created the license (eg, the DRM system, content owner, and content distributor), or the DRM system used to exercise the license rights. Regardless, a license management user interface 104 may be included in the shared digital license repository 142 that can be used to manage licenses. Such license management user interface 104 may interact with private DRM systems 136, 138, 140 on behalf of a user. Preferably, the user does not need to interact directly with the various DRM systems 136, 138, 140 from which the license was originated.

A user may use the license management user interface 104 to view various information about the license, including information about the DRM system to which the pre-obtained license is applied. By employing the license management user interface 104, a user may use the shared digital license repository 142 to obtain additional licenses from any suitable DRM system or to renew expired licenses. The obtained license can be delivered directly to the shared digital license repository 142 for storage. A user may perform peer-to-peer license transfer to other users via license management user interface 104. At the time of the transfer, the user's original license may expire, be revoked, or destroyed, and a new license for another user may be created in another user's shared digital license repository 142. The license management user interface 104 allows a user to be re-stored in case of a DRM system compromise, software / hardware move or upgrade, or upon change of authentication information such as email accounts and passwords. You can also create archive copies of the licenses stored in.

FIG. 3 shows an example system 300 including a shared digital license repository 142 that provides a base level of interoperability between proprietary DRM systems 136, 138, 140. The example system 300 of FIG. 3 operates similarly to the example system 100 of FIG. 1 with respect to common components.

4 is a shared license management user interface that omits a shared digital license repository 142 and instead provides a virtual shared repository for combining licenses stored in proprietary DRM systems 136, 138, 140. Another example system 400 employing 104 is shown. In FIG. 4, the shared license management user interface 104 may be configured to view the licenses of all users stored in the private DRM repositories 136, 138, 140. In addition, the example system 400 of FIG. 4 operates similarly to the example systems 100, 300 of FIGS. 1 and 3 with respect to common components.

An example embodiment provides a unified license list. For example, exemplary embodiments may be described in which a consumer has various formats (eg, DVD, redbook audio, computer DVD, streaming) for a variety of devices (eg, PCs, set top boxes, car stereos, devices that build networks with remote points, etc.). Etc.) to allow content to be purchased from a variety of sources (eg, offline stores, satellite / cables, internet downloads, etc.). In addition, the exemplary embodiment allows a consumer to access content under that license regardless of the license location, the consuming device, or the DRM system that originally created the license. That is, the exemplary embodiment contemplates all the content available to any suitable device capable of rendering the content within the usage rules defined by the corresponding license for the content.

Thus, the shared digital license repository 142 may store a copy of all the user's pre-obtained licenses to provide a unified license list. The shared digital license repository 142 can copy the user's license from each DRM system 136, 138, 140 (eg, via a full process), or the DRM systems 136, 138, 140 can Licenses can be copied to the shared digital license repository 142 (eg, via a pull process). Upon obtaining the shared digital license repository 142, a set of licenses, such as all HBO or NFL programs, may be preloaded into the repository 142. A service or software program may be employed that collects the user's pre-acquired licenses and loads the licenses into the shared digital license repository 142. That is, the example embodiment provides an example means of implementing license integration, but other equivalent means may be employed in another embodiment.

An example embodiment provides a user preference for a shared digital license repository and a DRM system. For example, any suitable multiple parties can provide a shared digital license repository 142 implementation. The user can select a shared digital license repository 142 to use based on preference. Such various implementations may differentiate their shared digital license repository 142 offerings according to factors such as storage of licenses and access to licenses (eg, devices with hardware interfaces, widely available web services). Etc).

Still other elements can include the nature of the license management interface 104 provided. For example, the license management interface 104 provided by the shared digital license repository 142 provides a consolidated view of each user's license regardless of each DRM system that generated the license or a proprietary license repository in which the license is stored. Can present

Still other elements may include a set of supported proprietary DRM systems. Thus, each shared digital license repository 142 may provide interoperability with the identified set of proprietary DRM license repositories. For example, an implementer A may provide a shared digital license repository 142 as a web service that interoperates with proprietary DRM systems A, B, and C. The A implementer's shared digital license repository 142 may retain copies of all licenses a particular consumer has obtained from A, B, and C proprietary DRM systems. On the other hand, another implementor, B, may limit interoperability to A and B DRM systems, and may not apply interoperability to C.

Still further elements include the price, where the DRM seller may provide its own private user interface 104 that interoperates with the shared digital license repository 142. Many DRM vendors may use devices (eg, personal computers, PDAs, mobile phones, etc.) that consumers use to interact with the shared digital license repository 142, rendering of the user interface (such as graphical or text-based rendering), interfaces Differentiate their offerings based on factors such as the set of shared digital license repositories, price, and so on, that are (e.g., a simplified or full-featured interface). Can be. Preferably, the user can select all of his / her licenses in the central shared digital license repository 142 while selecting the user interface 104 based on preferences.

An example embodiment may use a shared digital license repository 142 to authenticate a user. For example, if the consumer wishes to use the licensed content, the shared digital license repository 142 may optionally authenticate the user via, for example, the authentication element 144. Depending on the implementation of the shared digital license repository 142, such authentication may include encryption keys, biometric mechanisms, and the like. For example, an authentication license in the form of an ISO MPEG REL license, such as an X.509 digital certificate or a possessProperty certificate, may be provided to the consuming DRM system as follows.

In an example embodiment, the shared digital license repository 142 may provide the DRM system with the necessary license in a proprietary format of the consuming DRM system. For example, if the shared digital license repository 142 can be used as a web service, and the consumer is using a PDA to consume content, then the shared digital license repository 142 will have a DRM in which the authentication license resides on the PDA in its proprietary format. Can be provided to the system.

In another example embodiment, the consumer may copy the license from the shared digital license repository 142 to the consuming DRM system. For example, if the shared digital license repository 142 can be used as a mobile device, and the consumer is using a personal computer to consume the content, then the consumer can copy the license in a proprietary format to the DRM system residing on the personal computer. have.

In another example embodiment, if the shared digital license repository 142 is illustrated in the form of a smart card, the shared digital by plugging in the smart card to a host device such as a PC, set top box, game console, or the like. License repository 142 may be used. In such a case, an authentication license and a use license can be made available to the host device, thereby enabling access to and use of the content.

Example embodiments may be used to separately verify content acquisition. For example, trust mechanisms such as digital signatures provided by the founding DRM system may be preserved when storing licenses in the shared digital license repository 142. If proof of authenticity of the license cannot be extracted from the founding DRM system or provided to the consuming DRM system, the shared digital license repository 142 can be configured to be used to prove the authenticity of the license.

As such, shared digital license repository 142 may provide a separate verification of content acquisition. In that role, the shared digital license repository 142 acts as an independent agent that determines when, where and how licenses have been pre-acquired. DRM systems other than the founding DRM system may take over the license based on the trust of the shared digital license repository 142 demonstrating the existence and reliability of the license. In addition, the shared digital license repository 142 allows a consumer to demonstrate such license acquisition if a license stored in that repository 142 needs to be reissued later by the DRM system that originally created the license.

An example embodiment may be used to exchange a license between repositories 142 that may be interoperable. For example, an example embodiment allows a consumer to access content under that license regardless of the location of the license or consumer device. Since any suitable multiple parties may provide interoperable repositories 142 and license management interfaces for those repositories, each consumer may select one or more interoperable repositories to use based on preference.

To enable a consumer to access content from any suitable location or using any suitable device, an example embodiment may include interoperable stores 142 that may exchange licenses. have. For example, suppose a consumer uses a total of two interoperable repositories 142, one on a portable video player and one available as a web service, and if the consumer has a license to play a movie on the portable video player. Some embodiments allow a consumer to transfer a license to a web service to play a movie on a personal computer. Similarly, if a consumer uses a shared digital license repository 142 on a portable device and purchases a new pocket device, the example embodiment allows the consumer to transfer all licenses from the old device to the new device. do. To provide such functionality, each shared digital license repository 142 provides a standardized interface (eg, physical interface, program) that allows the repository 142 to exchange licenses with other interoperable repositories 142. Interface, or both).

Thus, the example embodiment provides interoperability, since there will be heterogeneity in the DRM market for the coming years, while the example embodiment still makes the consumption content protected by DRM a satisfactory user experience. We present measures to facilitate the simultaneous deployment of such incompatible DRM systems. By providing such a level of interoperability, the example embodiment provides a consistent user interface for heterogeneous DRM systems. Advantageously, the exemplary embodiment provides access to the digital license irrespective of the proprietary nature of the licensed DRM system.

An example embodiment may include a dedicated pocket license store 142. For example, a user may purchase a portable license storage device 142 configured in accordance with an exemplary embodiment at a department store. The user has a better and broader range of device form factors, device ergonomics, user interface, felt robustness and reliability, proprietary DRM APIs that differentiate device 142 from competing devices offered by various manufacturers. You can choose to purchase the device based on various features such as support, availability, connectivity, peer-to-peer service compatibility, price, and the like. For example, users can support USB or wireless service connections, collaborate with and store licenses for any suitable type of content, interoperate with Adobe, Microsoft, and Adelphia DRM systems, and A portable license repository 142 configured in accordance with an example embodiment may be purchased that may be connected to a Windows or MAC OS computer, mobile phone, set top box, or portable MP3 player. Such a device may be configured as a dedicated device, or the license repository 142 may be one feature of such a device that also includes other functions.

In such a scenario, a user arrives at home and is dedicated to a proprietary DRM system owned by, for example, Adobe, Microsoft, and Adelphia on their PC running Microsoft Windows or some other software using a USB or wireless connection. The pocket license storage device 42 can be attached. The storage device 142 may authenticate the user using biometric information (eg, a fingerprint), or the storage device itself may be the user's authentication (eg in the case of a smart card). The storage device 142 interacts with the DRM system using the corresponding private interfaces 122, 124, 126 of each private DRM system 136, 138, 140, and each private DRM system 136, 138, 140, it is possible to extract the user's purchase license list, and to store a copy of the extracted license. The user can use the screen of the device to view a list of purchased licenses including information about the content to which each license applies and the DRM systems 136, 138, 140.

The user may periodically back up the license stored in the device 142 to the computer. Preferably, if portable storage device 142 is permanently damaged, lost, stolen or replaced with a “new and improved” device, the user may transfer all of the pre-acquired licenses because the user may transfer a backup copy of the license to the replacement device. You won't lose.

If the user goes to a friend's house and downloads some of the digital content from the Internet to a friend's Apple MAC computer, the user connects his license storage device 142 to the friend's computer to the friend's Apple MAC You can have your license used for content coming into your computer. Preferably, the user can then consume the downloaded content using his license and an Apple DRM system installed on a friend's computer.

An example embodiment may include a shared digital license repository 142 configured as a service. For example, a user may subscribe to a web-based service that provides its shared digital license repository 142. The user can access the shared digital license repository 142 service from any suitable device with connectivity regardless of the type of physical connection (eg, DSL, cable modem service, wireless access, or satellite access). Users will be able to combine the services with competitive services such as robustness and reliability, better or broader support for proprietary DRM APIs, service features such as backup and reporting, availability, connectivity, peer-to-peer service compatibility, and pricing. The shared digital license repository 142 web service may be selected based on various differentiating features. For example, a user can subscribe to a shared digital license repository 142 service that can collaborate with any suitable type of content, store its license, and interoperate with Adobe, Microsoft, and Adelphia DRM systems. .

A user may use his DSL internet connection from his home to connect to the shared digital license repository 142 service and provide a username and password as authentication information. The user may wish that the shared digital license repository 142 service interacts with Adobe, Microsoft, and Adelphia DRM systems 136, 138, 140 to obtain their license from their respective systems 136, 138, 140. You can request The shared digital license repository 142 service can use the proprietary interfaces 122, 124, 126 of each system 136, 138, 140 to interact with each of those systems and store a copy of the license. The user can use the web page of the shared digital license repository 142 service to view a list of his / her acquired licenses, including information about the DRM system to which the license applies.

If the user goes to a friend's house and downloads some of the digital content from the Internet to the friend's computer, the user is connected to the shared digital license repository 142 service using the friend's computer and a cable modem, You can copy your license of the content to your friend's Microsoft DRM system. The user can then consume content downloaded from the friend's computer using his license and the Microsoft DRM system installed on the friend's computer.

An example embodiment may include a shared digital license repository 142 configured as a non-dedicated pocket device. In an exemplary embodiment, a non-dedicated pocket storage device 142 may be incorporated into a device that combines other functions, such as a mobile phone, PDA, portable game station, portable video player, or MP3 player. For example, a user may purchase a PDA that includes a shared digital license repository 142. The user can store a license on the PDA for content protected by any suitable DRM system. The user can consume such protected content using a PDA device or connect the PDA device to another consuming device such as a PC. In either case, the shared digital license repository 142 on the PDA may be interoperable with the DRM systems 136, 138, 140 used to protect its content.

In such a scenario, private DRM systems 136, 138 if private DRM systems 136, 138, 140 support the standardized interfaces 110, 112, 114 of shared digital license repository 142. 140 and the shared digital license repository 142 may be made using the interfaces. If that is not possible, the communication between the private DRM systems 136, 138, 140 and the shared digital license repository 142 uses the private interfaces 122, 124, 126 of the private DRM systems 136, 138, 140. Can be done.

An example embodiment may include a repository 142 that interoperates with DRM systems using a proprietary interface. For example, a user can collaborate with a license for any suitable type of content, store that license, and share a digital license that can interoperate with Adobe, Microsoft, and Adelphia DRM systems 136, 138, 140. You can subscribe to a web-based service that provides a repository 142.

In such a scenario, a user may view, using a computer, an Adobe PDF file that is the subject of a license that the user has stored and stored in a shared digital license repository 142 web service. If Adobe Reader cannot place a license for a PDF in the Adobe proprietary license repository, Adobe Reader may prompt the user for the location of the license. The user can provide a shared digital license repository 142 web service URL, and then the Adobe DRM system can obtain its license by interacting with the shared digital license repository 142 web service using its proprietary interface. In fact, the repository 142 acts as a repository that Adobe Reader already knows instead of the new standardized repository. The Adobe DRM system can then check the provided licenses to determine if the prescribed usage rules are met, and if so, Adobe Reader can render the PDF file.

An example embodiment may include a repository 142 that interoperates with DRM systems using a standard interface. For example, a user can purchase a dedicated portable storage device that supports USB and wireless service connections. Such device 142 provides a standard programmed interface that can interoperate with any suitable DRM system that supports it, and can store a license for any suitable content.

In such a scenario, a dedicated portable storage 142 in Microsoft, Adobe, and Apple DRM systems 136, 138, 140, where the user arrives home and all of them support the standard interface of the storage 142. Attach. Such dedicated portable storage 142 uses its standard interface to interact with each DRM system 136, 138, 140, extract a user's acquired license list from each system 136, 138, 140, You can save a copy of the license.

A user may move to a friend's house and download a video clip that is the subject of his or her license from the Internet to a friend's computer. The user can then try to play the video clip using Windows Media Player, but if the Windows Media Player cannot locate a license for the video clip on a friend's computer, the Windows Media Player will Can be reminded about the position of. The user can connect the dedicated portable storage 142 to a friend's computer and designate the dedicated portable storage 142 as the license location. The Microsoft DRM system on the friend's computer can then interact with the storage 142 using the standard interface of the dedicated portable storage 142 and obtain the corresponding license. In that case, the Microsoft DRM system would have been modified to support a new repository interface that is explicitly intended to allow consumers to have a shared license repository 142. The Microsoft DRM system may check the provided licenses to determine if the prescribed usage rules are met, in which case the Microsoft media player may render the video clip.

An example embodiment may include a license created for the shared license repository 142. For example, a user may use a dedicated portable storage device 142 to acquire and store licenses for any suitable type of content protected by various proprietary DRM systems 136, 138, 140. If the user wishes to obtain a license for new content, the user can use the interface provided by the dedicated portable storage device 142.

For example, if a user wants to purchase music files after connecting the dedicated portable storage device 142 to a portable MP3 player, the user wants to purchase using the interface and wireless internet connection of the dedicated portable storage device 142. You can search for music. The search interface of the dedicated portable storage device 142 is licensed in a standardized format of the device 142 or in a proprietary format of the DRM systems 136, 138, 140 that can interoperate with the dedicated portable storage device 142. In connection with this, all the music files matching it can be retrieved. The user can select the license he wishes to acquire (eg, the least expensive license). A dedicated portable storage device 142 can be obtained and the music file can be downloaded to the user's MP3 player. When a user plays a music file, the dedicated portable storage device 142 may provide that license to a proprietary DRM system used to protect the music file.

[0086] An example embodiment may include peer-to-peer communication between dedicated portable repositories. In such a scenario, two users of Jack and Nancy purchase a dedicated portable storage device 142 to license for many types of content protected by various DRM systems 136, 138, 140. May be stored in the device 142. Although not necessarily sold from the same manufacturer, both devices 142 may support the same standardized interface, such that both devices 142 communicate with each other to transfer license and loan (e.g., date and time), and the like. And various peer-to-peer activities.

For example, if a jack wishes to transfer his license for an e-book to Nancy's device 142, the jack connects his device 142 to Nancy's device 142 and The license may be transferred using the user interface of the own device 142. The original license on Jack's dedicated portable storage device 142 may be revoked, and the same new license may be created in Nancy's dedicated portable storage device 142. Such a scenario would be practical in a license to license a group of people, such as members of a book club to which both Jack and Nancy belong. The private DRM system that created the license and consumes the transferred license may authenticate the dedicated portable storage device 142 to perform such type of license revocation and creation. Thus, if Nancy tries to use a new license, the proprietary DRM system will trust Nancy's license so that she can read the e-book.

In a similar example, if the jack transfers his license for an e-book to Nancy's device 142, the original license on the jack's dedicated portable storage device 142 may be marked as expired. Similar new licenses may be created in Nancy's dedicated portable storage device 142. Such new license may grant the same license, but may nominate Nancy as the grantee. Again, the private DRM system that created the license and consumes the transferred license may authenticate the dedicated portable storage device 142 to perform such type of license revocation and creation. Thus, if Nancy tries to use a new license, the proprietary DRM system will trust Nancy's license so that she can read the e-book.

In another example embodiment, Jack may rent (eg, temporarily transfer) his Nancy to Nancy. In that case, Jack's license becomes invalid for the rental period, and only Nancy's license can be valid for the rental period. When the loan ends, Jack's license is revived and Nancy's license may expire. Again, a proprietary DRM system that creates a license and consumes that license may authenticate the dedicated portable storage device 142 to perform such type of license expiration and creation.

In another example embodiment, the dedicated portable storage device 142 may communicate with a proprietary DRM system when performing a peer-to-peer activity. In that case, when Jack transfers his license to Nancy's device 142, Jack's dedicated portable storage device 142 indicates that the proprietary DRM system marks the jack's license as expired and to Nancy's device 142. You can request to create a new license. If the proprietary DRM system supports the standardized interface of the dedicated portable device 142, such a request may be made via that interface. Otherwise, the dedicated portable storage device 142 may make such a request using the proprietary interface of the DRM system.

In another example embodiment, the transfer of license may involve financial transactions and third parties, such as escrow services or auction services. For example, the jack may auction the right to play multiple audio files similar to selling used CD collections. Nancy can bid on the license and win it. The jack may transfer licenses to an escrow account using a standardized interface provided by dedicated portable storage device 142. Nancy can pay the escrow account. The escrow service may intervene in a transaction to transfer payments to the jack and transfer licenses to that device using the standardized interface of Nancy's dedicated portable storage device 142.

An example embodiment may include a shared digital license repository 142 configured to provide license storage. In such exemplary embodiments, the shared digital license repository 142 may be used as a license repository with or without the license management user interface element 104. For example, a user can use a dedicated portable storage device 142 that can be used to store all licenses for that user. To perform any suitable license management function, a user may use proprietary user interfaces provided by the DRM systems 136, 138, 140 that create and consume licenses.

Each time a user uses content stored in a dedicated portable storage device 142, the private DRM systems 136, 138, 140 may variously communicate with the device 142. For example, the DRM systems 136, 138, 140 can find the license in the dedicated portable storage device 142 and communicate with the device using the standardized interface of the device 142. The DRM systems 136, 138, 140 may find a corresponding license in the dedicated portable storage device 142 and communicate with the device 142 using proprietary interfaces of the DRM systems 136, 138, 140. The DRM systems 136, 138, 140 may find the license in the private license store of the DRM systems 136, 138, 140. The dedicated portable storage device 142 can be used to replace such a store, and a transaction can be made with a license of the portable storage device 142. Thus, for private DRM systems 136, 138, 140, a dedicated portable storage device 142 may look like a private licensed store of the DRM systems 136, 138, 140.

An example embodiment may include a shared digital license repository 142 configured to verify content acquisition. For example, a user may use shared digital license repository 142 to address issues where content media or DRM systems 136, 138, 140 are obsolete. The user can use the shared digital license repository 142 to verify the purchase of a license for a particular content and continue to access that content even after the accompanying licensed content medium or its rendering device becomes obsolete. have.

For example, if a user subscribes to a shared digital license repository 142 web service interoperable with various proprietary DRM systems 136, 138, 140, the shared digital license repository 142 web service is Amazon.com ( Interoperate with online retailers of physical content media such as Amazon.com. The user can then purchase a DVD for the movie from Amazon.com, where the purchase of the DVD entails a license to play the movie encoded on the DVD. The shared digital license repository 142 web service may store such accompanying licenses.

While DVDs may become obsolete over time (eg, DVDs are replaced with streaming video), because the user has already purchased a movie on the DVD, an example embodiment may be that although the user's DVD edition is outdated, But continue to allow the user to watch the movie in a different format. In such a scenario, if the seller providing the streaming is willing to take over a previously acquired license that is stored in the shared digital license repository 142 web service, then the shared digital license repository 142 web service will allow the user to license for the movie. It can be proved that has already been obtained. The shared digital license repository 142 web service can then provide all specifications that certify the original license purchase, including the seller (eg, Amazon.com), media (eg, DVD), date of purchase, purchase price, and the like. have. Because the streaming video seller can trust the shared digital license repository 142 web service, it can allow the user to watch the movie in the streaming video.

Example embodiments may include an apparatus that supports multiple physical interfaces. For example, the shared digital license repository 142 may be a USB, Bluetooth, 1394, PCMCIA, 802.11 (a / b / c), proprietary technology, for connecting to other repositories or DRM systems interoperating with the repository 142. It may include a number of physical mechanisms such as RFID, CDMA, GSM, and the like. Such connections can be operated in parallel, in series, and so on.

An example embodiment may include an apparatus that supports various DRM APIs for extracting a license. For example, a single shared digital license repository 142 may be configured to interoperate with and extract licenses from a plurality of different DRM systems. Such interoperability can be achieved through proprietary APIs that each DRM system initially supports. For example, the repository 142 may be configured to act as a rendering application for the purpose of extracting a license in communication with Adobe Acrobat. Repository 142 may inquire Adobe Acrobat about acceptable rights for certain portions of the content and record the results.

An example embodiment may include an apparatus that supports a new standard API for accessing DRM systems. For example, the DRM vendor provides direct support for the digital license repositories 142 by explicitly supporting a standard API that allows each repository 142 to query the DRM system to determine available licenses. DRM systems may be configured to employ their user interfaces to license the shared digital license repository 142, or the repository 142 may be configured to withdraw a license from the DRM systems.

In an example embodiment, a user is using an instance of a DRM system, such as a Windows Media Player, and while the DRM system is running, the DRM system discovers shared storage 142 and uses the license interpreted by the DRM instance. You may want to save or copy to storage 142.

[0101] An exemplary embodiment may include a device that supports a mechanism for authenticating a user of the device by biometrics. Thus, one complex aspect in creating a DRM system is authenticating the person or thing that exercises the expressed rights. Most conventional DRM systems bind the use of certain digital content instances to one particular instance of the DRM system. For example, a license is granted to a given PC or device. However, according to an exemplary embodiment, the storage device 142 may provide authentication services to a DRM system, such as a fingerprint reader. The DRM system may contact the repository 142 to verify the fingerprint of the user of the device. As such, instead of being bound to an instance of a DRM system, a license may be bound to a fingerprint of a user or a repository 142 connected to multiple DRM systems.

In an example embodiment, the DRM system may be configured to trust the storage device 142 to authenticate the user. It is similar to the example biometric system described above, but rather employs a login ID and password permutation, a digital certificate, RFID, or other type of user authentication system or the like that does not need to be based on biometrics. The DRM instance may bind the content to the authentication mechanism of the storage 142. The user may choose to select a repository 142 that supports the type of authentication that the user is comfortable with. In yet another exemplary embodiment, the mobile phone may be configured as a repository 142 that provides the overall repository 142 functionality associated with authentication via its original identification function.

In another example embodiment, the shared digital license repository 142 may be configured as a unique key, and the DRM system may be configured to trust the existence of the unique key as a certificate for the license. For example, the DRM system may be configured to verify accessibility to a repository 142 that is uniquely identified, and if the repository 142 is accessible, rights to that content may be exercised. Preferably, this exemplary embodiment enables the portability of licenses, such that the rights to the content are shifted as the storage 142 is moved.

[0104] An example embodiment includes a storage 142 configured as a connected service (eg, mobile phone service, internet service, satellite service, etc.) rather than a physical device. Thus, the storage 142 need not be a physical device owned by the consumer, but rather can be configured as the Internet or a mobile phone service or the like. In that case, the user can connect the repository 142 to an instance of the DRM system. Such a connection may be established within the DRM system or via a multifunction device such as a mobile phone if the DRM system natively supports an interface to the storage 142. For example, a user may have a portable Bluetooth enabled CDMA phone that the user would like to meet with a Windows PC to exercise a stored license. The user can then connect the phone to the PC via Bluetooth and then connect the PC to the shared digital license repository 142 via CDMA using a mobile phone as an intermediary. The PC can then find a license to use in the CDMA based storage 142.

An example embodiment includes a user employing a license repository 142 to retrieve and purchase a new license online. For example, the store 142 may include its own user interface and be configured to operate as a store front for obtaining licenses from different services. In that case, the user may visit a friend's home and use the repository 142 to retrieve the content for viewing. After the content is verified, a purchase is made and a new license is transferred to the repository 142. The content can then be viewed using a local DRM system at a friend's home.

[0106] An example embodiment is a user making an offsite preservation copy of the content of the shared digital license repository 142 so that the content may be lost if the device 142 is lost, stolen or damaged in the future. It involves restoring. The shared digital license repository 142 or offsite preservation copy may be used to restore the license of private DRM systems 136, 138, 140 if the license is lost, stolen or damaged. For example, storage 142 may be document-based (eg glyph or text for OCR), removable media-based (eg CDR or smart card), fixed media-based (eg hard drive of PC), service-based And may be configured to support an export mechanism, which may be (eg, Microsoft Passport) or the like. Preferably, it allows a user to regain his or her license list upon loss, theft, or damage of device 142. Importing a license from an archive may belong to one repository or may be interoperable to allow a consumer to change the repository 142.

[0107] Upon transferring an example peer-to-peer license, user A's shared digital license repository 142 may be attached to user B's repository 142, at which time one of user A's licenses expires and For example, a new license can be created for use by user B. For example, two users may agree to transfer a license from one repository 142 to another. In essence, the two have agreed to exchange rights for a particular instance of content. In such example embodiments, a user connects two repositories 142 together to license or sell. Repository 142 may include a mechanism to expire or revoke a given or sold license.

In an example embodiment, the storage device 142 may be authorized to expire a license and create a new license, and the DRM system may be configured to trust the storage device 142 to perform such a function. have. For example, the repository 142 may be delegated by the DRM system to expire or terminate the license. In an example embodiment, the repository 142 may create a temporary license that can be exercised by the DRM system for a limited duration. In a disconnected system, the repository 142 may be entrusted to create a limited license.

In an example embodiment, the repository 142 may connect to the DRM system that originally created the license using a standardized API to execute license expiration, reissue, and peer-to-peer transfer. For example, storage 142 may be used to transfer licenses from one DRM system to another. This embodiment enables two DRM systems to transfer licenses via storage 142 and link them instead of two storage 142 exchanging licenses. If so, the right to transfer the license may be granted, and the reservoir 142 serves as a conduit for the transfer.

In an example embodiment, the repository 142 may execute the expiration, issue, and peer-to-peer transfer of the license using an API pertaining to the reason for the DRM system that originally created the license. For example, the store 142 acts as a jurisdiction agent and can perform the transfer between two instances of the DRM system using a standardized API that facilitates license transfer in cooperation with the DRM system instead of the store 142. have. Such a transfer may or may not be a feature of both DRM systems.

In an example embodiment, the reservoir 142 may be used to interpret the rights. For example, actual licenses may be stored neutral to DRM, where repository 142 interprets the rights instead of converting the license into a form that the DRM system can understand. The repository 142 may be upgraded by an appropriate API that allows the DRM system to transfer the obligation to interpret the license to the repository 142.

In an example embodiment using a standardized API, the stores 142 can communicate with each other to perform various peer-to-peer activities. Thus, two or more repositories 142 can be connected to each other so that licensees can achieve a license sharing and discovery system. A peer-to-peer network of repositories 142 may be formed that facilitates license pooling, real-time / online auctions, and the like. For example, a network of repositories 142 can be created and used to transfer licenses in real time. In order to participate, the user must provide five licenses, for example for sharing. The user then searches the repository 142 network to identify the license he wishes to exercise. License borrowing or transfer can occur in real time to the user's repository 142, and a notification may be sent to the DRM system to allow its consumption. Thereafter, a license may be provided to the road storage 142 network. Desirably, such example system may be able to allow an infinite number of users to be “independently” access to an infinite number of licenses.

In an example embodiment, the repository 142 may be set up as a service for the DRM system, and the DRM system may perform license management functionality using standardized APIs using its own user interface. For example, the repository 142 may appear as a way for the DRM system to store and retrieve licenses. The DRM system may still own a management user interface for such licenses, where the DRM system may be set up to support the APIs of the storage 142.

In an example embodiment, the repository 142 may be set up as a service for a DRM system, and the DRM system may use its own user interface to perform license management functions using proprietary APIs. For example, the repository 142 may appear in a manner that the DRM system stores and retrieves licenses. The DRM system can still own the administrative user interface for such licenses, which are " tricked " to use the storage 142. In this example embodiment, the repository 142 may be configured to intercept license storage requests belonging to the DRM system and provide such functionality.

In an example embodiment, the repository 142 may include its own user interface to perform license management functions across each of the DRM systems through standardized APIs. For example, the user interface of the repository 142 can be set up to allow a user to view a license stored in an instance of the DRM system, where the DRM system, via standardized APIs, allows the repository 142 to access the DRM system's. It may be set to make the license store accessible.

In an example embodiment, the repository 142 may include its own user interface to perform license management functions across each of the DRM systems via proprietary APIs. For example, the user interface of the repository 142 can be set up to allow a user to view a license stored on an instance of the DRM system, where the DRM system does not need to be modified, rather the repository 142 is configured as a DRM system. It is set to determine valid licenses using the original APIs.

In an example embodiment, using standardized APIs, repositories 142 connect to an escrow or auction service so that two users find each other, and a secure, remote peer-to-peer license You can make interactions possible. For example, a seller may access their repository 142 for a service such as eBay and the like to offer licenses to the auction, and then eBay buyers may browse the seller's repository 142 and for licenses stored there. You can price it. Then, once the escrow service confirms that the payment has been made, the seller's store 142 may be connected to the buyer's store 142, and a license transfer may take place.

In an example embodiment, the repository 142 may be set up to provide other types of peer-to-peer license transfers. For example, other types of peer-to-peer transfers, such as license borrowing and resale, may be supported between the repositories 142. Repositories 142 may transfer licenses from one another and, under appropriate conditions, may agree to revoke and return the borrowed license.

[0119] Using an example embodiment, companies provide consumers with better user interface, robustness, better proprietary API support, ergonomics, usability, peer-to-peer service compatibility, better price, reliability and the like. It may compete to create a reservoir 142 for. Form, function, cost, and robustness of the reservoirs 142 can be customized to obtain a suitable consumer. Good examples of this model are the variety and functions of cell phones and service programs in the wireless industry.

[0120] The apparatus and subsystems of the example embodiments of FIGS. 1-4 described above may, for example, perform all appropriate servers, workstations, which may perform the processes of the example embodiments of FIGS. Personal computers, laptop computers, PDAs, Internet devices, handheld devices, cellular phones, wireless devices, mobile game machines, other devices, and the like. The devices and subsystems of the example embodiments of FIGS. 1-4 can communicate with each other using any suitable protocol and can be implemented using one or more programmed computer systems or devices.

[0121] One or more interface mechanisms may be used in the example embodiments of FIGS. 1-4, which may be, for example, Internet access, telecommunications in any suitable form (eg, voice, modem, etc.), wireless Communication media and the like. For example, communication networks employed by the example embodiments of FIGS. 1-4 may include one or more wireless communication networks, cellular communication networks, G3 communication networks, public switched telephone networks (PSTNs), and packet data networks. Network (PDN), the Internet, intranets, combinations thereof, and the like.

[0122] The devices and subsystems of the example embodiments of FIGS. 1-4 are for illustration purposes, and as will be appreciated by those of skill in the art, used for the implementation of example embodiments. It is to be understood that various changes to the specific hardware are possible. For example, one or more functions of the devices and subsystems of the example embodiments of FIGS. 1-4 may be implemented by one or more program computer systems or devices.

In addition to such modifications, in order to implement other modifications, one computer system may be programmed to perform one or more special purpose functions of the apparatus and subsystem of the example embodiments of FIGS. . On the other hand, two or more programmed computer systems or devices may replace any one of the devices and subsystems of the example embodiments of FIGS. Thus, the principles and advantages of distributed processing such as redundancy replication and the like can also be implemented to increase the robustness and performance of the apparatus and subsystems of the example embodiments of FIGS. have.

The apparatus and subsystems of the example embodiments of FIGS. 1-4 may store information related to the various processes described herein. This information may be stored in one or more memories of the devices and subsystems of the exemplary embodiments of FIGS. 1-4, such as hard disks, optical disks, magneto-optical disks, RAM, and the like. have. One or more databases of the apparatus and subsystems of the example embodiments of FIGS. 1-4 may store information used to implement example embodiments of the present invention. The databases may be constructed using data structures (eg, records, tables, arrays, fields, graphs, trees, lists, etc.) contained in one or more memories or storage devices disclosed herein. Can be. The processes described in connection with the example embodiments of FIGS. 1-4 are collected and / or generated by the processes of the apparatus and subsystem of the example embodiments of FIGS. 1-4, in one or more databases thereof. It may include a suitable data structure for storing the data.

One or more of the apparatus and subsystems of the example embodiments of FIGS. 1-4 are one or more general-purpose computer systems, microprocessors, digital signals programmed in accordance with the teachings of the example embodiments of the present invention. It may be conveniently implemented using a processor, a microcontroller, or the like, as will be appreciated by those skilled in the art of computer and software arts. Suitable software can be readily produced by a programmer having ordinary skill in the art, based on the exemplary embodiments of the present invention, which will be appreciated by those skilled in the software arts. Furthermore, the apparatus and subsystems of the example embodiments of FIGS. 1-4 may be implemented on the World Wide Web. In addition, the apparatus and subsystems of the example embodiments of FIGS. 1-4 may be implemented by fabrication of a dedicated application-specific integrated circuit or interconnection of suitable networks of existing component circuitry, which One of ordinary skill in the art will appreciate. Thus, example embodiments are not limited to any particular combination of hardware circuitry and / or software.

[0126] Exemplary embodiments of the present invention are software stored in one or a combination of computer readable media, controlling the apparatus and subsystem of the exemplary embodiments of FIGS. 1-4, and the examples of FIGS. Software for driving the devices and subsystems of certain embodiments and allowing the devices and subsystems of the example embodiments of FIGS. 1-4 to interact with a human user. Such software may include, but is not limited to, device drivers, firmware, operating systems, development tools, application software, and the like. Such computer readable media may also include a computer program product of an embodiment of the invention for performing all or part of the processing performed in an implementation of the invention (if processing is distributed). Computer code devices of exemplary embodiments of the invention include, but are not limited to, scripts, translatable programs, dynamic link libraries (DLLs), Java classes and applets, complete executable programs, COBRA ( Common Object Request Broker Architecture) objects, etc., and any suitable translatable or executable code mechanism. Moreover, some of the processing of exemplary embodiments of the present invention may be distributed for better performance, reliability, cost, and the like.

As noted above, the apparatus and subsystems of the example embodiments of FIGS. 1-4 are intended to retain instructions programmed in accordance with the teachings of the present invention, and to include data structures, tables, records, and / or herein. It may include a computer readable medium or a memory for holding other data described. Computer-readable media includes all suitable media that participate in providing instructions to a processor for execution. Such media can be in many forms, including but not limited to, nonvolatile media, volatile media, transmission media, and the like. Non-volatile media may include dynamic memory and the like. Transmission media may include coaxial cable, copper wire, optical fiber, and the like. The transmission medium may also take the form of acoustic, optical, electromagnetic waves, and the like, generated in the course of radio frequency (RF) communications, infrared (IR) data communications, and the like. Common forms of computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other suitable magnetic media, CD ROM, CDRW, DVD, any other suitable optical media, punch cards card, paper tape, optical mark sheet, hole pattern or any other suitable physical medium having other optically recognizable markings, RAM, PROM, EPROM, FLASH-EPROM, Other suitable memory chips or cartridges, carrier waves, or other suitable media that a computer can read from.

Although the present invention has been described in connection with a number of exemplary embodiments and embodiments, the invention is not limited thereto and includes various modifications and equivalents falling within the scope of the appended claims.

100, 300, 400: license-driven content consumption system
102: Consumer 104, 116, 118, 120: License Management User Interface
106, 128, 130, 132: licenses in a standardized format
108, 134, 346, 348: License in Private Format
110, 112, 114, 122, 124, 126: programmed interface
136, 138, 140: DRM system 144: authentication element

Claims (2)

Receiving a license at a user computer that allows a plurality of content-consuming applications to render respective instances of the same content, wherein each of the plurality of content-consuming applications is compatible with different types of content. Is compatible;
Presenting an icon representing the received license on the user computer;
Operating the displayed icon on the user computer, thereby selecting one desired content-consuming application from the license and the plurality of content-consuming applications;
Retrieving an instance of the content that is of a type compatible with the desired one content-consuming application; And
Rendering the instance of the content in accordance with the license to a selected content-consuming application. The computer-implemented method of claim 1, wherein the manipulating the displayed icon is performed by a drag-and-drop method.

Images