JP6047076B2 - Device with DRM system and license repository - Google Patents

Description

  The present invention relates generally to the field of digital rights management, and more particularly to methods, systems and devices for storing licenses for digital content, access to the licenses, and management of the licenses.

  The consumer view was "application centric" shortly after the computer was in use. For example, if a consumer wants to consume digital content, he first opened an appropriate application such as a word processor. The consumer then accessed the content within this application.

  The current state of the art is promoting a “content centric” view. For example, if a consumer wants to consume digital content, the user can double-click on the file containing the content in his / her file system explorer to launch a related content consumption application. The right to consume content is often tied to specific embodiments of such content. For example, the right to watch a movie is tied to the physical ownership of the DVD. If the content is protected by a DRM (Digital Rights Management) system, the use of this content depends on the use of the particular DRM system originally used to protect this content. For example, if a consumer purchases a content license from Company A, the consumer must have Company A's DRM system installed on a consumer device for consuming such content.

  One thing common to most DRM systems available on the market today is that the content owner or content distributor must enforce usage rules as described in the license ,That's what it means. This license may be embedded in the content or may be a separate license, but in this case, it is readable by machines and humans such as click-through licenses and legal contracts. The DRM system interprets this license to identify what the consumer is allowed to do with this content and places restrictions on what the consumer does not allow. There are a variety of mechanisms that various DRM systems use to accomplish this task. For example, many DRM systems represent, store and maintain licenses in a proprietary manner. Consumers typically acquire a DRM system and request content that is defined for this system. Then, an instance of the content is prepared by encryption, formatting, and other credit and security technologies linked to this, but with these technologies, this content instance can be used only when DRM is specifically implemented. It becomes impossible to use. 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.

  Combining content consumption with specific combinations of consuming applications, consuming devices and / or DRM systems limits consumers' purchasing and consumption habits. However, consumers can use a variety of formats (eg, DVD, redbook audio, computer DVD, streaming, etc.) from a variety of sources (eg, brick and mortar stores, satellite / cable, internet downloads, etc.). , Trying to purchase content for a variety of devices (eg, PCs, home media centers, set-top boxes, car stereos, mobile phones, portable media players, remotely networked devices, etc.).

  Consumers hesitate to purchase content, which may not exist in the future to protect the content (for example, if the DRM system expires) or the company may be bankrupt For example, or because the DRM system is not compatible with the device that the consumer is trying to use to consume the content (eg, in the case of a platform-limited DRM system). In many cases, the consumer may have a device capable of rendering the content, but such a device may not have the required DRM system.

  Another reason for consumers to hesitate to purchase content is that the format or medium in which the content is currently available may be replaced by a more prevalent format or medium (eg, DVD replaces high definition DVD). It may be replaced). However, consumers do not like what they purchase becomes obsolete, so they need to repurchase the same content in the future.

  Consumers must install, manage, and interact with various combinations of consumer devices, consumer applications, and DRM systems in order to use the content that they purchase, which is for consumers It is a great burden. For example, the consumer's experience of using content with rights managed by a particular DRM system is unique to such a DRM system. A consumer may not be able to get an inventory of all the licenses he / she purchased, but this is because each license is stored in the proprietary repository for the DRM system that created this license. Because. When a consumer has licenses built for four different DRM systems, they have four unique experiences to understand, manage and use such licenses.

  Consumers also want all content available to any suitable device capable of rendering the content. The consumer also wants to purchase the content once so that it can be used at an appropriate time at any time in the future. The content owner wants the consumer to be able to access his content according to the usage rules defined in the license. Neither content owners nor consumers prefer to be bound by a particular DRM system. DRM should not be a barrier to this goal. The fact that current “content-centric” views create such a barrier is annoying to content owners because it suppresses consumers ’desire to purchase content.

  Attempts have been made to promote interoperability between DRM systems in an attempt to address some of these issues. If interoperability between DRM systems is successful, this allows consumers to have access to their content in their chosen format, location, time and device Is possible if approved by the content owner or distributor. Consumers will have a greater sense of owning the digital content they have purchased, regardless of the DRM system used to enforce the corresponding license and the version of such a system. This is because it is possible to use such content anytime and anywhere. However, there are several barriers to trying to realize DRM interoperability on the fly. For example, from the point of view of multiplicity, when a proprietary relationship is established between various DRM systems, it becomes an N-factorial problem for every permutation.

  From a security perspective, DRM systems provide various levels of implementation. If it is possible to move to any DRM system as long as the content is compatible, security problems may arise. Consumers may take advantage of low rights enforcement levels by moving all of their content to the least secure system. This facilitates an environment where the least secure DRM system is most widely used.

  In terms of support for usage rules in a license, the DRM system implements various sets of license conditions. Again, security issues can arise if it is possible to move to any DRM system if the content is compatible. For example, a consumer may attempt to move content from a DRM system that allows daily rental to a system that does not support daily rental restrictions and use this content beyond the daily rental period. .

  In terms of usage rule representation, DRM systems use various mechanisms to specify usage rules assigned to content. A DRM system may apply a fixed set of rules to all content types and / or instances, and such a system may apply usage rules to content on a per-instance basis. DRM systems that apply usage rules to individual content instances will differ in their ability to express the type of usage rule. For example, in the DRM system A, the owner of the content can specify that the content can be viewed but cannot be copied. The DRM system B provides the same function, but the content owner may specify that the content can be played only once. In the DRM system C, a language having a high flexibility in expressing usage rules is used. As such, the requirements and functions of the various DRM systems for the usage rule representation vary, making it difficult to achieve interoperability.

  In terms of user experience, each DRM system has a proprietary user interface that consumers use to understand, consume, and catalog the content that they access. Therefore, there is no consistency even if the user tries to experience various DRM systems.

  In terms of license acquisition, when a consumer attempts to acquire a content license, the supplier of this license will provide content that is compatible with the appropriate combination of content, device, and DRM system. Must understand its DRM system and format.

  There are standardization groups such as ISO MPEG-21 and OMA (Open Mobile Alliance), but these are intended to be a content format that allows content to be exchanged between various compatible DRM systems, client / It is to realize DRM interoperability by creating a standard DRM system and interface including server communication protocol, content protection method, content identification method, rights expression and degree of interoperability. There are other standardization groups that focus on the establishment of a common expression of rights (Rights Expression Language) as the primary means of achieving interoperability. MPEG-21 REL Working Group, TV-Anytime Rights Management and Protection Group, ISO SC36, IEEE LTSC (IEEE Learning Technology Standards Committee), OeBF Rights and Rules Working Group (Open eBook Forum Rights and Rules Working Group). The standardization of REL is similar to the standardization of a common format for message exchange. Standardization has the advantage that all conforming systems can communicate with each other and licenses can be exchanged and shared in an interoperable manner, but in this case the cost of conforming Is cheap compared to a complete DRM system, and messages (REL) are neutral to the platform, design, and implementation, and do not enforce them. This method enables technology providers with various platform processing items to compete on an equivalent basis while maintaining sufficient interoperability.

  Although the main barriers mentioned above are removed by various efforts for standardization, many barriers still remain. For example, in terms of creating standards, standardized DRM systems are extremely difficult to create, but this is part of the value chain from content owners to rendering device manufacturers for standardization. It is necessary for all the parties involved to agree on system requirements, and there are troublesome problems to achieve such an agreement. Each content owner has their own requirements for security levels, usage rules required by the license, and so on. Device manufacturers may hesitate to implement licenses because it is inconvenient and deters consumers from purchasing. This may also limit the use of features that allow manufacturers to differentiate their competitors. In addition, not all business models require the same level of security and usage restrictions. For example, in the contents of advertisements, it is necessary for the embedded commercial to be noticeable, but when distributing the audio MP3, it is necessary to restrict copying. Even if standards are established, they tend to deal with market segments that share common security requirements. Ad hoc interoperability across market segments is a constant problem.

  From the standpoint of international support, standardized DRM systems are difficult in one country, with their intellectual property laws, and it is almost impossible to create a globally standardized DRM system. To do so, all countries need to agree on the laws of intellectual property and its use.

  From a lifecycle perspective, like most digital entities, licenses have a lifecycle. Licenses are created, used to create new licenses, destroyed, expired, abolished, exercised, transferred, shared, etc. An expression of rights interoperability, while helpful in creating an interoperable DRM system, allows such a system to be involved throughout the life cycle of a digital license. Not all the functionality needed for this is provided.

  Because of these difficulties and others, the best possible strategy is to create a DRM standard for a given market in a given country (eg, a DVD movie in the United States). Thus, with current DRM system approaches, consumers are destined to address multiple DRM systems and the problem of DRM interoperability.

  Accordingly, there is a need for methods, systems, and devices that address the above and other problems associated with conventional content-centric systems and methods. This need and others are addressed by exemplary embodiments of the present invention, but these embodiments can be deployed and are “license centric” for digital content distribution and rights management. It provides methods, systems and devices that significantly improve the consumer experience by facilitating the scheme. A typical shared license repository to provide a rich set of lifecycle functions (including, for example, functions such as peer-to-peer license transfer, renewal, discovery, acquisition, conversion from one DRM to another) It is possible to configure. In the exemplary embodiment described above, consumers can choose from various repositories such as handheld devices and web services based on their preferences. In these exemplary embodiments, the consumer handling experience for many homogeneous DRM systems is enhanced by providing mechanisms and interfaces that allow interoperability of shared license repositories and proprietary DRM systems.

  Thus, in an exemplary aspect of the present invention, a method, system and device for use or distribution of license-centric content is provided, which is directed to a repository of its own data to define content usage. An existing DRM (Digital Rights Management) system with its own interface and a shared license configured to access data to regulate the use of content and to communicate with the existing interface of this existing DRM system Configured to interact with the repository and this existing DRM system and to allow the user to send the associated license for the content from the shared license repository to the existing DRM system or other shared license repository Configured users And an interface.

  Other aspects, features and advantages of the present invention will be apparent from the following detailed description, which are merely illustrative of the many exemplary embodiments and examples, including the best mode contemplated for carrying out the invention. It will be readily apparent. The present invention is also capable of various other embodiments, and its several details can be modified in various respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and description are to be regarded as illustrative in nature and not as restrictive.

