Patent Application
20070078777
1. Field of the Invention
The present invention generally relates to Digital Rights Management (DRM) system and methods, and more particularly, to a method and system for Digital Rights Management, for example, using advanced copy with issue rights, managed copy tokens, and the like.
2. Discussion of the Background
In recent years, systems have been developed to address various aspects of Digital Rights Management (DRM). However, many of these prior art systems lack robust mechanisms for handling digital rights management instructions, associating usage rights with digital content packages, managing of digital rights tokens, managing of digital content packages having predetermined broadcast dates, preserving of usage rights when content is transferred between DRM environments, and distributing content packages.
Therefore, there is a need for a method and system that addresses the above and other problems. The above and other problems are addressed by the exemplary embodiments of the present invention, which provide a method and system for Digital Rights Management, for example, using advanced copy with issue rights, managed copy tokens, and the like. Advantageously, the exemplary embodiments provide robust mechanisms for handling digital rights management instructions, associating usage rights with digital content packages, managing of digital rights tokens, managing of digital content packages having predetermined broadcast dates, preserving of usage rights when content is transferred between DRM environments, distributing content packages, and the like.
Accordingly, in exemplary aspects of the present invention there is provided a system, method, and computer program product for a digital content player having a DRM agent to perform rights management operations on a digital content package, including loading rights management instructions to be executed by the digital content player, the rights management instructions being associated with the digital content package, executing the rights management instructions on the digital content player, and loading supporting licenses associated with the digital content package for processing by the DRM agent. The DRM agent deciding whether to permit the rights management operations requested by the rights management instructions.
In further exemplary aspects of the present invention there is provided a system, method, and computer program product for providing usage rights for digital content, including associating with a digital content package a set of usage rights, recording the digital content package onto an original recording medium, and providing for legitimate copies to be made of the digital content package onto a user-recording medium and for the usage rights to be associate with the legitimate copies. The usage rights including first and second provisions. The first provision pertaining to rights to be provided only in the presence of the original recording medium. The second provision pertaining to rights to be provided in the absence or presence of the original recording medium.
In further exemplary aspects of the present invention there is provided a system, method, and computer program product for a digital content player adapted to play digital content packages in accordance with usage rights, including a renderer for rendering digital content packages, a token repository for storing, creating and transferring tokens based upon token management rights from a corresponding token issuer, and a DRM agent coupled to the token repository and the renderer for interpreting and enforcing usage rights associated with a digital content package and for communicating with the token repository to verify the possession of a token with a specific identifier if the usage rights require the possession of a token with the specific identifier.
In further exemplary aspects of the present invention there is provided a system, method, and computer program product for an original recording medium, including a recording of a digital content package having a pre-determined broadcast date, and a set of usage rights for the digital content package. The usage rights not allowing the digital content package to be viewed before the pre-determined broadcast date.
In further exemplary aspects of the present invention there is provided a system, method, and computer program product for preserving usage rights when content is transferred between DRM environments, including assigning a first set of usage rights to a digital content package, the first set of usage rights being adapted for enforcement in a first DRM environment, transferring the digital content package to a second DRM environment, translating the first set of usage rights into a second set of usage rights that are adapted for enforcement in the second DRM environment, associating the second set of usage rights with the digital content package, and maintaining the association of the first set of usage rights with the digital content package.
In further exemplary aspects of the present invention there is provided a system, method, and computer program product for distributing a digital content package, including associating a set of usage rights with a digital content package, and associating a set of meta-rights with the digital content package, the meta-rights defining rights to be issued to allowed modifications of the digital content package.
Still other aspects, features, and advantages of the present invention are readily apparent from the following detailed description, by illustrating a number of exemplary embodiments and implementations, including the best mode contemplated for carrying out the present invention. The present invention is also capable of other and different 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 descriptions are to be regarded as illustrative in nature, and not as restrictive.
The embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, and more particularly to
Two possible functions of the player are considered: the ability to make a copy of the content and the ability to issue rights. Some players might have either of the functions and some might have both. In one embodiment, the player can perform either or both of these functions under predetermined situations, such as immediately when a content disk is placed in the player's drive. In another embodiment, the player can have one or more buttons or other user interface elements on the player hardware, remote control, and/or attached monitor and mouse that can be utilized by the user of the player to cause the player to perform either or both of these functions. In a third embodiment, the player can have another function to present parts of the content to the user in an interactive way and the interactive components of the content can direct the player to perform either or both of the function of making a copy of the content or issuing rights. In another embodiment, the player can read instructions from the content as to when to perform either or both of the functions. In still further embodiments, the player can combine aspects of these different embodiments; for example, the player might have a hardware button to determine when to perform copies and might utilize the interactive features of the content to determine when to issue rights and what rights to issue.
As used in the context of the present patent application, the term “rights management instructions” refers to instructions for rights management operations such as issuing rights to or for the copying of digital content. Such instructions might include instructions as to when such digital content is to be copied or what portion of said digital content is to be copied or where such digital content is to be copied to. Similarly, such instruction might direct what rights are to be issued, when they are to be issued, what portion(s) of the content that they are to apply to and whom they are to be issued to. Such instructions, however, do not simply direct the playing of digital content.
As used herein, a “DRM agent” is a collection of software and/or hardware which serves to identify and enforce usage rights associated with digital content.
A digital content package, as used herein, refers to an audio event (such as a song or album), a video event (such as a home movie or an animation), an audio-visual event (such as a movie, television show, music video and the like), a digital image, digital textual information, or any other defined amount of digital information to be presented to a user including portions thereof and combinations thereof.
An example API for allowing the interactive features of the content to direct the player to issue rights is shown in 307 as “result =issue(unissuedLicense, supportingLicenses)”. The unissuedLicense parameter is an unissued License that the interactive features of the content are asking the player to issue. The unissuedLicense can be passed directly to the function or it can be passed by reference, such as by URI. The supportingLicenses parameter is all the issued Licenses that authorize the player to issue the unissuedLicense. The supportingLicenses parameter can be passed directly to the function or it can be passed by reference, such as by URI. The supporting Licenses can also be determined by the player based on other conventions. For example, the player can know how to look up supporting Licenses from elsewhere in the content or from other sources. The result return value is used to inform the interactive features of the content whether the issuance of the license was successful or not and possibly why.
When issuing rights (515), the player first checks if it is authorized to issue those rights (510). This check is performed against the supporting Licenses (503, 505, 509). In one embodiment, the supporting Licenses are found in a title usage file (TUF) (505), which is a file of usage rights that is cryptographically bound to some content and authenticated by some trusted entity to make verification (507) of those Licenses possible. In a further aspect of the embodiment, the cryptographic binding can further associate the content with a content provider identification, and the identified content provider can serve as the trusted root issuer for performing an REL authorization request for the player to issue rights. In other words, it could be further checked (507) that the supporting Licenses are authorized by the content provider identified associated with the content associated with the TUF including the supporting Licenses.
Once the player issues rights (515), in one embodiment the player can sign the License including those rights. In another embodiment, the player can store the License in a secure fashion (515) and record information about its issuance of that License, such as the authorization request (510) it made when determining if it was authorized to issue that license. By keeping this record, the player has the information in needs to know whether it is appropriate to use the r:issueContext and r:issueTime properties defined in the REL standard (ISO/IEC 21000-5:2004) for future authorization requests (502) (for example, future authorization requests to play the content or copy the content). For optimization purposes, it is possible to reduce the amount of information recorded by the player. For example, the player need not necessarily remember the time at which it issued the License if it makes no retrospective queries and handles all authorization-related flows in a time-liner fashion. In the extreme case, it is possible for the player to keep no record other than that those Licenses stored in the prescribed secure fashion (406) have all been properly issued.
Usage rights can be associated with a digital content package in various ways. For example the two can be associated by being recorded to the same recording medium. Alternatively, an identification code associated with digital content package can be used to access via a communications link the associated rights.
As used herein, a legitimate copy refers to a copy that is permitted in accordance with the governing usage rights. It is not meant to cover copies made by hacking, reverse engineering, or other unauthorized methods.
As used herein the term original recording medium is used to refer to a recording medium distributed by the content owner and its authorized representatives. This is to be contrasted with a user recording medium which refers to a copy made by an end-user. In the present invention, a user-recording medium may be a digital content player with a hard drive or other storage medium to which content can be recorded.
In accordance with the present invention two sets or provisions of rights are provided. In the first instance there is a superset of rights that is allowed in the presence of the original recording medium. For example, if the original recording medium is an HD-DVD, a copy of that HD-DVD is made onto a user's HD-DVD player, or computer, the user will be afforded greater rights while the HD-DVD is in the player or computer and lesser rights when it is not. One example of rights could be the right to make additional copies. That right might only be granted in the presence of the original HD-DVD in the player or computer. In that way a user could loan the HD-DVD to a friend who could make a recording on the friend's player or computer. Once the friend returned the HD-DVD to its owner, that friend could watch the digital content package but could not make additional copies. Another example would be a promotion that would allow copies of the original to be viewed only during a given time-based window whereas the original HD-DVD, or for that matter, a copy of the digital content package from the HD-DVD when the original HD-DVD is in the same player or computer as the copy, could be viewed in a different and most likely larger time-based window.
In another embodiment of this invention, meta-rights on the original recording medium can be used to issue further rights beyond those originally associated with the digital content package. These further usage rights would be usable with the original recording medium, user recording mediums, and any other copy of the digital content package, just as if they had been originally associated with the digital content package. Meta-rights provide the flexibility to base usage rights on events that occur after the original usage rights are associated with the digital content package. For example, meta-rights can make it possible to put usage rights into effect that are valid for a particular digital content player that has physically interacted with the original recording medium. The identity of the digital content player cannot be known ahead of time; however the meta-rights can permit the digital content player to issue usage rights to itself so as to allow it to use any copy of the digital content package even after the original recording medium has been removed.
In order to authenticate these further usage rights, it is necessary to secure them. A digital content player can have a secure storage for the purpose. In one embodiment, the secure storage can be configured such that only the digital content player operating according to authorized meta-rights can write to the storage. In another embodiment, the secure storage can be configured such that the digital content player can only read rights it has written to the storage while operating according to authorized meta-rights. In either case, after the digital content player reads usage rights from its secure storage, it can be confident that they are authentic usage rights, duly issued under meta-rights from the content owner of the digital content package or its authorized representatives.
Once all remaining licenses have been verified trusted in step 506, an attempt is made in step 510 to authorize the action requested in step 502. The authorization can result in no, yes, or conditions. If the authorization results as no, the request is denied in step 518 and the next request is processed in step 502. If the authorization results in conditions, flow proceeds to step 511, 512, and 513. If any of the conditions are not satisfied, the request is denied in step 518. If all conditions are satisfied or if the authorization originally resulted in yes, flow proceeds to step 514, where the nature of the request is determined. If the request is to play or copy, it is granted at step 517 and the next request is processed in step 502. If, on the other hand, the request is to issue rights, the license is issued in step 515, including signing the license if signing is necessary. At step 516 the license is stored in the self-issued license store 406 for later retrieval in step 503 (in case 406 represents secure storage) or step 505 (in case 406 represents insecure storage).
The process described in
By utilizing the issue rights feature of the player to cause the player to issue rights specific to the particular player or to other particular devices, it is possible to accomplish interesting models for the distribution and use of content. For example, one manner of use might be permitted for all parties (broad rights) (403, 404, 405), while another manner of use might be permitted for specific players (rights stored in 406).
By utilizing the copy feature of the player to copy content from its original location into other locations without changing the content identifier, it is possible to accomplish interesting models for the distribution and use of content. For example, one manner of use might be permitted for content available from its original location (403), while another manner of use might be permitted for the same content regardless of its location (404).
By the combined utilization of the issue rights and copy features of the player, even more interesting models for the distribution and use of content can be accomplished. For example, one manner of use might apply to all players and regardless of content location (404); another manner of use might apply to all players with the content available from its original location (403); another manner of use might apply to specific players regardless of content location (some rights in 406); and another manner of use might apply to specific players with content available from its original location (other rights in 406). The following example describes a scenario utilizing three of these manners of use.
A content provider (401) makes content (300) available on a read-only optical disk (101) (the original location). For promotion purposes, the content can be played by anyone on Dec. 1, 2005, whether or not they have the original optical disk (using rights 404). The content can also be played by anyone who has the optical disk at any time (using rights 403). A consumer borrows the disk from a friend. There is a copy creation offer (405) that allows the consumer to create a copy for free. Of course, this copy would only be playable on Dec. 1, 2005, (pursuant to 404) unless the disk is present (pursuant to 403). The content usage rules 403 also permit the issuance of new usage rules (406) in the presence of the disk to allow the same player to play the content for up to one day without the presence of the disk (so he can return the disk to his friend right away, and still play the copy for a day).
Five grants are involved in this scenario:
The first four grants are issued by the content provider and shipped on the disk (at 306) and copied along with the advanced copy. The fifth grant is issued by the player at the direction of the interactive features (303, 304) of the content calling the issue( ) API (307) and is stored (406) on the device (402).
The first grant is shown in the following License:
The second, third, and fourth grants are shown in the following License:
The fifth grant is shown in the following License:
The above described exemplary embodiments, advantageously, determine when to issue rights in a user-friendly way, accomplish a perception of different rights to copies, and establish trust for and secure licenses issued by players.
Further exemplary embodiments employ the use of Managed Copy Tokens (MCTs) to simulate virtual copies. Every MCT (603) has a token identifier (604). The token identifier (604, 805, 807) can be shared by multiple tokens (603, 804, 806), so, for example, there can be 3 MCTs with token identifier ABC. In one exemplary embodiment, the token identifier can be written in a token identifier grammar. An example token identifier grammar is that the token identifier includes the token issuer's public key (1001) followed by a token issuer-assigned token distinguisher (1002). Such a grammar would allow, for example, the easy determination of the token issuer associated with any MCT. The token issuer is the entity that is authorized to issue licenses (701) allowing for the creation and transfer of that MCT. In another example token identifier grammar, the token identifier includes a number of fields indicating different classes to which the token belongs. Such a grammar would allow, for example, the easy determination of the token classes associated with any MCT and the easy construction of rights expressions which allow the creation, transfer, or use of tokens from a certain class.
Creation and transfer of MCTs are governed by the MCT issuer. Systems require some way to determine the MCT issuer for any given MCT. One example way is by using a token identifier grammar such as defined above with a field (1001) for the token issuer. Another way is to have a MCT registry (1102) wherein the MCT issuer can be looked up by a token repository 1101 sending a request 1103 with a token identifier and receiving a response 1104 with the token issuer info. In one example, an MCT issuer might allow (for example, via usage rights 701) an MCT with identifier “ABC” to be created by Canadians for the payment of $5. If 10 Canadians each pay $5, then there will be 10 MCTs created with identifier “ABC”. If an 11th Canadian pays $10, he can create two more MCTs. Further expanding upon this example, consider that the MCT issuer authorizes (for example, via usage rights 701) the tokens to be transferred to any other Canadian or US Citizen. The 10th Canadian could then transfer his token to a US Citizen and the 11th Canadian could transfer one of his tokens, for example, to the 10th Canadian. The 11 Canadians and 1 US Citizen would then have one token each.
MCTs are typically created, transferred, and managed by some trusted software or hardware (602) such that indiscriminate creation and transfer of tokens is not possible or is distinguishable from the legitimate creation and transfer of tokens. The small size of MCTs relative to digital content makes them ideally suited for management by trusted software or hardware designed to be immune to backup-and-recovery attacks. MCTs can be represented in a number of ways such as files (802, 804, 806) in a file system (801) or entries in a database (900). In one example, a trusted database (900) includes an MCT table with two sets of columns, one for MCT identifier (901, 902 or just 901) and one for MCT count (903). Each row in the database (904, 905, 906, 907) represents the corresponding count of MCTs with the corresponding identifier. When an MCT is created, the count is increased. When an MCT is transferred, the count is decreased on the sending side and increased on the receiving side.
In order to simulate virtual copies, usage rights (702) to content (703) can be conditioned upon the possession of certain MCTs that have been legitimately created and/or transferred. For example, in the example above with 11 Canadians and 1 US Citizen, if the right (702) to view an e-book (703) was conditioned upon the possession of an MCT with token identifier “ABC”, then the transferring of MCT occurring between the US Citizen and 10th and 11th Canadians would be simulating the transferring of the associated book between them because whoever holds the MCT can view the e-book (just like whoever holds a physical copy of a book can read the book).
In addition to having usage rights to content conditioned upon the possession of certain MCTs, it is also possible to have some usage rights to content conditioned upon the possession of a first type of MCTs, other usage rights to the same content conditioned upon the possession of a second type of MCTs, still other usage rights to the same content conditioned upon the possession of some physical media, and still other usage rights to the same content unconditioned upon either the first or second type of MCTs or media. If the MCT creation rights for the first type of MCT are conditioned upon possession of the second type of MCT and if the MCT creation rights for the second type of MCT are conditioned upon possession of some physical media, then such a licensing model would simulate different rights for the original, the first generation copies, and the second generation copies. It would also allow for some limited preview of the content by people who hold neither the original nor first or second generation virtual copies.
The following licenses demonstrate an application of the MCT idea to a piece of content (703) identified by 12.345 that is available for use in repositories (601) only during the month of December, 2005. The content is available for use from physical media (700) during that time (see FIG. element 702 and license #1 below). It is also available during that time for use in the presence of MCT with identifier MCTIssuer:123CABEE (see FIG. element 702 and license #2 below). MCT with identifier MCTIssuer:123CABEE can be created by a MCT repository (602) upon communication with publisher.com to satisfy any fees and count restrictions put in place at publisher.com's website (see FIG. element 701 and license #3 below). MCT with identifier MCTIsuser:123CABEE can be freely copied to any MCT repository (602) with security level 7 or higher (see
License #1:
License #2:
License #3:
License #4:
The above description of MCTs relates to MCTs that are permanent after created. It is also possible to have MCTs that are created with a specified lifetime (1004). After their lifetime since creation lapses, MCTs are destroyed. Or, it is possible to have MCTs that carry an indication of their creation time (902, 1003), so that other licenses that require the presence of MCTs can require the presence of MCTs newer or older than a certain date, for example. Other variations are possible as might be obvious to one skilled in the art, such as territory-bound MCTs (1005) that cannot move out of the territory in which they were created. Such advanced classes of MCTs can be implemented in a number of ways. One example is to use a grammar for MCT identification that includes the class of MCT including creation territory and creation time. Another way is to store this information in a database.
The above described exemplary embodiments, advantageously, provide virtual copies, first sale, and differential rights to different-class (generation, disk/nodisk, etc.) copies.
In another embodiment of the present invention, the allowed showing of content on a physical media is coordinated with the broadcast of that same content. In other words, copies of a digital content package, such as a movie, can be distributed in protected format so that they may not be viewed before such content debuts in broadcast format.
Further exemplary embodiments are related to the business model of USPS as a Cable Channel (e.g., HBO via USPS). This exemplary embodiment solves the problem for content aggregators like HBO, and other channel operators, to package content together to distribute to the consumer. Typically, HBO makes agreements with content distributors like DirecTV and Cable operators. The HBO channel is delivered to various content distributors and transmitted into the home.
However, HBO may like to be able to provide their aggregated content via other means than cable and satellite. Another avenue would be to deliver HBO content over IP delivery. There is, however, another opportunity to deliver HBO content over a new distribution means, such as optical disk, and the liked.
An exemplary embodiment includes the combination of two new technologies to provide a unique new distribution means for HBO or others, i.e., the combination of HD optical disk storage and DRM technology. For example, if HBO where to package their content on optical disk with a specific month of lifecycle, they would mail the May discs to consumers via physical mail, in late April. The discs would arrive at the consumer's household as part of a subscription model. On the first day in May, the disks would be playable, but not before or after the month of May '05, as an example.
In addition, HBO could restrict the specific days that the content is playable to coincide with they days the HBO channel provides the same content. At a finer level of granularity, it could further be restricted to the specific times that the broadcast is made (e.g., May 16, 2005 GMT 8:00am, 12:00pm, and 3:00pm, etc.). The consumer would read the content of the disc in a coincident manner to the time of broadcast.
If this last case where implemented, it literally could be a “Broadcast” from the disk. The consumer would insert the disc and content would come off the disk coincident with the Broadcast by HBO.
Advantageously, a consumer that elects to receive content via broadcast (e.g., Terrestrial Digital HD) could still have HBO as a channel choice via this alternative mechanism.
Accordingly, in this exemplary embodiment, the combination of HD optical disk storage and DRM technology can provide a unique new distribution means for HBO or others. For example, if HBO where to package their content on optical disk with a specific event in mind that would trigger the ability to use the disk, they would mail the discs to consumers via physical mail, in late April. The discs would arrive at the consumer's household as part of a subscription model. As soon as the event happened the disks would be playable but not before the event. As an example, the event could be that HBO decides to broadcast the content on the disk on a certain date. The making available of the content on that date could be accomplished by providing on the disk an HBO URL that can be contacted to supply code to unlock the disk once the event is known.
In addition, HBO could restrict the specific days that the content is playable to coincide with the days the HBO channel provides the same content and of course those days might not be known when the disk is distributed so the relevant event would be determination of the dates. At a finer level of granularity, it could further be restricted to the specific times that the broadcast is made (e.g., May 16, 2005 GMT 8:00am, 12:00pm, and 3:00pm, etc.) The consumer would read the content of the disc in a coincident manner to the time of broadcast.
If this last case where implemented, it literally could be a “Broadcast” from the disk. The consumer would insert the disc and content would come off the disk coincident with the Broadcast by HBO and that broadcast time need not be known when the disks are distributed via USPS.
Advantageously, a consumer that elects to receive content via broadcast (e.g., Terrestrial Digital HD) could still have HBO as a channel choice via this alternative mechanism.
The physical media is then distributed via distribution system 1510 and copies such as 1512 and 1514 of the content on physical media can then be played on devices 1511 and 1513 respectively subject to the schedule 1509.
It should be readily apparent that schedules 1505 and 1509 need not be identical or even of the same form. For example schedule 1505 may include a date and time of broadcast or of multiple dates and times. It might also include information regarding the distribution such as network (e.g., HBO, ESPN), channel number and distribution system (e.g., cable, satellite, over the air, etc.). Schedule 1509, in contrast may not have set viewing times but rather windows. Such windows could be open ended such as allowing the content to be viewed at any time after a certain date and time. Alternatively, such windows could be closed thereby only allowing viewing during a set period of time. Multiple windows and other structures are also possible. In addition, windows can be combined with other usage rights such as, for example, limits on the number of times content can be viewed. Alternatively, there might be separate windows for viewing and copying which could be either distinct or overlapping to some degree or another. Other arrangements will be readily apparent to those skilled in the art. Nevertheless, it should be understood that one embodiment of this invention is to have a schedule 1509 for the physical media that allows the physical media to be distributed to end-users so that end-users of physical devices such as 1511 and 1512 get access to the content at the same time as end-users of devices such as 1506 which receive content broadcast according to schedule 1505.
In a further embodiment of the present invention, usage rights that are associated with a first DRM environment are sent both translated and untranslated when content is transferred from the first DRM environment to a second DRM environment. In doing so, the original usage rights are preserved to be used if the content returns to the first DRM environment or if the usage rights need to be translated for a third DRM environment.
Further exemplary embodiments include transporting rich REL with DRM specific REL. This exemplary embodiment solves the problem that when a fixed MPEG REL license is used by several different DRM systems, each DRM system has its own rights expression support capabilities. For example, a DRM system may have its own rights expression, or only have the ability to support some subset of rights in MPEG REL.
In a traditional model, the REL would be delivered from A to B to C with the content. Transformations of the REL would occur at each step. Because each of the transformations is Lossy, A-C would give different rights to C than A-B-C, because of the path and transformations that occur. This exemplary embodiment resolves this problem by permitting transformations of the REL to the specific DRM systems, but preserving the original source REL. In this mode, A would create a transform of REL A(REL), but maintain REL. When the content is delivered to B, the rights REL and A(REL) are transmitted. B could either then operate on REL or A(REL), if B was capable. In addition, B could perform its own transform. B would then be able to use REL, A(REL) or B(REL).
If the content where then delivered to C, the rights REL, A(REL) and B(REL) would also be delivered. To be clear, A(REL) is REL cast in a way that A can understand REL. It is not rights assigned to A. C could then operate against any of the rights described, REL, A(REL) or B(REL). In addition, if none of those where operable by C, it could create C(REL), and the like.
The transmission of A(REL) to B can be optional. For example, if requested, A could transmit the content and REL instead of content with REL and A(REL). Advantageously, each subsequent system has the ability to see the original REL and operate against is or against a transformation that has occurred previously.
It is assumed that each of these transforms is Lossy, but compliant. For example, if A performs a transform, then A(REL) describes a subset of usage permitted by REL. If A(REL) describes usages beyond REL, then that can only occur under the guidance or approval of some compliance body that specifically permits the extension of rights.
In
One embodiment of the present invention which addresses the problems with the prior art discussed in connection with
In
In
Another aspect of the present invention is shown in
Further exemplary embodiments provide methods and systems for specifying rights for resources resulting from exercising of other rights. In an exemplary embodiment, exercising a right on a resource in many cases results in generating new or derived resources. For example, editing a document often creates a new document, extracting a portion out of a document and then inserting it into another document also end up with a new document, and adapting a video to a different bit rate yields a derived version of the video content. When granting rights of this type, one may also be interested in specifying rights for the resources to be generated as the result of exercising the granted rights. For example, one may want to specify that a distributor has the right to sell the play right for a video, and also has the right adapt it to some lower bit rates to sell the same play right but for less money.
Considering exercising a right as a process that can take some (zero or more) resources as input and produce some (zero or more) other resources as output, the idea of this exemplary embodiment is to devise methods and systems for:
Specifically, this exemplary embodiment includes:
Advantageously, the exemplary embodiment solves the problem of specifying rights for resources to be generated as the result of exercising other rights. It is currently cumbersome to deal with this problem. For example, DPRL uses the mechanism of “nextRight” to allow inheriting the existing rights from the input resource, and adding rights to or subtracting rights from the existing rights. This mechanism is not flexible, however, in that (a) it is hard to apply it to the cases where two or more resources are generated and they have different sets of rights, (b) it does not support specifying a different set of rights as the combination of adding and subtracting rights, and (c) it does not support indication of who has the right to issue those rights.
Issuing rights for newly generated resources can be dependent upon exercising the right for generating the resources. The dynamic (and hence variable) information, such as identification and other metadata that is not known in advance and only becomes available during the exercise of the right has to be captured and used in the right to issue rights. Currently in REL, variables are only specified for and used within exercising a right (e.g., inside a grant). A novel aspect of this exemplary embodiment is to allow capture and usage of the dynamic information across different but related rights (such as adapt and issue).
Accordingly,
Advantageously, the exemplary embodiments can be used to augment, for example, the Advanced Access Content System (AACS), by providing capabilities that enhance those offered by AACS. The exemplary embodiments achieve this by offering sophisticated usage rules that are specified as rights expressions using an international standard rights expression language, for example, the MPEG REL. The exemplary usage rules can include many parameters, such as fees, geographical restrictions, target DRM systems, dates, resolutions, tracking, and the like. The exemplary embodiments also offer an Advanced Copy right that allows users to create and use a copy governed by usage rules that are flexible and can vary on a title-by-title basis.
The exemplary usage rules can be optional AACS usage rules. AACS players not interpreting the exemplary usage rules function like ordinary AACS players. On the other hand, if AACS players interpret and enforce the exemplary usage rules, new uses of the content can be offered to consumers. In this way, the exemplary embodiments provide an extensible, flexible platform to facilitate a wide variety of business models for AACS protected content.
The exemplary embodiments need not support recordable media. In addition, the exemplary embodiments need not support acquisition of usage rules via mechanisms other than those supported by AACS. While support for these features is a natural use of the MPEG REL and expands the options available to the AACS systems, support for these features requires additional architectural consideration.
The exemplary embodiments can include:
An Interface Book, which specifies an extension and profile for AACS HD DVD specific rights expressions and the mechanisms for integrating the expressions with the AACS HD DVD pre-recorded media and players.
A Rights Expression Book, which specifies the common MPEG REL extensions and profiles for AACS as well as for other DRM systems in the media and entertainment market.
A Protocol Book, which specifies the common rights protocols such as rights authorization and rights issuance protocols for AACS as well as for other DRM systems in the media and entertainment market.
Technical Compliance Rules, which specify the technical compliance and robustness rules required for compliant implementations.
Exemplary Business Models, which capture the target business models that are currently supported by the exemplary embodiments.
Architecture Scope and Assumptions, which capture the architecture scope intended to be supported for the exemplary embodiments and some assumptions and issues upon which the scope relies.
The following section covers general information including scope; normative references; terms, definitions, symbols, and abbreviated terms; and namespaces and conventions.
The normative references can include:
ISO/IEC 21000-5:2004, Information technology—Multimedia framework (MPEG-21)—Rights Expression Language
XMLSCHEMA, XML Schema Part 1: Structures and Part 2: Datatypes, W3C Recommendation, 2 May 2001, available at <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502> and <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502>
AACSHD DVD and DVD Pre-recorded Book, AACS LA, Version 0.9, Release Candidate 3, 11 Aug. 2005.
The terms, definitions, symbols, and abbreviated terms can be given in Clause 3 of ISO/IEC 21000-5:2004.
The namespaces and conventions can be given in Clause 4 of ISO/IEC 21000-5:2004, except for the namespace prefixes given in Table 1 below.
The following section specifies the interface-specific extensions to the MPEG REL. The goal of the interface-specific extensions is to provide a way to express rights and conditions relying on functionality that is only provided by AACS. These rights and conditions can be used to provide additional offerings to the consumer beyond the offerings enabled by the common Rights Expression Book. These additional offerings are not expected to be common with future exemplary interfaces. The potential for cross-interface adoption of the features in this interface book (for example, managed copy) will be evaluated in the coming months, and future versions of the exemplary embodiments might elevate the support for such features to the common exemplary books.
The following section specifies the syntax and semantics of the AACS HD DVD Pre-recorded Extension to the REL. Subsequent sections present a brief informative description of the features offered by this extension, followed by the full normative description.
The AACS HD DVD Pre-recorded Extension defines the following new conditions:
DiskInDrive: requires the presence of an HD DVD to exercise a right
UrPtr: limits the exercise of a right to particular group of enhanced video object sets (EVOBs) within a play list
The extension also defines authorization context properties that support the new conditions:
evobsUrPtr( ): a usage rule pointer shared by all EVOBs
pmsn(a): an HD DVD's pre-recorded media serial number
volumeld(a): an HD DVD's volume ID
The extension also defines:
a QName for expressing the right to make a managed copy (for more information on managed copies, please see the AACS documentation)
a URI for indicating the AACS content provider identification system
a URI for indicating the AACS device identification system
a URI template for identifying a play list on an AACS disk using a URI
Further sections describe the two new conditions and provide examples of their use. For brevity, the details of the r:issuer element have been omitted from the examples.
The aacs:diskInDrive condition requires the presence of an HD DVD to exercise the granted right. The required HD DVD is identified by its volume ID, its serial number, or both.
The volume ID is the same for all HD DVDs that include the same content, whereas the serial number is unique to each HD DVD. If this condition includes the volume ID, any disk of a particular title satisfies the condition. If this condition includes the serial number, only one disk satisfies the condition. If this condition includes both the volume ID and the serial number, satisfying the condition requires that both pieces of information from the disk match those specified in the condition.
Using this condition ties the licensed digital content to a particular physical medium. For example, suppose the Big Movie Studio (Provider ID B188) is distributing an HD DVD (Content ID 12345678) including its award-nominated movie (video play list 001) to individuals who will choose the award winner. The Big Movie Studio wants to ensure that copies of its movie do not appear on the internet. The license for the award-nominated movie could use the diskInDrive condition to require the presence of the original HD DVD in order to play the movie, as in the example below:
The aacs:urPtr condition limits the exercise of the granted right to those enhanced video object sets (EVOBs) on the disk that have a particular usage rule pointer.
An enhanced video object set (EVOB) is simply a program stream of audiovisual or audio data. An EVOB can be associated with a usage rule pointer, which points to a usage rule set stored in the title usage file. Several EVOBs can have the same usage rule pointer, so that a single usage rule set applies to several EVOBs.
Using this condition effectively creates a subset of a play list on an HD DVD by selecting the EVOBs to which a particular usage rule set is applied. For example, suppose the Big Movie Studio wants to license two versions of a movie, a G-rated version and a PG-rated version, but manufacture a single HD DVD. They could apply usage rule set 1 to the EVOBs that comprise the G-rated version of the movie and usage rule set 2 to all the other EVOBs. Each usage rule set could point to the same license with two grants, one which includes the urPtr condition to allow playing only those EVOBs whose usage rule pointer is 1 and one which doesn't include the urPtr condition and allows playing all the EVOBs regardless of pointer value. The second grant could require online permission to check for parental approval, for example.
Table 2 specifies the authorization context properties previously described and the statements they represent. If a property has the name given in the first column of Table and the value given in the second column of Table 2, then the statement represented by that property is the statement given in the third column of Table 2.
The following sections specify the semantics of a Rights Expression extension including elements and types that are specific to AACS HD DVD Pre-recorded media.
Let c be an aacs:DiskInDrive. Let (p, r, t, v, Σ, L, R) be an authorization request. Let (g, h, e) be an authorization story. Then c is Satisfied with respect to (p, r, t, v, Σ, L, R) and (g, h, e) if and only if both of the following are true:
Let c be an aacs:UrPtr. Let (p, r, t, v, Σ, L, R) be an authorization request. Let (g, h, e) be an authorization story. Then c is Satisfied with respect to (p, r, t, v, Σ, L, R) and (g, h, e) if and only if the value of c/aacs:ptrValue is Equal to Σ.aacs:evobsUrPtr( ).
The QName aacs:managedcopy is for use with the governanceRule attribute of bpx:governedcopy and indicates the governance rules for managed copy as defined in the AACS Compliance Rules.
The URI http://www.tbd.org/2005/Provider/AACS/HDDVD is for use with the idsystem attribute of bpx:identityHolder and bpx:identityHolderPattern and indicates the identification system for content providers consisting of a 16-bit ID assigned by the AACS LA as described in 2.4 of AACS Pre-recorded Video Book. The 16-bit ID shall be base16-encoded for carriage in XML.
The URI http://www.tbd.org/2005/Device/AACS/HDDVD is for use with the idSystem attribute of bpx:identityHolder and bpx:identityHolderPattem and indicates the identification system for devices consisting of a 128-bit device unique nonce (see 5.1.1 of AACS HD DVD and DVD Pre-recorded Book) generated and maintained in compliance with all AACS compliance and robustness rules related to device unique nonces. The 128-bit ID shall be base64-encoded for carriage in XML.
The URI templates:
The following sections include a listing of the schema (XMLSCHEMA) that defines the XML syntax of the defined types and elements.
Schema for the interface-specific extension:
The following section specifies the interface-specific profiles. The goal of the interface-specific profiles is to drive convergence among implementations on common levels (basic and enhanced) of support, so that rights expression authors can write licenses that can be processed by the widest possible set of AACS HD DVD Pre-recorded disk players for the desired feature set.
This section specifies the Rights Expression profiles for AACS HD DVD Pre-recorded media. Two profiles are defined: basic and enhanced. The basic profile is intended to allow for expressing rights that are similar to the capability of a basic AACS player (modulo, perhaps, the ability to process usage rules). The enhanced profile is intended to allow for expressing rights that are similar in functionality to the functionality offered by an enhanced AACS player.
The Basic AACS HD DVD Pre-recorded Profile includes the AACS HD DVD Pre-recorded Extension previously described (except for managed copy) plus the following elements from the exemplary Rights Expression Profile defined in the exemplary Rights Expression Book: r:license, r:grant, r:digitalResource, r:nonSecureIndirect, r:issuer, r:allConditions, mx:play, and bpx:identityHolder.
The QName for indicating the Basic AACS HD DVD Pre-recorded Profile is aacs:basic.
All basic AACS players that process exemplary usage rules shall be able to process the Basic AACS HD DVD Pre-recorded Profile. Additionally, all such players shall be able to process Licenses including multiple r:grant elements by ignoring the r:grant elements that include any r:forAll, r:Principal, r:Right, or r:Condition the player does not recognize and by processing the remaining r:grant elements. Such players need not be able to process Licenses utilizing other extension points provided for in ISO/IEC 21000-5:2004.
The Enhanced AACS HD DVD Pre-recorded Profile includes the AACS HD DVD Pre-recorded Extension previously described plus the exemplary Rights Expression Profile defined in the exemplary Rights Expression Book. In addition to taking a value equal to one of the URIs previously described, the URI attribute of r:nonSecureIndirect may take a value equal to any of the URIs provided in the ID attributes of ResourceGroup elements in the “MNGCOPY_MANIFEST.XML” file in the “AACS” directory as specified in section 5.2 of AACS HD DVD and DVD Pre-recorded Book.
The QName for indicating the Enhanced AACS HD DVD Pre-recorded Profile is aacs:enhanced.
All enhanced AACS players that process exemplary usage rules shall be able to process the Enhanced AACS HD DVD Pre-recorded Profile. Additionally, all such players shall be able to process Licenses including multiple r:grant elements by ignoring the r:grant elements that include any r:Principal, r:Right, or r:Condition the player does not recognize and by processing the remaining r:grant elements. Such players need not be able to process Licenses utilizing other extension points provided for in ISO/IEC 21000-5:2004.
The following section specifies the carriage of the exemplary rights expressions on AACS HD DVD Pre-recorded disks.
Licenses are carried on HD DVD Pre-recorded media in one of two ways depending on the purpose of the licenses. Licenses for playing (including for issuing licenses for playing) and licenses for making copies are carried as further described.
Licenses for playing are carried using the REL Usage Rule defined in 3.4 of AACS HD DVD and DVD Pre-recorded Book. The REL Usage Rule shall carry or reference to an XML License that is well-formed, schema-valid, and in Schema Centric Canonical Form (see Schema Centric XML Canonicalization). If the REL Usage Rule carries or references to an XML License that is either not well-formed, not schema-valid, or not in Schema Centric Canonical Form, the behavior of the player cannot be guaranteed and is player-specific. If the player detects that the file is not well-formed, not schema-valid, or not in Schema Centric Canonical Form, the player shall report an error.
There may be a file, named “MNGCOPY_LICENSES.XML”, in the “AACS” directory. Licenses for making copies are carried in this file as children of its root element, which shall be r:licenseGroup. The r:licenseGroup shall be well-formed, schema-valid, and in Schema Centric Canonical Form (see Schema Centric XML Canonicalization). If it is either not well-formed, not schema-valid, or not in Schema Centric Canonical Form, the behavior of the player cannot be guaranteed and is player-specific. If the player detects that the file is not well-formed, not schema-valid, or not in Schema Centric Canonical Form, the player shall report an error.
The following section specifies the processing of the exemplary rights expressions by AACS HD DVD Pre-recorded players, including the processing relation to the AACS functions of playback, managed copying, and hash checking.
A REL Usage Rule including a License and a “MNGCOPY_LICENSES.XML” file in the “AACS” directory can be processed as further described.
In the tables below, the Ordinal column refers to the ordered seven-tuple of members for an authorization request as identified in 5.2 of ISO/IEC 21000-5:2004.
Any EVOBs in a play list may be played back if there is an authorization proof for the authorization request constructed according to Table 3 for playing back those EVOBs.
If none of the conditions applicable to this authorization request depend on the end of the playback interval, the player shall perform the verification of the proof for this authorization request prior to beginning playback. If any of the conditions applicable to this authorization request depend on the end of the playback interval, the player shall perform the verification of the proof for this authorization request on an incremental periodic basis in such a way that playback is authorized at the time the playback started and that once a playback ceases to be authorized it does not continue for more than 60 seconds beyond the time when it ceases to be authorized.
Sections 4.3.3 and 4.4.3 of AACS HD DVD and DVD Pre-recorded Book specify a content hash check procedure and associated timing constraints. For playback, no change is made to this procedure. The procedure is performed as normal within the associated timing constraints to verify that the content being played back corresponds to the play list and provider identified in the Resource and Trust Root Members, respectively, of the authorization request shown in Table 3.
A resource group defined in a “MNGCOPY_MANIFEST.XML” file in the “AACS” directory may be managed/advanced/clear copied if there is an authorization proof for the authorization request constructed according to Table 4 for that managed/advanced/clear copy operation.
The player shall perform the verification of the proof for this authorization request prior to making the managed/advanced/clear copy.
Sections 4.3.3 and 4.4.3 of AACS HD DVD and DVD Pre-recorded Book specify a content hash check procedure and associated timing constraints. The timing constraints are not pertinent to making managed/advanced/clear copies. The procedure shall be performed before the managed/advanced/clear copy is made to verify that the content being managed/advanced/clear copied corresponds to the resource group and provider identified in the Resource and Trust Root Members, respectively, of the authorization request shown in Table 4.
A player may include an r:grant in a License it issues if there is an authorization proof for the authorization request constructed according to Table 5 for the inclusion of that r:grant in that License.
The player shall perform the verification of the proof for this authorization request prior to including the r:grant in the License.
The following section describes the interface-specific compliance rules on the authorization context described in exemplary Compliance Rules. The authorization context is a vehicle for forming the link between the rights expression semantics relying on truths and the compliance rules for how the truth is determined. For functionality that relates to the material in this interface book, it is appropriate for the exemplary Compliance Rules to refer to specifications provided by AACS. The goal of this section is to highlight all such reference points so that the exemplary Compliance Rules can simply refer to this section.
The exemplary embodiments assume that the exemplary Compliance Rules include rules about usage of authorization context properties in authorization requests:
Some authorization context properties will have no constraints placed on their use by the exemplary Compliance Rules,
Some authorization context properties will have everything about their use locked down in the exemplary Compliance Rules itself, and
Some authorization context properties shall not be used unless explicitly permitted in the exemplary Interface book.
This section specifies the authorization context property uses permitted by the exemplary interface book.
A player may use an aacs:evobsUrPtr context property in an authorization context in an authorization request if the statement made by that context property is true.
A player may use aacs:pmsn and/or aacs:volumeld context properties in an authorization context in an authorization request if the statements made by those context properties are determined to be true by reading the respective values from the disk in accordance with all AACS compliance and robustness rules about reading and verification of PMSN and Volume Id values.
A player may use a context property named r:issueContext(l, p, h, σ) with value true in an authorization context in an authorization request if all of the following are true:
A player may also use a context property named r:issueContext(l, p, h, σ) with value true in an authorization context in an authorization request if all of the following are true:
A player may use a context property named r:issueTime(l, p) with value i in an authorization context in an authorization request if all of the following are true:
No constraint is placed on i; its determination is left up to the player.
A player may also use a context property named r:issueTime(l, p) with value i in an authorization context in an authorization request if all of the following are true:
No constraint is placed on i; its determination is left up to the player.
The following two functions are added to the AACS object:
The following section shows some examples of rights expressions using the exemplary interface-specific extension and the exemplary interface-specific profiles previously defined.
This section demonstrates how to express two of the business models from the exemplary Business Models sections. For these examples, it is assumed that the governance rules for advanced copy permit the copying of exactly the files defined in the resource group being copied (including or excluding the TUF, depending on whether it is listed in the resource group) and that the rights processing for playing, copying, and issuing works in much the same way as it does from disk (though any disk in drive constraints still require the disk to be in the drive, for example). Contrast this to the governance rules for managed copy that still permit the copying of exactly the files defined in the resource group being copied but the use of those copied files is dependant on the associated managed copy technologies.
A consumer acquires an AACS disc with an offer on the disc which allows the consumer to insert the disk into his mobile video player and create an advanced copy of the content on to his mobile video player. For a specified fee, the user is able to play video play list 999 from the advanced copy without the presence of the disk on his mobile video player.
Three grants are involved in this scenario:
The first grant is issued by the content provider and shipped on the disk in the “MNGCOPY_LICENSES.XML” file. The second grant is issued by the content provider, shipped on the disk in the TUF, and copied along with the advanced copy. The third grant is issued by the mobile video player at the direction of the application calling the issue( ) API and is stored on the mobile video player.
The first grant is shown in the following License:
The second grant is shown in the following License:
The third grant is shown in the following License:
A consumer borrows an AACS disc from a friend. There is an advanced copy creation offer that allows the consumer to create an advanced copy for free. The on-disk usage rules only allow video play list 999 to be played in the presence of the disk, but there is also the ability to make new usage rules in the presence of the disk to allow the same player to play video play list 999 for up to one day without the presence of the disk (so he can return the disk to his friend right away, and still play the copy for a day).
Four grants are involved in this scenario:
The first grant is issued by the content provider and shipped on the disk in the “MNGCOPY_LICENSES.XML” file. The second and third grants are issued by the content provider, shipped on the disk in the TUF, and copied along with the advanced copy. The fourth grant is issued by the device at the direction of the application calling the issue( ) API and is stored on the device.
The first grant is shown in the following License:
The second and third grants are shown in the following License:
The fourth grant is shown in the following License:
The following sections specify the exemplary Rights Expression Profile which is a profile common to various applications for expressing rights upon audiovisual content. The exemplary Rights Expression Profile includes a subset of the MPEG REL base profile in PDAM/1 ISO/IEC 21000-5 MPEG-21 REL Profiles, Aug. 19, 2005, and it defines elements for codifying features that are common to all applications that interface with the exemplary embodiments.
The following sections present namespace prefixes and cites normative references used throughout this book. Further sections lists all the elements included in the exemplary Rights Expression Profile, provide the definitions of the extension elements, show a number of example usage scenarios and REL expressions to codify them, and list the extension schema.
For convenience, this profile uses shorthand namespace prefixes when referring to XML elements and types. The actual prefix used is not important as long as the namespace URI is correct. The prefixes used in this profile are given in the following table.
The normative References include:
The following table lists all the elements included in the exemplary Rights Expression Profile. Elements with the r, sx and mx namespace prefixes come from MPEG REL, and those with the bpx namespace prefix are extension elements which are defined in the next section.
This section defines an MPEG REL extension which represents the additional common features supported by the exemplary embodiments. The exemplary Rights Expression Profile draws from this extension. The syntax and the semantics of the extension elements are presented here. The XML schema for the extension elements and types are further listed.
The identityHolder element is an extension of the r:Principal defined in the REL Core. It identifies the principal who is the holder of the specified identity, which can be an unrestricted mixture of character content and element content from any namespace. The optional idSystem attribute can be used to indicate the identification system.
The following example specifies a principal as the holder of an International Mobile Subscriber Identifier.
In the above example, the bpx:identityHolder is granted the right to play the resource specified in r:digitalResource.
Let p be an r:IdentityHolder. Then p identifies that system entity that possesses the identifier indicated by the value p, and the identifier belongs to the identification system indicated by p/@r:idSystem when the attribute is present.
The GovernedCopy element represents the right to copy the resource and at the same time to result in certain rights being associated to the copied resource. The optional attribute @governanceRule of type QName indicates the name of a governance rule that determines how exactly the copy should be made and what rights should be associated and by whom for the copied resource. When the attribute is not specified, this right allows to make a bit-wise identical copy of the resource and to result in an identical copy of the r:license that this right is specified being made to the copied resource.
Two distinguished governance rules are defined as “bpx:advancedCopy” and “bpx:clearCopy,” as further defined.
A sample code fragment is provided below for illustration:
In the above example, any principal is granted the right to play a movie clip, and the right to copy the clip together with the same license.
Following is another example license:
Suppose the governance rule named “acme:CopyOnce” only allows exercising this right once to make a bit-wise identical copy of the resource and associating the other rights in the same license to the copied resource by issuing another license by the same issuer. In this case, exercising the right bpx:governedcopy in the license will result in a bit-wise identical copy of the resource, and the following license:
Let r be a bpx:GovernedCopy. Then, if r/@bpx:govemanceRule is present, r identifies the act of making a copy and associating right expressions with that copy in compliance with the compliance rules identified byr/@bpx:govemanceRule. Otherwise, if r/@bpx:govemanceRule is absent, r identifies the act of making a bit-wise identical copy and associating a right expression to that copy that is Equal to the License in the authorizer in one of the authorization proofs for the authorization request for that copy.
If r is used as the Right Member of an authorization request, then the Resource Member of that authorization request shall be present and shall identify the resource being copied.
The SeekPermission condition and ServiceLocation elements require that permission from a server be sought before the associated right may be exercised, and restricts a time period during which an obtained permission can be cached for future use without contacting the server.
The r:serviceReference element, when used in the bpx:seekPermission element, describes a reference to a server from which the permission for exercising the associated right must be sought. The bpx:serviceLocation specifies a server by its location bpx:url indicating where the server is located.
The optional bpx:cacheable element is used to indicate that the permission obtained from the server may be cached. Its child element bpx:period indicates the amount of time that the permission may stay in the cache until it must be deleted.
The condition specified by the element is satisfied only when any of the following is true:
In the following example, the right to play a video object can be exercised only if permission is obtained from the server at “http://www.pi.org/paymentService.”
Let c be a bpx:SeekPermission. Let (p, r, t, v, Σ, L, R) be an authorization request. Let (g, h, e) be an authorization story. Let m be c/r:serviceReference. Then c is Satisfied with respect to (p, r, t, v, Σ, L, R) and (g, h, e) if and only if either m is undefined or, letting Σ be the ordered tuple containing the values of the reference-specific parameters determined by m, at least one of the following is true: Σ.bpx:sP(m/r:serviceDescription, p) is true or all of the following are true for a equal to some subset of Σ:
Let d be a bpx:ServiceLocation. Then the description of the service described by d is given in the “General Payment and Permission Protocol” section of the exemplary Protocols Book. The endpoint of the service is given by the value of d/bpx:url.
The StartCondition condition element requires the included condition be checked at the start of an exercise of the associated right.
The condition is satisfied only if the included condition is satisfied at the starting time of exercising the associated right.
Using this condition to wrap another condition (such as a time condition) makes it possible to satisfy this condition without necessarily knowing how long the requested exercise will last in order to test the wrapped condition and without having to continually check the wrapped condition (which otherwise may be required) as the requested exercise continues to take place.
For example, the following expression specifies that the resource can be played as long as the playing starts within the year of 2005.
Let c be a bpx:StartCondition. Let (p, r, t, v, Σ, L, R) be an authorization request. Let (g, h, e) be an authorization story. Then c is Satisfied with respect to (P, r, t, v, Σ, L, R) and (g, h, e) if and only if c/r:condition is Satisfied with respect to (p, r, t, i, Σ, L, R) and (g, h, e) where i is the interval of zero length starting at the start of time interval v.
The OutputRegulation condition element requires output signal to be regulated using any of the regulations specified by the list of bpx:regulation elements.
The optional attribute @typeOfSignal indicates which type, bpx:digital or bpx:analog, of signal the regulation applies. When this attribute is not present, the regulation applies to any type. The optional attribute @qualityOfSignal indicates which quality, bpx:HD (for high-definition) or bpx:SD (for standard definition), of the signal the regulation applies. When this attribute is not present, the regulation applies to any quality of the signal.
This condition is satisfied only if at least one of the regulations specified by the list of bpx:regulations is used to regulate the output signal with a matched type and matched quality. Here, the type of the signal matches with the type of the regulation if the associated bpx:regulations has either no type specified or an identical type, and the quality of the signal matches with the quality of the regulation if the associated bpx:regulation has either no quality specified or an identical quality.
The following example shows that a movie trailer is allowed to play when the output signal is regulated by either allowing High Definition Analog Output in the form of Constrained Image (ICT: 1) or having Analogy Protection according to Type 1 of APS (APSTB:01).
Let c be a bpx:OutputRegulation. Let (p, r, t, v, Σ, L, R) be an authorization request. Let (g, h, e) be an authorization story. Then c is Satisfied with respect to (P, r, t, v, Σ, L, R) and (g, h, e) if and only if, for every integer i from 1 to Σ.bpx:oRNum( ), there exists a c/bpx:regulation child y of c such that all of the following are true:
The identityHolderPattern element restricts an identity holder to a particular identification system. It defines a pattern that matches a bpx:identityHolder element with a specific bpx:idSystem attribute. It is an extension of the r: PrincipalPatternAbstract defined in the REL Core.
An r:forAll element with an embedded bpx:identityHolder element represents the declaration of a variable whose eligible binding is a set of bpx:identityHolders with a bpx:idsystem attribute matching the bpx:idSystem attribute specified in the pattern.
The following example declares and uses a variable called “authorizedDevice”. Effectively, any holder of an identity issued by the identification system called “urn:mpeg:mpeg21:2005:01-REL-bpx-NS:imsi” may play the specified content.
Let a be a bpx:IdentityHolderPattern. Let x be an XML document. Let m be the root element contained in x. Let q be an authorization request. Let e be an authorizer. Then x Matches a with respect to q and e if and only if both m is a bpx:IdentityHolder and the value of m/@bpx:idSystem is equal to the value of a/@bpx:idSystem.
Table 6 specifies the authorization context properties relating to the base profile extension and the statements they represent. If a property has the name given in the first column of Table 6 and the value given in the second column of Table 6, then the statement represented by that property is the statement given in the third column of Table 6.
Qualified Names, include profileCompliance QName, which is the qualified name bpx:malibu-common used as the value of @sx:profileCompliance in a license to indicate compliance to this profile; GovernanceRule QNames, include AdvancedCopy, which is the qualified name bpx:AdvancedCopy that identifies the compliance rules specified in the “Advanced Copy” section of the exemplary Compliance Rules, and ClearCopy, which is the qualified name bpx:ClearCopy that identifies the compliance rules specified in the “Clear Copy” section of the exemplary Compliance Rules; Type-of-Signal QNames, include Analog, which is the qualified name bpx:analog that identifies the analog type of signal, and Digital, which is the qualified name bpx:digital that identifies the digital type of signal; Quality-of-Signal QNames, include SD, which is the qualified name bpx:SD that identifies the standard definition quality of signal, and HD, which is the qualified name bpx:HD that identifies the high definition quality of signal; Regulation-of-Signal QNames, include ICT:l, which is the qualified ICT:1name, and APSTB:01, which is the qualified APSTB:01 name
The following section includes exemplary use case scenarios from the exemplary Business Models, and demonstrates the application of the profile defined in the previous sections.
For a fee, the consumer may watch the directors cut version of the film, instead of the theatrical release version (which would be “basic” title).
HBO offers an AACS disk subscription model to customers that choose to receive terrestrial HD television. These customers may not have HBO available to them via cable/satellite. In this case HBO would mail 2 AACS SD disks per month to the customer (30 hours of content per Disk). These disks would have the appropriate months HBO content, but the disks would only be available for the specified month.
The license on the mailed disks will be like the following:
Consumer acquires a travel book about a particular country. Contained in the book is an AACS disk. The basic title of the disk describes the country, but there is enhanced content that can only be played while in the country.
When content is stored on a server, there is no usage rule on the disk for the content. The download content comes with its usage rules, which means that the rules are not on the disk.
On the other hand, when content is stored on the disk, the usage rule looks like the following:
When first released, an AACS disk might be a pay per view disk. After a certain time window, the consumer may be permitted to “convert” the disk to a traditional “play from disk” disk.
Consumer buys a new high resolution display. They then go to a rental shop to rent their favourite movie. They are prevented from viewing the high resolution version for two months because the rental version has limited rights until the end of the year.
A consumer acquires an AACS disk that allows the 30 second sound clips to be extracted. The consumer then uses their AACS compliant device to extract certain audio segments from the movie into a clear MP3 format. The consumer then uses one of these segments as a ring tone.
Users who register their movie with WB.com can extract files from the disk like movies, wallpaper, ring tones, etc.
Fixed time, date, either or both:
Relative to online authorization time:
Relative to AC generation time:
Output Regulated examples, include examples such as must be digital output (no analog), must be protected if HD, and the like, and which is covered by the bpx:outputRegulation condition element. Geographic examples, include examples covered by the r:territory condition element. Payment examples, include examples covered implicitly by the bpx:seekPermission condition element.
Exemplary Schema of the MPEG REL Extension:
Exemplary Profile Schema of the MPEG REL Core:
Exemplary Profile Schema of the MPEG REL Standard Extension:
Exemplary Profile Schema of the MPEG REL Multimedia Extension:
The following sections capture the target business models that can be supported by the exemplary embodiments. An objective of the exemplary embodiments is to deliver a set of specifications and REL licenses, for example, for the mastering of HD DVD disks by Warner Brothers, and the like.
This section together with the exemplary Architecture Scope and Assumptions section define the exemplary scope of the exemplary embodiments. Further sections enumerate business models and provide examples, and enumerate supported conditions that can be used as part of some of the business models or to enhance them.
Business models are grouped into four basic categories, based on the location of the content:
If content remains on the disk, and the local system is used to govern the usage of the content from the disk, it is considered “Enhanced Mode Content (Content Used While on Disk)”
If the content is delivered from a server and used in support of the disk, it is considered “Enhanced Mode Content (Content Downloaded and Used with Disk)”
If the local system is used to authorize the ability to copy content from the disk, and govern the use of the copied content, it is considered “Advanced Copy Content (Content Copied from Disk)”
If the content is protected on the disk but under certain conditions the content is released from the disk without further mandated usage restrictions, it is considered “Advanced Copy Content (Content Copied from Disk into the Clear)”
In Enhanced Mode Content (Content Used While on Disk) set of models, a player system is used to govern the use of content while it is still on the disk. Because AACS mandates Basic Mode Content be playable by all AACS compliant devices without condition, this section targets the “AACS Enhanced Mode Content.” The intent is to not only provide the basic capabilities of the business models, but also to superimpose the variety of conditions provided in the conditions section.
Pay at the Time of Consumption includes Enhanced mode content that cannot be played without paying a fee.
For a fee, the consumer may watch the directors cut version of the film, instead of the theatrical release version (which would be “basic” title).
A consumer receives a free copy of a movie disk at a convenience store. The disk would include the full movie, and trailers for the included movie as well as others. If the user wishes to view the full movie, they could pay a fee that would authorize playback. The disk could then be handed to a friend, etc.
In this case the main movie title would be flagged “enhanced” while the trailer for the movie and the terms and conditions would be flagged “basic.”
15 SD (Standard Definition) resolution movies are available on the disk. None of the movies are viewable without a financial transaction.
Time Release Subscription includes delivering disks to consumers based on a subscription model. These disks will work for the appropriate unit of time (e.g., Month of May '06).
HBO offers a disk subscription to customers that choose to receive terrestrial HD television. These customers may not have HBO available to them via cable/satellite. In this case, HBO would mail 2 SD disks per month to the customer (30 hours of content per Disk). These disks would have the appropriate months HBO content, but the disks would only be usable for the specified month.
As above, only some content unlocks on a specific day of the month to coincide with the premiere dates that occur on the subscription month. For example, episode 201 of Band of Brothers is only available after May 13th, when it premiers on HBO.
Locked Content includes a disk that has locked content that can only be accessed under certain conditions (e.g., online transaction).
Consumer acquires a travel book about a particular country. Contained in the book is a disk. The basic title of the disk describes the country, but there is enhanced content that can only be played while in the country.
Pre Purchase includes a consumer that acquires a disk that has content on it that will only be usable after a certain date.
Special disks could be made available for purchase at theaters during the theatrical release of a movie. These disks would not be usable until the retail release of the movie. The price of these disks could be the same price as the retail disks, but include special content, or they could be priced lower than the retail disks. The consumer would have a compelling reason to attend the theatrical release instead of waiting to purchase the HD DVD.
Time Released Conditions include usage rules that are expanded over time.
When first released, a disk might be a pay per view disk. After a certain time window, the consumer may be permitted to “convert” the disk to a traditional “play from disk” disk.
Consumer buys a new high resolution display. They then go to a rental shop to rent their favourite movie. They are prevented from viewing the high resolution version for two months because the rental version has limited rights until the end of the year.
As far as security concerns, the disk might or might not have the actual movie content. The disk might include only promotions and playlists for acquiring the movie as download content closer to the release window.
The following Enhanced Mode Content (Content Downloaded and Used with Disk) models, include additional content being made available online to use with the disk. This additional content may have various conditions placed on the ability to play it (e.g., geographic, time, fee, etc.).
Streaming Content includes online content can being streamed from a service for use in conjunction with the disk.
A consumer acquires a disk with the option to have an audio commentary from an actor in the movie played in sync with the movie. This commentary is not a replacement sound track, but an additional track played with the rest of the movie.
Downloaded Content includes online content that can be delivered and stored for use in conjunction with the disk.
A consumer identifies additional subtitle material is available for use with a movie. They download the subtitles and store it on their compliant device, but the subtitles are not usable unless they are used with the associated disk. The consumer then rents the disk and views the subtitles during the movie playback.
Advanced Copy (AC) Content (Content Copied from Disk) includes an exemplary version of a copy. The AC model does not preclude or interfere in any way with the “AACS Managed Copy” (MC). The AC feature is optional for device implementers and built on top of AACS.
The primary difference between an AC and an MC is that the usage of an AC is determined by “Usage Rules” that are both flexible and can vary on a title-by-title basis while the usage of an MC is determined by the AACS specifications and compliance rules, which are fixed across all content types.
Usage rules are specified that control two aspects of an AC. The first are rules that govern under which conditions an AC can be created. The rules for creating an AC can be very sophisticated, and include many parameters, including such things as: fees, geographical restrictions, memberships, target DRM Systems, dates, resolutions, and tracking, etc.
The second aspect is the actual usage of an AC. After an AC is created, usage rules are associated to govern the usage of the AC. These rules can also be very sophisticated and include similar types of parameters as the rules for authorizing the creation of the AC.
A disk may include a main title movie, with permission to create a MC for a fee of $5. The consumer could create an MC in accordance with AACS compliance or . . .
If the consumer owned a device compliant with the exemplary embodiments they may also see an offer for an AC. This offer may state that they have the ability to create an AC for free, but the AC is locked to the receiving DRM system, and requires $3 each time to play it.
Bind to Device included content that can be copied from the disk, but can only be played in the presence of an identified device after the copy is created.
A consumer acquires a disk with an offer which allows the consumer to create a copy of the content onto his/her player's protected storage. Creating the AC could have usage rules associated with it (e.g., a fee), and the AC would have usage rules associated with it (e.g., only playable by this particular player).
A consumer borrows a disk from a friend. There is an AC creation offer that allows the consumer to create an AC for free, with the condition that it is only usable for 1 day after the AC is created, and only by the target device.
Superdistribution includes copies of the disk content that are permitted to be distributed directly between a customer and his/her friends. A distributed version of the content might not be usable without additional permissions or usage rules being granted from a server.
A consumer borrows a disk from a friend. The disk permits the creation of an AC. The creation of the AC could be for free, but the AC content would be unusable until a $15 fee is paid. At the time the fee is paid, the AC content could then be playable indefinitely by the associated device.
As in the above example, except the consumer uses his/her broadband connection to send a copy of the movie to his/her friend. In this case, the AC creation offer could be contingent on identifying the target device at creation time. In this manner, the consumer could push a copy of the movie to a friend, and the friend could opt to pay for the movie without having to get the disk.
Advanced Copy Content (Content Copied from Disk into the Clear) includes an assumption that disks include either clear content or content protected by AACS, and that the AACS compliance rules govern the use of AACS protected content after it has been unlocked by AACS.
These models provide an additional mode where the content can be protected by AACS until certain conditions are met and then released into the clear. The content is presumed to be either inherently protected by some other means (e.g., game copy protection) or released into a clear format (e.g., mp3, jpg, etc.).
The disk includes non theatrical material for purchase. For a fee the user can unlock an XBox game related to the movie.
Users who register their movie with WB.com can copy files from the disk like movies, wallpaper, ring tones, etc.
In general, conditions are specified circumstances that must be met in order for a complaint system to act. Whereas usage rules govern when and how content can be played or released to another DRM system, conditions on these actions help to build particular business models. Here are some examples:
A per use fee condition placed on the ability to play enhanced content builds a pay per view model.
A time condition placed on the ability to play enhanced content can be used to implement a rental model or pre purchase model.
A fee condition placed on the abililty to create a copy can be used to implement a form of Superdistribution.
A fee condition placed on the ability to use a copy implements a different flavor of Superdistribution. In this case creating the copy may have been free, while using the copy incurs a fee.
This section describes the targeted types of conditions for the Exemplary business models.
Time Constraint includes the ability to use or distribute content that may be governed by some time constraints.
Fixed time, date, either or both
Start time
End time
Relative to online authorization time
Relative to AC generation time
Output Regulated includes when content is used that there may be restrictions on the types of ports that can be used to deliver the content to various rendering devices.
Must be digital output (no analog)
Must be protected if HD
Geographic includes the usage of the content that could be restricted to certain geographical areas.
Country
Payment includes content that can be used when a payment is made.
Per use fee—a fee is required each time the content is played.
Flat fee—a one-time fee is required for using the content.
The following sections capture the architecture scope intended to be supported for the exemplary embodiments and some assumptions and issues upon which the scope relies. An objective of the exemplary embodiments is to deliver a set of specifications and REL licenses, for example, for the mastering of HD DVD discs by Warner Brothers.
The following sections, together with the Exemplary business models, define the scope of the exemplary embodiments.
The architecture scope is to support the business models described in the Exemplary business models and the requirements specified in the AACS Common Book for the title usage file (TUF).
The remaining sections describe the exemplary system components, a number of the architectural scenarios that the exemplary embodiments support, list exemplary embodiments related to Technical Compliance Rules.
This section describes the exemplary system components, which include:
Accordingly, the exemplary system components diagram 2900 of
The exemplary system 2900 of
A Disk 2801: This component includes an AACS HD DVD pre-recorded disk (recordable disks are not considered) that includes protected content governed by usage rules written according to the exemplary Rights Expression Book and the exemplary Interface Book. The exemplary Interface Book also defines the exact nature of the binding between the protected content and the usage rules.
A Player 2903: This component is capable of exercising rights to use and possibly distribute the protected content encoded on the disk 2801.
A Content Server 2901: This component is a server that provides ancillary protected content or TUFs to a requesting player 2903. Downloading content or TUFs from the content server 2901 enables the player 2903 to obtain content or usage rules in addition to those stored on the disk 2801.
An Authorization Server 2902: This component authorizes a requested exercise of rights for a requesting player 2903. Determining the appropriate authorization response may involve interpreting usage rules 2807 stored on the server 2902, receiving or verifying payment, or other authorization processing. Any usage rules 2807 stored on the authorization server 2902 are communicated to it out of band.
It is expected that a few content and authorization servers 2902 will communicate with many players 2903.
No separate service need exist purely for the purpose of issuing licenses. There is no need to transmit only licenses between entities like a server 2902 and the player 2903 or vice versa.
To exercise rights to use the protected content on the disk 2801:
Usage rules can be associated with protected content in one of the following ways:
Copy-related usage rules are associated with a ResourceGroup
Other usage rules are associated with EVOBS and Playlists.
Usage rules need not be separately signed, but can be integrity protected as part of the AACS packaged content. The issuer of usage rules is the content provider. The key for the integrity of the usage rules belongs to AACS LA.
This section describes architectural scenarios illustrating exercise of the various rights supported by the exemplary embodiments.
When a user wants to play the protected content encoded on the disk 2801, the player 2903 interprets the usage rules associated with the protected content 2803 to determine whether the Play right is authorized. Exercise of the right may be authorized in one of the following ways:
The Play right is authorized by the usage rules encoded on the disk 2801.
The Play right is contingent upon authorization by an authorization server 2902, and the player 2903 requests the required authorization. The authorization server 2902 determines the appropriate response (which may involve interpreting usage rules 2807 stored on the server 2902 and/or making payments) and sends that response to the player 2903.
The requested Play operation requires additional protected content or additional TUFs, and the player 2903 requests the required content from the content server 2901. The content server 2901 sends the requested protected content or TUFs 2803 to the player 2903. If appropriate, the player 2903 may interpret additional usage rules included in TUFs received from the content server 2901 to determine whether the Play right is authorized.
If the Play right is authorized, the player plays the protected content.
Use of a managed copy is determined by the AACS specifications and compliance rules, and the rules can be fixed across all content types.
The following is assumed about the AACS Managed Copy function:
The intent of Managed Copy is for a DRM system to receive a version of the content from the disk 2801 that is then governed by the DRM system.
AACS compliance rules determine the usage of a Managed Copy, and it is assumed that the compliance rules allow the DRM system to play the Managed Copy indefinitely, but the compliance rules may preclude the Managed Copy from being indiscriminately retransmitted to other systems.
Furthermore, it is assumed that each disk 2801 must make an offer available for some pricing terms and conditions that allow a compliant AACS system to make a Managed Copy to one of the AACS approved DRM systems.
When a user wants to make a managed copy of the protected content 2803 encoded on the disk 2801, the player 2903 interprets the usage rules associated with the protected content 2803 to determine whether the Managed Copy right is authorized. Exercise of the right may be authorized in the following way.
The Managed Copy right is authorized by the usage rules encoded on the disk 2801. The exemplary usage rules can be used to authorize exercise of the Managed Copy right without connecting to the authorization server 2902.
The Managed Copy right is contingent upon authorization by an authorization server 2902, and the player 2903 requests the required authorization. The authorization server 2902 determines the appropriate response (which may involve interpreting usage rules 2807 stored on the server 2902 and/or making payments) and sends that response to the player 2903.
If the Managed Copy right is authorized, the player 2903 creates a copy of the protected content 2803 and associates new usage rules with it as specified in the AACS specifications and compliance rules.
The Advanced Copy right is the exemplary version of a copy. In the case of exercising the Managed Copy right, the use of a copy is determined by the AACS specifications and compliance rules, and the rules can be fixed across all content types. In the case of exercising the Advanced Copy right, use of the copy is governed by usage rules that are flexible and can vary on a title-by-title basis. The usage rules can be very sophisticated and include many parameters, including such things as fees, geographical restrictions, memberships, target DRM systems, dates, resolutions, tracking, and the like.
When a user wants to make an advanced copy of the protected content 2803 encoded on the disk 2802, the player 2903 interprets the usage rules associated with the protected content 2803 to determine whether the Advanced Copy right is authorized. Exercise of the right may be authorized in one of the following ways:
The Advanced Copy right is authorized by the usage rules encoded on the disk 2802.
The Advanced Copy right is contingent upon authorization by an authorization server 2902, and the player 2903 requests the required authorization. The authorization server 2902 determines the appropriate response (which may involve interpreting usage rules 2807 stored on the server 2902 and/or making payments) and sends that response to the player 2903.
If the Advanced Copy right is authorized, the player 2903 creates a copy of the protected content 2803 and the specified usage rules.
When a user wants to make a clear copy of the protected content 2803 encoded on the disk 2801, the player 2903 interprets the usage rules associated with the protected content 2803 to determine whether the Clear Copy right is authorized. Exercise of the right may be authorized in one of the following ways:
The Clear Copy right is authorized by the usage rules encoded on the disk 2801.
The Clear Copy right is contingent upon authorization by an authorization server 2902, and the player 2903 requests the required authorization. The authorization server 2902 determines the appropriate response (which may involve interpreting usage rules 2807 stored on the server 2902 and/or making payments) and sends that response to the player 2903.
If the Clear Copy right is authorized, the player 2903 creates a clear copy 2804 of the protected content 2803. The clear content 2804 is presumed to be either inherently protected by some other means (such as game copy protection) or released into a clear format (such as mp3, jpg, and the like).
When a user wants to expand their rights in an authorized manner (for example, binding certain rights to a certain player 2903), the player 2903 interprets the usage rules associated with the protected content 2803 to determine whether the Issue right is authorized. Exercise of the right may be authorized in one of the following ways:
The Issue right is authorized by the usage rules encoded on the disk 2801.
The Issue right is contingent upon authorization by an authorization server 2902, and the player 2903 requests the required authorization. The authorization server 2902 determines the appropriate response (which may involve interpreting usage rules 2807 stored on the server 2902 and/or making payments) and sends that response to the player 2903.
If the Issue right is authorized, the player 2903 creates the new rights for use in other authorizations.
When a user wants to play an advanced copy of the protected content 2803, the player 2903 interprets the usage rules associated with the copy to determine whether the Play Advanced Copy Content right is authorized. Exercise of the right may be authorized in one of the following ways:
The Play Advanced Copy Content right is authorized by the usage rules associated with the copy.
The Play Advanced Copy Content right is contingent upon authorization by an authorization server 2902, and the player requests the required authorization. The authorization server 2902 determines the appropriate response (which may involve interpreting usage rules 2807 stored on the server 2902 and/or making payments) and sends that response to the player 2903.
The requested Play Advanced Copy Content operation requires additional protected content or additional TUFs 2803, and the player 2903 requests the required content from the content server 2901. The content server 2901 sends the requested protected content or TUFs 2803 to the player 2903. If appropriate, the player 2903 may interpret additional usage rules included in TUFs received from the content server 2902 to determine whether the Play Advanced Copy Content right is authorized.
If the Play Advanced Copy Content right is authorized, the player 2903 plays the copy.
Further exemplary embodiments include determining the list of compliant advanced copy destinations, determining the list of compliant geographic determination technologies and the process/robustness criteria for approving such technologies, determining the list of compliant time determination technologies and the process/robustness criteria for approving such technologies, designating the authority who determines whether usage rules are not being respected and, if such authority is not AACS LA itself, remedy process to get AACS LA to revoke the offending devices, and the like.
The above-described devices and subsystems of the exemplary embodiments can include, for example, any suitable servers, workstations, PCs, laptop computers, PDAs, Internet appliances, handheld devices, cellular telephones, wireless devices, other devices, and the like, capable of performing the processes of the exemplary embodiments. The devices and subsystems of the exemplary embodiments can communicate with each other using any suitable protocol and can be implemented using one or more programmed computer systems or devices.
One or more interface mechanisms can be used with the exemplary embodiments, including, for example, Internet access, telecommunications in any suitable form (e.g., voice, modem, and the like), wireless communications media, and the like. For example, employed communications networks or links can include one or more wireless communications networks, cellular communications networks, G3 communications networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, a combination thereof, and the like.
It is to be understood that the devices and subsystems of the exemplary embodiments are for exemplary purposes, as many variations of the specific hardware used to implement the exemplary embodiments are possible, as will be appreciated by those skilled in the relevant art(s). For example, the functionality of one or more of the devices and subsystems of the exemplary embodiments can be implemented via one or more programmed computer systems or devices.
To implement such variations as well as other variations, a single computer system can be programmed to perform the special purpose functions of one or more of the devices and subsystems of the exemplary embodiments. On the other hand, two or more programmed computer systems or devices can be substituted for any one of the devices and subsystems of the exemplary embodiments. Accordingly, principles and advantages of distributed processing, such as redundancy, replication, and the like, also can be implemented, as desired, to increase the robustness and performance of the devices and subsystems of the exemplary embodiments.
The devices and subsystems of the exemplary embodiments can store information relating 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, and the like, of the devices and subsystems of the exemplary embodiments. One or more databases of the devices and subsystems of the exemplary embodiments can store the information used to implement the exemplary embodiments of the present inventions. The databases can be organized using data structures (e.g., records, tables, arrays, fields, graphs, trees, lists, and the like) included in one or more memories or storage devices listed herein. The processes described with respect to the exemplary embodiments can include appropriate data structures for storing data collected and/or generated by the processes of the devices and subsystems of the exemplary embodiments in one or more databases thereof.
All or a portion of the devices and subsystems of the exemplary embodiments can be conveniently implemented using one or more general purpose computer systems, microprocessors, digital signal processors, micro-controllers, and the like, programmed according to the teachings of the exemplary embodiments of the present inventions, as will be appreciated by those skilled in the computer and software arts. Appropriate software can be readily prepared by programmers of ordinary skill based on the teachings of the exemplary embodiments, as will be appreciated by those skilled in the software art. Further, the devices and subsystems of the exemplary embodiments can be implemented on the World Wide Web. In addition, the devices and subsystems of the exemplary embodiments can be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be appreciated by those skilled in the electrical art(s). Thus, the exemplary embodiments are not limited to any specific combination of hardware circuitry and/or software.
Stored on any one or on a combination of computer readable media, the exemplary embodiments of the present inventions can include software for controlling the devices and subsystems of the exemplary embodiments, for driving the devices and subsystems of the exemplary embodiments, for enabling the devices and subsystems of the exemplary embodiments to interact with a human user, and the like. Such software can include, but is not limited to, device drivers, firmware, operating systems, development tools, applications software, and the like. Such computer readable media further can include the computer program product of an embodiment of the present inventions for performing all or a portion (if processing is distributed) of the processing performed in implementing the inventions. Computer code devices of the exemplary embodiments of the present inventions can include any suitable interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes and applets, complete executable programs, Common Object Request Broker Architecture (CORBA) objects, and the like. Moreover, parts of the processing of the exemplary embodiments of the present inventions can be distributed for better performance, reliability, cost, and the like.
As stated above, the devices and subsystems of the exemplary embodiments can include computer readable medium or memories for holding instructions programmed according to the teachings of the present inventions and for holding data structures, tables, records, and/or other data described herein. Computer readable medium can include any suitable medium that participates in providing instructions to a processor for execution. Such a medium can take many forms, including but not limited to, non-volatile media, volatile media, transmission media, and the like. Non-volatile media can include, for example, optical or magnetic disks, magneto-optical disks, and the like. Volatile media can include dynamic memories, and the like. Transmission media can include coaxial cables, copper wire, fiber optics, and the like. Transmission media also can take the form of acoustic, optical, electromagnetic waves, and the like, such as those generated during radio frequency (RF) communications, infrared (IR) data communications, and the like. Common forms of computer-readable media can include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other suitable magnetic medium, a CD-ROM, CDRW, DVD, any other suitable optical medium, punch cards, paper tape, optical mark sheets, any other suitable physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other suitable memory chip or cartridge, a carrier wave or any other suitable medium from which a computer can read.
While the present inventions have been described in connection with a number of exemplary embodiments, and implementations, the present inventions are not so limited, but rather cover various modifications, and equivalent arrangements, which fall within the purview of prospective claims.
This application claims priority to U.S. Provisional Patent Application Ser. No. 60/721,523 of DeMartini, entitled “ADVANCE COPY WITH ISSUE RIGHTS,” filed Sep. 29, 2005, the entire disclosure of which is hereby incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 60721523 | Sep 2005 | US |