Embodiments of the present invention are illustrated by way of example and not limitation in the following figures and accompanying drawings, in which like reference numerals represent like parts.
FIG. 2 illustrates an exemplary system for describing interaction between exemplary components. FIG. 2 shows an overview of an exemplary process using the shared digital repository of FIG. FIG. 2 illustrates an exemplary system for describing a shared license repository that provides a basic level of interoperability between proprietary DRM systems. FIG. 2 illustrates an exemplary system that includes only one of the components shown in FIG.

  The present invention includes the recognition that in the current state of consumption of digital content, in a “content centric” manner, the consumed content is combined with a specific consuming application. For example, if a consumer wants to consume digital content, double-clicking the file containing the content in his / her file system explorer will launch an appropriate content consumption application. The right to consume content is often associated with specific embodiments of such content. For example, the right to view a movie is tied to the physical ownership of the DVD. If the content is protected by a DRM (Digital Rights Management) system, the use of this content depends on the use of the specific DRM system originally used to protect this content. For example, if a consumer purchases a content license from Company A, the consumer must install Company A's DRM system on a consumer device for consuming the corresponding content.

  These exemplary embodiments improve the content centric method by introducing the concept of “license centric” digital rights management. Consumers want to focus their attention on the rights they have to use the content. Consumers want to be able to easily manage such rights. Consumers do not like the situation where content can only be used in the specific combination of content media or format, consumer application, consumer device and DRM system. In the context of an exemplary embodiment, the license may include a display of usage rules recorded with a representation of rights. A license can convey the entire context of an approved right. Information recorded in the license may include rights approver, rights assignee, content, authorized usage and associated terms and conditions. The representation of rights may include a digital form of rights expression. Examples of rights representations can include rights based on, for example, an XML-based rights expression language, such as ISO MPEG REL, XrML, SAML, XACML, ODRL, OMA REL, data structure, bit field, and the like.

According to this exemplary embodiment, the consumer acquires content licenses (eg, purchases, rentals, exchanges and donations) and uses such licenses to use consumer applications, devices, and content distribution media. This content can be used (eg, consumed, rendered, distributed, shared) independently of the DRM system used to enforce the license terms. For example, a consumer can purchase a license to watch a movie, but such license need not be tied to a particular embodiment of such a DVD, such as a DVD. Even if this same movie is available on another medium, such as pay-per-view broadcasts or high definition DVDs, this consumer's license is deemed to allow this rendering, It is effective for the purpose of watching movies. As another example, suppose a consumer has acquired a license to play a movie on any device in his home domain. This license can be displayed as an icon on the person's desktop. When this license icon is dropped on DRM Player I (eg, Real Player), the movie is played on his PC monitor. If you drag the same license icon to DRM Player II (for example, Windows® Media Player), the movie will still appear (for example, DRM Player).
On a large screen driven by II). The DRM Player retrieves content related to a license suitable for the rendering environment (for example, as needed). Similarly, when this license is transferred to a mobile phone or portable player, these devices can also retrieve and render content (if needed) as long as they belong to the home domain It is. This is much more convenient for consumers than state-of-the-art DRM systems.

  In these exemplary embodiments, consumers can access their inventory of purchased licenses independent of their location, consuming application or device, or the proprietary DRM system that created this license. It is. These exemplary embodiments include a typical license repository that provides consumers with one point of contact to manage all of their licenses. This typical license repository is a consistent user interface for heterogeneous DRM systems, while at the same time facilitating interoperability between such systems. These exemplary embodiments include the storage and management of digital licenses and an interface for accessing such licenses.

  Thus, in contrast to currently marketed systems, these exemplary embodiments employ a “license centric” scheme for the distribution of DRM-enabled digital content. Consumers can acquire content licenses and use this content using such licenses regardless of the consumer application or device they use, the content distribution medium, the DRM system that enforces the license terms, etc. Become. For example, a consumer can purchase a license for a music track, but this license need not be tied to a particular embodiment of this music, such as a CD. Even if this same music is available on another medium, such as an MP3 file for download, the consumer license is still valid as this license allows such rendering, and Applicable.

  In order to enable such a “license centric” scheme, these exemplary embodiments allow consumers to focus on licenses rather than instances of content, thereby Improving the experience. These exemplary embodiments allow consumers to better understand and utilize their licenses, such as acquisition, peer-to-peer transfers (eg, lending, selling, etc.), exploring, updating, archiving, inventory, etc. It enhances the consumer experience by making it possible to perform cycle functions. These exemplary embodiments provide a consistent user experience and a single point of contact for using and managing all licenses, the consumer location, the consuming device, and the entity that created these licenses (eg, Proprietary DRM system, content owner and content distributor). These exemplary embodiments provide a minimal but 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 benefits, these exemplary embodiments provide mobile access to a shared digital license repository and provide lifecycle management for stored licenses. These exemplary embodiments include a storage area for digital licenses and an interface for accessing such licenses.

  Referring now to the drawings, wherein like reference numerals indicate like or corresponding elements throughout the several views, and particularly to FIG. 1 therein, license-centric content according to an exemplary embodiment A system 100 for consumption is illustrated. In FIG. 1, an exemplary system 100 for license-centric content consumption may include licenses 106, 108, 128, 130, 132, and 134 that represent content usage rules. The format of these licenses is standardized as licenses 106, 128, 130 and 132, or is proprietary such as licenses 108 and 134. One part of the proprietary license is the legal terms and conditions that the user agrees to when acquiring the content, and this content exists inside the proprietary DRM system and understands these terms and conditions This forms the basis of a proprietary license. The exemplary system 100 is a shared digital license repository 142 that can be used by or shared by one of a plurality of DRM systems and / or instances of DRM systems 136, 138, 140. Can be included.

  This shared digital license repository 142 interfaces with one or more of the proprietary DRM systems 136, 138 and 140, including the proprietary DRM system repository, the proprietary DRM system program interfaces 122, 124, 126 and / or the DRM system itself. One or more of the program interfaces 110, 112, and 114 may be included. These program interfaces 110, 112, 114, 122, 124 and 126 are logical functions. These can each be implemented as part of a license repository and a proprietary DRM system or as separate external glue modules. The shared digital license repository 142 is configured to manage licenses and further includes a license management user interface 104 configured as part of the shared license repository 142 and / or as part of the proprietary DRM systems 136, 138, and 140. One or more can be included.

  These proprietary DRM systems 136, 138, and 140 may include DRM license repositories that are proprietary to the respective DRM system, where the program interface 122, between the instances of the shared digital license repository 142, 124 and 126 are configured to be able to transfer licenses between them. The proprietary DRM systems 136, 138, and 140 may also include license management user interfaces 116, 118, and 120 that are configured to manage the transfer of licenses between instances of the shared digital license repository. The proprietary DRM systems 136, 138 and 140 are configured to allow program interfaces 122, 124 and 126 between service providers and acquisition of licenses from the respective service providers, and to the shared digital license repository 142. A shared digital license repository 142 configured to store licenses may be included. These license management user interfaces 116, 118, and 120 can also be configured to manage the acquisition of new licenses from service providers and to store licenses in the shared digital license repository 142.

  The shared digital license repository 142 can also include an authentication component 144 configured to authenticate the shared digital repository 142 itself and / or a user / owner of the shared digital license repository 142. This shared digital license repository 142 can also be configured as a repository of digital content. The exemplary system 100 need not include all of the components described in connection with FIG. 1, while another exemplary embodiment can include only one part of these described components.

  At the heart of this exemplary system is a digital license repository 142, which can be shared by multiple proprietary DRM systems 136, 138 and 140. Repository 142 has a license that is expressly expressed or implied by the circumstances (e.g., having a CD implies that you have a license to play the corresponding music). It is possible to remember, search and understand. Such a license can be displayed in a form unique to the repository 142. In order to facilitate access to the licenses in the digital license repository 142 from any suitable location or device, the repository 142 may be placed in a network such as a mobile physical device, a PC or set-top box, or a game console that the user can carry. Or a device attached to a domain control device, a software application running on a standard platform, or a service accessible from various locations.

  Shared digital license repository 142 allows multiple agents to participate in the license lifecycle, where they do not need to understand a proprietary representation of such licenses. There are advantages. The interfaces 110, 112, and 114 of the shared digital license repository 142 are configured to search for licenses, obtain licenses, transfer licenses peer-to-peer, update licenses, convert licenses between proprietary DRM system formats, and so forth. Is possible.

  In order to interact with the user, the shared digital license repository 142 includes a license management user interface 104 that allows the user to interpret the contents of the repository 142 and for licenses stored in the repository 142. Lifecycle functions can be implemented, but these functions include, for example, backup, acquisition of new licenses, transfer of licenses, license search, license status, status and inventory reporting, license renewal, retirement Functions such as cleaning licenses issued, issuing licenses, converting licenses to standard formats, converting licenses between proprietary formats, and archiving licenses to paper or other digital formats. .

  In order to interact with the proprietary DRM systems 136, 138 and 140, the shared digital license repository 142 includes program interfaces 110, 112 and 114, which allow storage, search, retrieval and specific DRM systems 136, 138. And other license lifecycle functions including rights expressions specific to 140 are possible. These interfaces 110, 112, and 114 allow interoperability between DRM systems 136, 138, and 140, where DRM systems 136, 138, and 140 need to understand each other's proprietary rights expressions. There is an advantage that there is no. The shared digital license repository 142 can also be configured to output proof of identity features via an authentication component 144 that allows, for example, the proprietary DRM systems 136, 138 and 140 to authenticate users. .

  The shared digital license repository 142 can interact with other digital license repositories 142. Each shared digital license repository 142 is configured to include a standardized (eg, physical, programmatic, wireless, multiplexed, etc.) interface that allows the shared digital license repository 142 to exchange licenses. Is possible. The ability to interact with other shared license repositories 142 allows the user to select repositories based on their preferred operating experience for licenses and to transfer licenses between repositories. One or more shared digital license repositories 142 can be implemented within a single computing entity. For example, a shared digital license repository service may be provided to a plurality of users using a license repository service.

  The shared license repository 142 can also interact with this particular DRM system using a proprietary interface provided by the particular DRM system. As a result, the shared license repository 142 can interoperate with a DRM system that does not support the native program interfaces 110, 112, and 114 provided therein.

  FIG. 2 shows an overview of typical steps for using the shared license repository 142, where the user acquires and configures the shared digital license repository 142 at step 202. In this exemplary embodiment, unlike conventional DRM systems that are restricted to proprietary repositories, the user can choose a repository from a third party. The shared digital license repository 142 may be a device such as a handheld device that a user purchases, a software application that operates on a standard platform, a widely available service such as a web service or a service that can be used on a cellular phone, or the like. . Various user interfaces can be provided by implementing the shared digital license repository 142 in various ways, so that each user can provide an offer from the available shared digital license repository 142, for example, to the user's preferences. It is possible to choose based on. The user can then use this chosen shared digital license repository 142 to manage all his licenses independently of the DRM that created them.

  In steps 204-206, the shared digital license repository 142 pre-loads a collection of licenses or interacts with other digital license repositories 142 or various proprietary DRM systems 136, 138, 140 to obtain previously License can be obtained. The user can actively or passively acquire a license, such as purchasing content or a rendering program. The shared digital license repository 142 can interact with the DRM systems 136, 138, 140 using the proprietary interfaces 122, 124, 126 for each of the DRM systems 136, 138, 140. The shared digital license repository 142 can store a copy of all licenses previously purchased by the user. The shared digital license repository 142 may copy the user's license from each of the DRM systems 136, 138, 140 (eg, by a pull process), or the DRM system 136, 138, 140 may share the user's license. It can be configured to copy (eg, by a push process) to the repository 142. Licenses can be explicitly expressed or implied based on the status of the DRM system for consumption (e.g., owning a DVD plays the video encoded in it) It implies that you have a license.

  The shared digital license repository 142 uses the content with any suitable DRM system (eg, rendering, consumption, copying and distribution) by providing the necessary licenses in the proprietary format of the consumer DRM system. ) Is allowed. To use the content, an appropriate license may be provided to the consumer DRM system from the user's shared license repository 142. With the shared digital license repository 142, it is also possible to authenticate that the user consumes the content, for example by the authentication component 144. Depending on how the shared digital license repository 142 is implemented, an encryption key, a biometric authentication mechanism, or the like may be used for authentication.

  In steps 208 to 216, the shared digital license repository 142 can provide the user with a centralized license user interface that provides many features to manage using this license throughout the license lifecycle. The user can choose from available repositories based on user preferences and can manage the license independently of the various DRM systems that originally created the license. In the exemplary embodiment, shared license repository 142 implements a rich set of lifecycle functions including license transfer (eg, peer-to-peer transfer), renewal, search, acquisition, conversion from one DRM to another, etc. It is possible.

  In yet another exemplary embodiment, a trust mechanism such as a digital signature provided by the originating DRM system can be preserved when the license is stored in the shared digital license repository 142. If proof of license authentication cannot be extracted from the original DRM system or cannot be provided to the consumer DRM system, the license authentication is performed using the shared license repository 142. It is possible to prove this.

  This exemplary embodiment provides many advantages over conventional DRM systems. For example, in terms of user experience consistency, this exemplary embodiment allows a consumer to perform license management operations using a single user interface. Thus, in this exemplary embodiment, the shared license repository 142 includes a license management user interface 104 that can be used by a user to manage licenses regardless of where the license is stored, the entity that created the license ( For example, a DRM system, content owner, and content distributor) or a DRM system used to exercise licensed rights corresponding to this license. License management user interface 104 can interact with proprietary DRM license repositories 136, 138, and 140 on behalf of the user. As an advantage, the user does not have to interact directly with the various DRM systems 136, 138 and 140 from which the license is created.

  Using the license management user interface 104, the user can view information on all licenses acquired so far, including information on DRM systems to which such licenses are applied. By employing this license management user interface 104, the user can use the shared license repository 142 to acquire additional licenses or renew expired licenses from any suitable DRM system. It is. This acquired license can be communicated directly to the shared license repository 142 for storage purposes. Users can also transfer licenses peer-to-peer to other users via the license management user interface 104. Upon transfer, the original user license can be expired, abolished, or destroyed, and a new license for another user can be created in this user's shared license repository 142. . The license management user interface 104 also allows the user to make an archive copy of the license stored in the shared digital license repository 142 so that the DRM system fails, software / hardware is moved or updated. Or when authentication information such as an e-mail account or password is changed.

  FIG. 3 illustrates an exemplary system 300 that includes a shared license repository 142 that provides a basic level of interoperability between proprietary DRM systems 136, 138, 140. The exemplary system 300 of FIG. 3 operates in the same way as the exemplary system 100 of FIG. 1 with respect to common components.

  FIG. 4 shows a further exemplary system 400 that omits the shared license repository 142 component, but instead, a virtual shared repository that combines the licenses stored in the proprietary DRM systems 136, 138, 140. A shared license management user interface 104 is used. In FIG. 4, the shared license management user interface 104 can be configured to provide a list of all user licenses stored in the proprietary DRM repository 136, 138, 140. To perform management operations, the user interacts with the shared license management user interface 104 using the program interfaces 122, 124, 126 provided by the proprietary DRM system 136, 138, 140 to result in the user's request. . In other respects, the exemplary system 400 of FIG. 4 operates in the same manner as the exemplary systems 100 and 300 of FIGS. 1 and 3, respectively, with respect to common components.

  This exemplary embodiment provides a centralized license inventory. For example, in this exemplary embodiment, a consumer may have different formats (eg, DVD, redbook audio) for different devices (PC, set-top box, car stereo, remotely networked device, etc.). , Computer DVDs, streaming, etc.), allowing content to be purchased from various sources (eg, brick and mortar stores, satellite / cable, internet downloads, etc.). The exemplary embodiment also allows the consumer to access the content according to the corresponding license regardless of the location of the license that originally created the license, the consuming device, or the DRM system. Thus, in this exemplary embodiment, all content is made available to any suitable device capable of rendering content within the usage rules defined by the corresponding license for this content.

  Thus, the shared digital license repository 142 can store a copy of all licenses acquired so far for the user and provide a centralized inventory of these licenses. The shared digital license repository 142 copies the user's license from each of the DRM systems 136, 138, 140 (eg, by a pull process), or the DRM system 136, 138, 140 transfers the user's license to the shared license repository 142. It is possible to copy (for example by a push process). The shared digital license repository 142 can interact with the DRM systems 136, 138, 140 using the proprietary program interfaces 122, 124, 126 for each of the DRM systems 136, 138, 140. The shared digital license repository 142 can be pre-loaded with a collection of licenses such as all HBO programs and NFL programs when the repository 142 is acquired. A service or software program can be employed to collect the licenses previously acquired by the user and load these licenses into the shared digital license repository 142. Thus, while this exemplary embodiment provides an exemplary means of achieving centralization of licenses, other equivalent means can be used in yet another exemplary embodiment.

  In this exemplary embodiment, the user can select a shared digital license repository and a DRM system. For example, any suitable number of parties may provide a shared digital license repository 142 implementation. The user can select which shared digital license repository 142 is to be used based on preferences. Depending on these various implementations, the shared license repository 142 offerings depend on factors such as license storage and access to licenses (for example, portable devices with hardware interfaces, widely available web services, etc.) Differences may occur.

  These factors may further include features of the provided license management interface 104. For example, the license management interface 104 provided by the shared digital license repository 142 unifies the list of the licenses of each user regardless of the DRM system that created the license and the proprietary license repository in which the license is stored. It is possible to provide.

  An additional factor may include a set of supported proprietary DRM systems. Thus, each shared digital license repository 142 can provide interoperability with a specified set of proprietary DRM license repositories. For example, implementer A may provide shared license repository 142 as a web service that interoperates with proprietary DRM systems A, B, and C. Implementer A's shared license repository 142 is capable of maintaining a copy of all licenses that a particular consumer has acquired from proprietary DRM systems A, B, and C. Other implementers B can exclude C by limiting interoperability to DRM systems A and B.

  An additional factor may be price, in which case the DRM merchant can provide its own proprietary user interface 104 that interoperates with the shared digital license repository 142. Various DRM vendor offerings include devices used by the user to interact with the shared digital license repository 142 (PC, PDA, cellular phone, etc.) and user interface presentations (eg, graphic or text based) It is possible to make a difference depending on factors such as the function of the interface (for example, simple or full), the set of supported shared digital license repositories, price, etc. As an advantage, the user can select which user interface 104 to use based on his / her preference, and can centrally store all his / her licenses in the shared license repository 142.

  In the exemplary embodiment, a shared digital license repository 142 can be used to authenticate the user. For example, if the consumer wants to use licensed content, shared digital license repository 142 can optionally authenticate the user, for example, by authentication component 144. Depending on how the shared digital license repository 142 is implemented, an encryption key, a biometric authentication mechanism, or the like may be used for such authentication. For example, X.com with approval of property ownership. An authentication license in the form of a 509 digital certificate or ISO MPEG REL license can be provided to the consuming DRM system in the following manner.

  In an exemplary embodiment, the shared license repository 142 can provide the necessary licenses to the consuming DRM system in the proprietary format of the DRM system. For example, the shared license repository 142 can be used as a web service, and if the consumer uses a PDA to consume content, the shared digital license repository 142 has an authentication license resident on the PDA. It can be supplied in a proprietary format suitable for existing DRM systems.

  In another exemplary embodiment, the consumer can copy the appropriate license from the shared digital license repository 142 to the consuming DRM system. For example, if the shared digital license repository 142 is available as a portable device and the consumer is using a personal computer to consume content, the consumer can transfer the license to the personal computer in an appropriate proprietary format. It is possible to copy to a resident DRM system.

  In yet another exemplary embodiment, when the shared digital license repository 142 is instantiated in the form of a smart card, the shared digital license repository 142 plugs the smart card into a host device such as a PC, set-top box, game console or the like. Can be used. In this case, the access and use of the content can be made possible by assuming that the authentication license and the use license can be used for the host device.

  This exemplary embodiment can be used to independently verify content acquisition. For example, a trust mechanism such as a digital signature provided by the original DRM system can be saved when the license is stored in the shared license repository 142. If the proof that the license is authentic cannot be extracted from the original DRM system or provided to the consuming DRM system, the shared digital license repository 142 is configured to verify that the license is authentic. Is possible.

  In this way, the shared digital license repository 142 can independently verify that the content has been acquired. In this role, the shared digital license repository 142 acts as an independent agent that determines whether, when, how and where a license has been previously acquired. DRM systems other than the authoring DRM system accept such licenses based on the trust in the shared digital license repository 142 and verify that the license exists and deserves trust. In addition, if the shared digital license repository 142 requires that such a license stored in the repository 142 be later reissued by the DRM system that created the license, the consumer It is possible to prove that this license has been acquired.

  This exemplary embodiment can be used to exchange licenses between interoperable repositories 142. For example, this exemplary embodiment allows content to be accessed according to the consumer's corresponding license, regardless of the location of the license or the consuming device. Any number of parties may provide an interoperable repository 142 and may provide a license management interface for such repositories so that each consumer can use it. It is possible to select one or more interoperable repositories based on preferences.

  In order to allow consumers to access content from any suitable location or using any suitable consumer device, the exemplary embodiment provides an interoperable repository 142 that can exchange licenses. Contains. For example, assuming that a consumer uses two interoperable repositories 142, one on a portable video player and one available as a web service, the consumer may have a specific If you have a license to play a movie, this exemplary embodiment allows the consumer to transfer the license to the Web service so that the movie can be played on a personal computer. Yes. Similarly, when a consumer uses a shared digital license repository 142 on a handheld device and purchases a new handheld device, the exemplary embodiment transfers this license from the old device to the new device. To make it possible. In order to provide such functionality, each shared digital license repository 142 is a standardized interface (e.g., a physical interface) that enables the repository 142 to exchange licenses with other interoperable repositories 142. , A program interface or both).

  In this way, the exemplary embodiment provides interoperability, and it is expected that there will be heterogeneous types in the DRM market over the next few years, so that the exemplary embodiment is protected by consuming DRM. The present invention provides a method for facilitating the simultaneous deployment of such incompatible DRM systems while making the consumed content acceptable. By providing such a level of interoperability, the exemplary embodiment can provide a consistent user interface for disparate DRM systems. This exemplary embodiment has the advantage of accessing a digital license from a mobile, regardless of the proprietary nature of the DRM system that created the license.

  The exemplary embodiment may include a dedicated handheld license repository 142. For example, a user can purchase a portable license repository device 142 configured according to this exemplary embodiment from a department store. The user can choose to purchase this device 142 based on the various features that make it different from competing devices offered by different manufacturers, For example, form factor, device ergonomics, user interface, perceived robustness and reliability, good or extensive support for proprietary DRM APIs, availability, connectivity, peer-to-peer service compatibility There is a price. For example, the user supports USB and wireless service connectivity and can operate with and store any appropriate type of content license, such as Adobe (registered trademark) or Microsoft (registered). ™ and Adelphia DRM systems, and can be connected to Microsoft Windows® or MAC OS® computers, cellular phones, set-top boxes or portable MP3 players It is possible to purchase a portable license repository 142 configured in accordance with an embodiment. Such a device can be configured as a dedicated device, or the license repository 142 can be a feature of such a device that includes other functions.

  In this scenario, when the user returns home, he or she uses a USB or wireless connection function to run a dedicated handheld license repository device 142, eg, Microsoft Windows® or any other software. It can be attached to a proprietary DRM system of Adobe, Microsoft, or Adelphia on its own personal computer. The repository device 142 can authenticate the user using biometric authentication information (eg, a fingerprint) or the repository device itself can authenticate the user (eg, in the case of a smart card). The device 142 interacts with each of the proprietary DRM systems 136, 138, 140 using the corresponding proprietary interfaces 122, 124, 126, and extracts a user inventory of the purchased licenses from the proprietary DRM systems 136, 138, 140. It is possible to store a copy of the extracted license. The user can use the screen of the device 142 to view an inventory of purchased licenses, including content and information about the proprietary DRM systems 136, 138 and 140 to which the respective licenses are applied.

  Periodically, the user can back up the license stored on the device 142 on the computer. The advantage is that even if the portable repository device 142 fails, is lost, stolen, or replaced by a “new and improved” device 142, the user has all the licenses he has acquired so far The user can transfer a backup copy of the license to the replacement device.

If a user goes to a friend's house and downloads digital content from the Internet to the friend's Apple MAC computer, the user can connect his / her own license repository device 142 to the friend's computer. Also, you can use your friend's Apple
It can be available in the DRM system. As an advantage, in this way, the user can consume the downloaded content on his friend's computer using his own license and the Apple DRM system installed on the friend's computer. .

  The exemplary embodiment may include a shared license repository 142 configured as a service. For example, a user can subscribe to a web-based service that provides a shared license repository 142. Users can access this shared license repository 142 service from any suitable device with connectivity, regardless of the type of physical connection (eg, DSL, cable modem service, wireless access, satellite access). Is possible. Users can choose the shared licensing repository 142 web service based on various features that make it different from competing services, such as perceived robustness and reliability, proprietary There is good or extensive support for DRM APIs, service functions such as backup and reporting, availability, connectivity, peer-to-peer service compatibility, and price. For example, users can collaborate and store licenses for any type of content where appropriate, and apply for a shared license repository 142 service that is interoperable with Adobe, Microsoft, and Adelphia DRM systems. It is possible.

  Users can connect to the shared license repository 142 service from their home using their DSL Internet connection and provide a username and password as authentication information. Users can request that the shared license repository 142 service interact with Adobe, Microsoft, and Adelphia's proprietary DRM systems 136, 138, 140 to obtain the user's license from each of the systems 136, 138, 140. It is. The shared license repository 142 service interacts with each of the systems 136, 138, 140 using its proprietary interface 136, 138, 140 to extract a user inventory of acquired licenses from each of the systems 136, 138, 140. It is possible to store a copy of these licenses. The user can browse his / her inventory of acquired licenses using the web page of the service of the shared license repository 142, including information regarding the DRM system to which these licenses are applied.

  When a user goes to a friend's house and downloads electronic content obtained from the Internet to the friend's computer, the user connects to the service of the shared license repository 142 using the friend's computer and a cable modem, You can copy your license for this content into this friend's Microsoft DRM system. The user can then consume the downloaded content on his friend's computer using his license and the Microsoft DRM system installed on the friend's computer.

  The exemplary embodiment may include a shared digital license repository 142 configured as a non-dedicated handheld device. In an exemplary embodiment, the non-dedicated handheld repository device 142 can be integrated into a device with another function, such as a cellular phone, PDA, portable game station, portable video player or MP3 player. . For example, a user can purchase a PDA that includes a shared license repository 142. The user can store a license for content protected by any suitable proprietary DRM system in the PDA. A user can consume such protected content using a PDA device or connect the PDA device to another consumer device such as a PC. In either case, the shared license repository 142 on the PDA can interoperate with proprietary DRM systems 136, 138, 140 that are used to protect content.

  In this scenario, communication between the proprietary DRM system 136, 138, 140 and the shared license repository 142 uses the standardized interface 110, 112, 114 of the shared license repository 142, and such interface is connected to the DRM system 136, 138. , 140 can be implemented. If this is not possible, communication between the proprietary DRM systems 136, 138, 140 and the shared license repository 142 can be performed using the proprietary interfaces 122, 124, 126 of the proprietary DRM systems 136, 138, 140. is there.

  The exemplary embodiment may include a repository 142 that interoperates with a DRM system that uses a proprietary interface. For example, a user can work with and store licenses for any suitable type of content, and can also interoperate with Adobe, Microsoft, and Adelphia DRM systems 136, 138, 140. It is possible to apply for a web-based service that provides the repository 142.

  In this scenario, the user can use a computer to view an Adobe PDF file in which the user has stored a license for it in the web service of the shared license repository 142. Adobe Reader® prompts the user to locate the license if it is impossible to locate where the license for this PDF file is in Adobe's proprietary license repository. The user can provide the URL of the shared license repository 142 web service, and the Adobe DRM system uses its proprietary interface to interact with the shared license repository 142 web service to obtain the appropriate license. It becomes possible. In practice, the repository 142 operates as a repository that Adobe Reader already understands, instead of a new standardized repository. The Adobe DRM system now checks the provided license to determine if the specified usage rules are satisfied, and if so, the Adobe Reader can render the PDF file. is there.

  The exemplary embodiment may include a repository 142 that interoperates with a DRM system using a standard interface. For example, a user can purchase a dedicated portable repository device 142 that supports USB and wireless service connectivity. The device 142 can provide a standard program interface that is interoperable with any suitable DRM system that supports such an interface, and can store licenses for any type of content. Is possible.

  In this scenario, when the user returns home, he attaches a dedicated portable repository 142 to Microsoft, Adobe, and Apple's DRM systems 136, 138, 140, all of which support the repository 142 standard interface. ing. This dedicated portable repository 142 interacts with each of the DRM systems 136, 138, 140 using such a standard interface and collects the user's inventory of acquired licenses from each of the DRM systems 136, 138, 140. It is possible to extract and store copies of these licenses.

  The user can go to his friend's house and download a video clip corresponding to the license he has to the friend's computer from the Internet. The user can then try to play the video clip using Windows® Media Player, but Windows® Media Player will license the video clip on this friend's computer. If it is impossible to locate the location, Windows® Media Player may prompt the user to locate the license. The user can connect a dedicated portable repository 142 to the friend's computer and designate the dedicated portable repository 142 as a license location. The Microsoft DRM system on this friend's computer can now interact with the repository 142 using the standard interface of the dedicated portable repository 142 to obtain an appropriate license. In such cases, Microsoft's DRM system has been modified to support a new repository interface that is explicitly intended to allow consumers to have a shared license repository 142. Microsoft's DRM system checks the provided licenses to see if the specified usage rules are satisfied, and if so, Windows Media Player renders the video clip It becomes possible.

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

  For example, assume that a user connects a dedicated portable repository device 142 to a portable MP3 player and wants to purchase a music file. Using the interface of a dedicated portable repository device 142 and a wireless Internet connection, the user can search for the music he wants to purchase. The search interface of the dedicated portable repository device 142 is licensed with either a standardized format of the device 142 or a proprietary format of the DRM system 136, 138, 140 with which the dedicated handheld repository device 142 can interoperate. It is possible to send back all matching music files that are related. The user can select the license he / she wants to acquire (for example, the license with the lowest cost). The dedicated portable repository device 142 can obtain this selected license and can then download the music file to the user's MP3 player. When the user plays the music file, the dedicated portable repository device 142 can provide a license to the proprietary DRM system used to protect the music file.

  In this exemplary embodiment, peer-to-peer communication between dedicated portable repositories is possible. In this scenario, two users, Jack and Nancy, purchase a dedicated portable repository device 142 to license many types of content protected by various proprietary DRM systems 136, 138, 140. 142 can be stored. Although not necessarily from the same manufacturer, both devices 142 can support the same standardized interface so that the devices 142 communicate with each other to transfer and loan licenses ( Various peer-to-peer behaviors can be performed, including for example temporary transfers).

  For example, if Jack wants to transfer his own license for an ebook to Nancy's device 142, Jack connects his device 142 to Nancy's device 142 and the user interface on his device 142 This license can be transferred using The original license in Jack's dedicated portable repository device 142 can be abolished and a new same license can be created on Nancy's dedicated portable repository device 142. This scenario is practical for licenses that grant usage rights to groups of people, such as members of a book club to which both Jack and Nancy belong. A proprietary DRM system that creates and consumes transferred licenses can allow a dedicated portable repository device 142 to perform this type of license revocation and creation. Therefore, when Nancy tries to use this new license, the proprietary DRM system trusts her license and allows her to read the e-book.

  In a similar example, Jack can transfer his license for the e-book to Nancy's device 142, and also when the original license on Jack's dedicated portable repository device 142 expires. It is possible to attach. A new similar license can be created on Nancy's dedicated portable repository device 142. The new license can authorize the same usage rights as above, but may designate Nancy as the other person to whom such rights are authorized. Again, a proprietary DRM system that creates and consumes transferred licenses can allow a dedicated portable repository device 142 to perform this type of license revocation and creation. Therefore, when Nancy tries to use this new license, the proprietary DRM system trusts her license and allows her to read the e-book.

  In a further exemplary embodiment, Jack can lend his license to Nancy (eg, a temporary transfer). In this case, Jack's license has been revoked during this lending period, so Nancy's license can only be valid during this lending period. Once this loan is over, Jack's license can be restarted, and Nancy's license expires. Again, the proprietary DRM system that creates and consumes this license can allow a dedicated portable repository device 142 to perform this type of license revocation and creation.

  In another exemplary embodiment, a dedicated portable repository device 142 can communicate with a proprietary DRM system in performing peer-to-peer operations. In this case, when Jack forwards his license to Nancy's device 142, Jack's dedicated portable repository device 142 marks this proprietary DRM system that Jack's license has expired, and Nancy's device 142 You can request to create a new license. Such a request can be implemented through a standardized interface of a dedicated portable repository device 142 if the proprietary DRM system supports such an interface. If not, the dedicated portable repository device 142 can make such a request using the proprietary interface of the DRM system.

  In yet another exemplary embodiment, the license transfer may involve a financial transaction and a third party such as an escrow or auction service. For example, Jack can auction a license for the right to play several audio files, similar to the sale of a used CD collection. Nancy can bid on this license and win this auction. Using a standardized interface provided by a dedicated portable repository device 142, Jack can transfer the license to an escrow account. Nancy can pay for this escrow account himself. The escrow service affects this transaction and uses its standardized interface to transfer payments to Jack and transfer licenses to Nancy's dedicated portable repository device 142.

  The exemplary embodiment may include a shared digital license repository 142 configured to provide a license storage area. In this exemplary embodiment, the shared digital license repository 142 can be used as a license storage service without or even having the license management user interface component 104. For example, a user may have a dedicated portable repository device 142 that can be used to store all licenses for him. When executing an appropriate license management function, the user may use a proprietary user interface provided by the DRM system 136, 138, 140 that creates and consumes the license.

  Whenever a user consumes content using a license stored on a dedicated portable repository device 142, the proprietary DRM system 136, 138, 140 can communicate with the device 142 in a variety of ways. is there. For example, the DRM system 136, 138, 140 can look for a suitable license on a dedicated portable repository device 142 and communicates with the device 142 using its standardized interface. The DRM system 136, 138, 140 can also look for a suitable license on a dedicated portable repository device 142 and communicate with the device 142 using the proprietary interface of the DRM system 136, 138, 140. The DRM system 136, 138, 140 can also look for a suitable license in the proprietary license store of the DRM system 136, 138, 140. A dedicated portable repository device 142 can be used as a replacement for such a license storage device, and transactions can be executed with the license of the portable repository device 142. Thus, to the proprietary DRM system 136, 138, 140, the dedicated portable repository device 142 may appear similar to the proprietary license store of the DRM system 136, 138, 140.

  The exemplary embodiment may include a shared digital license repository device 142 configured to verify content acquisition. For example, the user can use the shared digital license repository device 142 to deal with obsolete content media and DRM systems 136, 138, 140. By using this shared digital license repository device 142, a user can verify the purchase of a license for specific content even after the content medium that provided the implied license or the rendering device of this medium has become obsolete, It is possible to continue accessing such content.

  For example, suppose a user subscribes to a shared licensing repository 142 web service that interoperates with various proprietary DRM systems 136, 138, 140. This shared license repository 142 Web service is also available from Amazon.com. interoperable with various online retailers of physical content media such as com. Now, the user is Amazon. com can purchase a DVD of a movie, but purchasing a DVD here implies a license to play a movie encoded on the DVD. The web service of the shared digital license repository 142 can store such an implied license.

  Over time, this DVD may become obsolete (eg, the DVD will be replaced by streaming video), but since the user has already purchased this movie on a DVD, this exemplary embodiment is: Despite the user's copy of the DVD becoming obsolete, the user is allowed to continue watching the movie in another format. In this scenario, if the vendor that provides the streaming video wants to give a previously acquired license stored in the shared license repository 142 web service, the shared license repository 142 web service is a problem. It is possible to prove that the user has already obtained a license for the movie. The shared license repository 142 web service may now provide all of the details of the original license proof of purchase, including vendor (eg, Amazon.com), media (eg, DVD), purchase date, purchase price, etc. It becomes possible. Since the streaming video vendor can trust the shared licensing repository 142 web service, the user is allowed to view the corresponding movie on the streaming video.

  This exemplary embodiment includes a device that supports multiple physical interfaces. For example, the shared digital license repository 142 may be another repository or a DRM system that the repository 142 interoperates with, for example, USB, Bluetooth, 1394, PCMCIA, 802.11 (a / b / g), proprietary, RFID, CDMA, It is possible to include multiple physical mechanisms that connect to GSM and the like. Such connections can be operated in parallel, serial and similar manners.

  This exemplary embodiment includes devices that support various DRM APIs for extracting licenses. For example, one shared digital license repository 142 can be configured to interoperate with several different DRM systems to extract licenses therefrom. Such interoperability can be implemented via a proprietary API that each DRM system supports natively. For example, the repository 142 can be configured to operate as a rendering application for the purpose of extracting a license when communicating with Adobe's Acrobat. The repository 142 can query Adobe's Acrobat for permission rights for a given content and record the results.

  The exemplary embodiment includes a device that supports a new standard API for accessing a repository of a DRM system. For example, DRM vendors support standard APIs that allow direct support for the digital license repository 142 to explicitly allow each of the repositories 142 to query the DRM system to determine available licenses. Can be provided. The DRM system can be configured to push licenses to the shared digital license repository 142 using its own user interface, or the repository 142 can be configured to pull licenses from the DRM system. .

  In an exemplary embodiment, a user can use an instance of a DRM system, such as Windows Media Player, and the DRM system discovers the shared repository 142 while it is active. It is also possible to provide for storing and copying the licenses understood by the DRM instance in the repository 142.

  This exemplary embodiment includes a device that supports a mechanism for biometric authentication of users of such devices. Thus, one complication in creating a DRM system is authenticating who or what exercises the expressed rights. Most conventional DRM systems tie the use of a given digital content instance to one specific instance of the DRM system. For example, a license is typically granted for a given device or PC. However, in an exemplary embodiment, repository device 142 may provide an authentication service for a DRM system such as a fingerprint reader. The DRM system can query the repository 142 to check the user's fingerprint of the device. In this way, instead of tying a license to an instance of a DRM system, it is possible to tie it to a fingerprint of a user connected to the repository 142 or multiple DRM systems.

  In an exemplary embodiment, the DRM system may be configured to delegate user authentication to the repository device 142. This is similar to the typical biometric system described above, with the difference that it uses login ID and password devices, digital certificates, RFID or other types of user authentication systems that do not need to be based on biometrics, etc. It is a point. The DRM instance can tie content to the repository 142 authentication mechanism. The user selects a repository 142 that supports an authentication configuration that he is satisfied with. In another exemplary embodiment, a cell phone can be configured as a repository 142 to link the authentication capabilities of the cell phone with its native identification capabilities and the functionality of all repositories 142.

  In yet another exemplary embodiment, the shared digital license repository 142 can be configured as a unique key, which configures the DRM system to trust the authorization of the license if this unique key exists. It is possible. For example, a DRM system may be configured to check for accessibility to a uniquely identified repository 142, so that if the repository 142 is accessible, the rights to the associated content Can be exercised. As an advantage, this exemplary embodiment allows for the transfer of licenses, where rights to content move with the movement of the repository 142.

  The exemplary embodiment includes a repository 142 that is configured as a connected service (eg, cell phone service, Internet service, satellite service, etc.) rather than as a physical device. Therefore, the repository 142 does not need to be a physical device owned by a consumer, and can be configured as an Internet or mobile phone service. In such a case, the user can connect the repository 142 to an instance of the DRM system. Such a connection can be established in the DRM system if the DRM system natively supports an interface to the repository 142, or can be implemented via a multifunction device such as a cell phone. . For example, a user may have a Bluetooth enabled CDMA phone that he carries and may encounter a Windows PC and want to exercise a stored license. The telephone can be connected to this PC via Bluetooth, and when this telephone is used as an intermediary, this PC can be connected to the shared digital license repository 142 by CDMA. The PC can now find a license for use in the CDMA-based repository 142.

  The exemplary embodiment includes a user using the digital license repository 142 to search online and purchase a new license. For example, the repository 142 can be configured to operate as a storefront that obtains licenses from various services, including its own user interface. In this case, the user visits a friend's house and uses the repository 142 to search for content to be viewed or heard. Once the content is identified, it can be purchased and a new license can be sent to the repository 142. Then, it becomes possible to view and listen to this content using the DRM system in this friend's house.

  This exemplary embodiment creates an off-site archive copy of this device 142 in the future in the event that the shared digital license repository device 142 is lost, stolen, or destroyed. Includes users to remember for. Store these licenses using the shared digital license repository 142 or off-site archive copy in case the licenses of the proprietary DRM systems 136, 138, 140 are lost, stolen, or destroyed. It is possible to leave. For example, the repository 142 may be a paper base (eg OCR glyphs or text), a removable media base (eg CDR or smart card), a fixed media base (eg hard disk on a PC), a service base (eg Microsoft Passport), etc. It can be configured to support such a write mechanism. As an advantage, this allows users to search their license inventory if the device 142 is lost, stolen, or destroyed. Importing licenses from the archive can be proprietary or interoperable to the repository 142 brand to allow consumers to change the repository 142. .

  In one typical peer-to-peer license transfer, user A's shared digital license repository 142 can be attached to user B's repository, where one of user A's licenses expires and user A A new license is created that B can use. For example, two users can agree to transfer a license from one repository 142 to another. In short, they agree to exchange licenses for specific content instances. In this exemplary embodiment, a user connects two repositories 142 to each other to grant or sell a license. The repository 142 can include a mechanism for expiring or revoking licenses that are granted or sold.

  In an exemplary embodiment, repository device 142 may be allowed to expire and generate a new license, and the DRM system may delegate the execution of such functions to device 142. It is possible to configure. For example, it is possible for the DRM system to delegate the license expiration or termination to the repository 142. In an exemplary embodiment, the repository 142 can create a temporary license that can be exercised by the DRM system for a limited duration. In a system that is not connected, it is possible to entrust the repository 142 to generate a finite license.

  In an exemplary embodiment, the repository 142 uses a standardized API to connect to the DRM system that originally created the license to expire or reissue the license and transfer the license on a peer-to-peer basis. Is possible. For example, the repository 142 can be used to transfer a license from one DRM instance to another. Instead of two repositories 142 exchanging licenses, this exemplary embodiment allows two DRM systems to transfer licenses through repositories 142 and their connections. In this case, it is possible to grant the right to transfer the license, where the repository 142 acts as a pipe for this transfer.

  In an exemplary embodiment, the repository 142 can perform license revocation and issuance using a proprietary API to the DRM system that originally created the license to transfer the license peer-to-peer. is there. For example, the repository 142 acts as a responsible agent, and performs a transfer between two instances of the DRM system on behalf of the repository 142 using a standardized API, in cooperation with the DRM system. Can be easily transferred. This transfer may or may not be a function of either DRM system.

  In an exemplary embodiment, the repository 142 can be used to interpret rights. For example, the actual license can be stored in a DRM-neutral manner, where the repository 142 interprets the rights instead of converting the license into a form that the DRM system can understand. The repository 142 can be augmented with a suitable API that allows the DRM system to transfer the responsibility for interpreting the license to the repository 142.

  In an exemplary embodiment, repositories 142 can communicate with each other using a standardized API to perform various peer-to-peer activities. Therefore, since two or more repositories 142 are connected to each other, it is possible to form a system in which license holders share and discover licenses. A peer-to-peer network of repositories 142 can be formed to facilitate license pooling, real-time / online auctions, and similar operations. For example, a network of repositories 142 can be created and used to transfer licenses in real time. In order to join this network, the user must prepare, for example, five shared licenses. The user can then search the repository 142 network to identify the license he wishes to exercise. It is possible to lend or transfer licenses to the user's repository 142 in real time, and to notify the DRM system to allow consumption. Thereafter, the license can be presented back to the repository 142 network. As an advantage, such a typical system can potentially allow an unlimited number of users to “legally” access an unlimited number of licenses.

  In an exemplary embodiment, the repository 142 can be configured as a service to a DRM system, and the DRM system uses its user interface to implement license management functions using a standardized API. It is possible. For example, the repository 142 can provide itself as a way for the DRM system to use and search for licenses. Nevertheless, the DRM system can have a management user interface for such licenses, but the DRM system can now be configured to support the repository 142 API.

  In an exemplary embodiment, the repository 142 can be configured as a service to a DRM system, and the DRM system can use its own user interface to implement license management functions using a proprietary API. Is possible. For example, the repository 142 can provide itself as a way for the DRM system to use and search for licenses. Nevertheless, the DRM system may have an administrative user interface for such licenses, where the DRM system is made to use the repository 142 “tricked”. In this exemplary embodiment, repository 142 may be configured to intercept a license storage request native to the DRM system to provide such functionality.

  In one exemplary embodiment, repository 142 may include its own user interface to perform license management functions across each of the DRM systems via a standardized API. For example, the repository 142 user interface can be configured to allow a user to view licenses stored in an instance of the DRM system, where the DRM system uses a standardized API. It is possible to configure the repository 142 to allow access to the license storage device of the DRM system.

  In an exemplary embodiment, the repository 142 can include its own user interface to perform license management functions across each of the DRM systems via the proprietary API. For example, the repository 142 user interface can be configured to allow a user to view licenses stored in an instance of the DRM system, where the DRM system need not be modified. The repository 142 is configured to determine available licenses using the DRM system's native API.

  In an exemplary embodiment, the repository 142 uses standardized APIs to connect to escrow and auction services so that two users can discover each other and perform secure and remote license transactions on a peer-to-peer basis. It can be possible to execute. For example, a seller can connect his / her repository 142 to a service such as eBay and present a license for auction purposes, and then the eBay buyer can price the seller's repository 142 and the license stored in it. Can be browsed. If the escrow service then verifies that the payment has been made, the seller's repository 142 can be connected to the buyer's repository 142 and a license transfer can be performed.

  In certain exemplary embodiments, repository 142 may be configured to provide other types of peer-to-peer license transfers. For example, other types of peer-to-peer transfers such as license lending and resale can be supported between repositories 142. The repositories 142 can transfer licenses between each other and can agree to abolish and reinstate licenses that have been lent under appropriate conditions.

  In this exemplary embodiment, by providing better user interface, robustness, better proprietary API support, ergonomics, availability, peer-to-peer service compatibility, better price, reliability, etc. Companies can compete for the opportunity to create a repository 142 for consumers. The form, capability, expense and robustness of the repository 142 can be customized to find rights consumers. A good preference for this model is the diversity and functionality of cell phones and service programs in the wireless industry.

  The above-described devices and subsystems of the exemplary embodiment of FIGS. 1-4 may be any suitable server, workstation, PC, capable of performing the processes of the exemplary embodiment of FIGS. 1-4, for example. , Laptop computers, PDAs, internet appliances, handheld devices, cellular phones, wireless devices, portable players, other devices, and the like. The devices and subsystems of the exemplary embodiment of FIGS. 1-4 can communicate with each other using any suitable protocol and can be implemented using one or more programmed computer systems and devices. Is possible.

  One or more interface mechanisms may be used in the exemplary embodiments of FIGS. 1-4, including, for example, Internet access, telecommunications in any suitable form (eg, voice, modem, etc.), wireless communication media, etc. is there. For example, the communication networks used in the exemplary embodiments of FIGS. 1-4 are one or more wireless communication networks, cellular communication networks, G3 communication networks, PSTN (Public Switched Telephone Network), PDN (Packet Data Network), Internet , Intranets, combinations thereof, and the like.

  It should be understood that the devices and subsystems of the exemplary embodiment of FIGS. 1-4 are for illustrative purposes, and as many changes as possible are made to the specific hardware to implement the exemplary embodiment. Those skilled in the relevant art will understand that. For example, the functionality of one or more of the devices and subsystems of the exemplary embodiments of FIGS. 1-4 can be implemented using one or more programmed computer systems and devices.

  In order to implement these and other changes, one computer system may perform the special purpose functions of one or more of the devices and subsystems of the exemplary embodiments of FIGS. To program. On the other hand, two or more programmed computer systems or devices may be introduced in place of any one of the devices and subsystems of the exemplary embodiments of FIGS. Thus, the principles and advantages of distributed processing such as redundancy and replication can be implemented as desired to improve the robustness and performance of the exemplary embodiment devices and subsystems of FIGS. .

  The devices and subsystems of the exemplary embodiments of FIGS. 1-4 can store information related to various processes described herein. This information can be stored in one or more memories, such as a hard disk, optical disk, magneto-optical disk, RAM, etc., of the devices and subsystems of the exemplary embodiments of FIGS. One or more databases of devices and subsystems of the exemplary embodiment of FIGS. 1-4 can store information used to implement an exemplary embodiment of the present invention. These databases can be organized using data structures (eg, records, tables, arrays, fields, graphs, trees, lists, etc.) contained in one or more of the memory and storage devices listed in this document. Is possible. The processes described in connection with the exemplary embodiment of FIGS. 1-4 are collected and / or generated in the one or more databases by the device and subsystem processes of the exemplary embodiment of FIGS. Any suitable data structure for storing data can be included.

  As will be appreciated by those skilled in the computer and software arts, one or more general purpose computer systems, microprocessors, digital signal processors, microcontrollers, etc. programmed in accordance with the teachings of the exemplary embodiments of the invention In use, it is possible to conveniently implement all or part of the devices and subsystems of the exemplary embodiments of FIGS. As will be appreciated by those skilled in the software art, appropriate software can be readily created by programmers of ordinary skill based on the teachings of this exemplary embodiment. In addition, the devices and subsystems of the exemplary embodiments of FIGS. 1-4 can be implemented on the World Wide Web. In addition, as will be appreciated by those skilled in the electrical arts, the devices and subsystems of the exemplary embodiment of FIGS. 1-4 are conventional by creating an application specific integrated circuit or forming a suitable network. It can be realized by interconnecting component circuits. Thus, the exemplary embodiments are not limited to any specific combination of hardware circuitry and / or software.

  Controls the devices and subsystems of the exemplary embodiment of FIGS. 1-4 stored in any one or combination of computer-readable media and drives the devices and subsystems of the exemplary embodiment of FIGS. However, exemplary embodiments of the present invention may include software that enables the devices and subsystems of the exemplary embodiments of FIGS. 1-4 to interact with human users and the like. Such software can include, but is not limited to, device drivers, firmware, operating systems, development tools, application software, and the like. Such a computer readable medium further includes a computer program product of an embodiment of the present invention that performs all or part of the processing performed when implementing the present invention (if processing is distributed). Is possible. Computer code devices of exemplary embodiments of the present invention include, but are not limited to, interpretable programs (DLLs, Dynamic Link Libraries), Java classes and applets, fully executable programs, Any suitable interpretable or executable code mechanism may be included, including CORBA (Common Object Request Broker Architecture) objects and the like. In addition, portions of the processing of exemplary embodiments of the present invention can be distributed to improve performance, reliability, cost, etc.

  As mentioned above, the devices and subsystems of the exemplary embodiments of FIGS. 1-4 retain instructions programmed in accordance with the teachings of the present invention and also include the data structures, tables, records and / or described herein. Or it may include a computer readable medium or memory holding other data. Computer readable media can include any suitable media that participates in providing instructions to a processor for execution. Such a medium may take many forms, including but not limited to, non-volatile memories, volatile media, transmission media, and the like. Non-volatile media can include, for example, optical disks, magnetic disks, magneto-optical disks, and the like. Volatile media can include dynamic memory and the like. Transmission media can include coaxial cables, copper wire, optical fiber, and the like. Transmission media can also take the form of being generated during acoustic waves, light waves, electromagnetic waves and RF (radio frequency) communications, IR (infrared) 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 medium, CD-ROM, CDRW, DVD, any other Any suitable optical medium, punch card, paper tape, optical mark sheet, hole or any other suitable physical medium with an optically recognizable mark pattern, RAM, PROM, EPROM, flash EPROM, etc. Any suitable memory chip or cartridge, carrier wave, or any other suitable medium readable by a computer can be included.

  Although the invention has been described in connection with a number of exemplary embodiments and examples, the invention is not limited thereto, but rather various modifications and equivalents thereof that fall within the scope of the appended claims. It is included in the range.

Claims (2)

An apparatus comprising a DRM system having a first enforcement mechanism for enforcing use of content according to a first format license,
The DRM system includes a processor and a memory that is operatively connected to the processor and stores execution instructions for the processor;
By operation of the processor in accordance with an execution instruction stored in the memory,
(1) involved in a first authentication of a user for a first DRM system having a first enforcement mechanism for enforcing use of content in accordance with a license of a first format;
(2) involved in the second authentication of the user,
(3) The license information manager is communicatively connected to a second DRM system having a second implementation mechanism for implementing the use of content according to a license in a second format different from the first format; performs user authentication based on the second authentication, receiving a second format content license information is information indicating a license that allows access to content of a user from a device comprising the second DRM system Configured to
(4) receiving content license information in the first format from the license information manager;
(5) using an instance of content in a format according to the first implementation mechanism;
A device comprising a DRM system, characterized in that it is configured as follows. An interoperable license repository comprising a processor and a memory operatively connected to the processor and storing execution instructions for the processor,
By operation of the processor in accordance with an execution instruction stored in the memory,
(1) involved in a second authentication by a first client device associated with the user , wherein the first client device is involved in the first authentication of the user;
(2) receiving content license information indicating whether or not the user has permission to access the content from the second client device;
(3) If the second authentication of the user indicates that the user has been authenticated, send first license information having a first format to the first client device;
Wherein the first client device has a first enforcement mechanism for implementing the use of content;
The first license information is information based on the content license information,
If the user has permission to access content, the use of the first instance of content by the first client device is performed based on the first license information;
An interoperable license repository that is structured as follows:

Images