Patent Application
20060143134
Ever since media entered the digital age, copyright owners have worried about the ease with which content can be shared. By this point in time, most of us are aware of just how easy it is to “rip” a compact disk (CD) or digital versatile disk (DVD). All of a sudden, one legitimate copy of copyrighted content can be used to spawn innumerable pirated copies. And worst of all, each copy will be just as robust in quality as the legitimate copy. The reason for this is that the digital copying process is, in essence, perfect. At least when pirated copies were made from analog media, copyright owners could relish in the fact that the pirated copies were never quite as good as the original.
Analog media was much more owner friendly because anti-copying mechanisms could be introduced into the recording themselves. Although these anti-copying mechanisms (e.g. the “Macrovision” system is one example) could be defeated, they could not be defeated without specialized hardware. Macrovision employs a technique known as synch-clipping where video synchronization pulses included in a video tape could be attenuated such that a television receiver could perceive the synchronization signals but a video recorder could not. As a result, a video pirate would need to introduce a specialized “black-box” in between the source video player and the copy recorder. Again, it was not so much that Macrovision could not be defeated, it was the fact that it was cumbersome and expensive to acquire and use the specialized hardware that made Macrovision much more effective than it otherwise would have been. It should be noted that Macrovision is often employed in DVD video disks, but it is even less effective here because a “DVD-ripper”, which is a software application tailored to steal video from a DVD disk, can easily recognize and overcome the Macrovision protection. Again, installing a DVD-ripper, which is typically available as a down from the Internet, on a personal computer is a great deal easier than buying an analog Macrovision “black box”.
In response to the ease with which media content can be defeated, the content industries (e.g. the music industry, the film industry and e-book publishers) have worked diligently to create digital rights management systems, which are typically known as DRM systems. By this point in time, there are literally a plethora of various DRM systems, the champions of each touting the efficacy of the protection afforded by their version of digital rights management.
To quickly summarize, essentially all DRM systems protect content through encryption. Encryption fulfills the basic requirement of any DRM system—to prevent access to the content unless it is specifically authorized. The various DRM systems known today differ in how they provide the authorized access to the encrypted content. For example, one DRM system provide a set of access rules, which are typically encoded into a content file. The access rules are used by a player (e.g. a CD or DVD disk) to determine if access is allowed. One example of an access rule is a region indicator, which indicates what geographic region in the world the content is authorized for.
More sophisticated DRM systems have also been conceived. For example, one system provides for a hardware token (e.g. an encoded integrated circuit chip) and a token reader. In order to gain access to content, the user must use a special presentation application that decrypts the content once a token has been properly recognized. What is important to realize is that there a wide variety of DRM systems, each of which claims to be the be-all to end-all DRM system.
The overall importance of DRM systems is growing every day. This is because many people now obtain their content through the Internet, or other form of electronic distribution. In this age of electronic distribution, an encrypted content file is provided to a user along with an access license. A specialized content player uses the license in order to decrypt the content and, once decrypted, present the content to a user. Typically, the access license is encoded with use-rules and other information that prevents the license from piracy. For example, an access license can be encoded with a hardware-specific platform identifier (e.g. a serial number of a personal media player) or user name. This can be done either when the license is granted or when the license is first used to play its associated content.
However, even the most sophisticated DRM systems sometimes have difficulty enabling certain types of usage that a content owner would like to permit. For example, when content was distributed on a physical medium, it was clearly possible to lend the medium to a friend or to sell the content second-hand. Once the medium was loaned out, the original owner of the content could no longer use the content because the act of loaning (or selling) the medium deprived the original owner to any further access to the content. In today's age of DRM, the owner of content simply can not lend or sell his content to any third party. This is because a license encoded with a hardware-specific platform identifier or user name will simply not work in any other environment.
A method and apparatus for sharing a digital access license by receiving a request to share the license, identifying a current license to be shared, preparing a loaner-license according to the current license and conveying the loaner-license to a borrowing client.
Several alternative embodiments will hereinafter be described in conjunction with the appended drawings and figures, wherein like numerals denote like elements, and in which:
According to one illustrative use case, a borrowing user 55 can submit a request 60 to borrow a digital access license from the owner user 50. Accordingly, the request is received from the borrowing user 55 by the borrowing client 35. The borrowing client 35 can then direct the request 65 to the owner client 30. According to one illustrative use case, the owner client 30 will then make the owner user 50 aware of the incoming request. The owner user 50 can authorize the request by entering an allow indication 95 into the owner client 30. The owner client 30 can then prepare and deliver a loaner-license 70 back to the borrowing client 35. The request from the borrowing client 35 can, according to one illustrative use case, alternatively be directed to a license authority 40. This alternative request path 75 relies on the license authority 40 to propagate request 80 to the owner client 30. A loaner-license is then directed 85 to the license authority 40. The license authority 40 can then forward the loaner-license 90 to the borrowing client 35. In all of these illustrative use cases, communications are enabled by means of a numerous variety of physical interfaces, including, but not limited to an Ethernet interface, a serial interface (e.g. RS-232), a universal serial bus (a.k.a. USB), an infrared interface, a Bluetooth interface and a wireless networking interface (e.g. varied versions of IEEE 802.11).
In order to share an access license, the present method provides for creating a loaner-license according to the current license (step 15). It should be appreciated that the loaner-license will typically include attributes pertaining to the current license to be shared. Once the loaner-license is prepared, it is conveyed to a borrowing client (step 20). According to one variation of the present method, conveyance to a borrowing client is accomplished by conveying the loaner-license directly to the borrowing client 35. According to yet another variation of the present method, conveyance to a borrowing client 35 is accomplished by directing the loaner-license to license authority 40, which then forwards the loaner-license to the borrowing client 35.
According to one example alternative variation of the present method, a local user (e.g. the owner user 50) is made aware of a request to borrow a digital access license received by the owner client 30. The owner client 30, according to this variation of the present method, waits for the owner user 50 to indicate that the loan should be allowed. Accordingly, the owner client 30 receives as an allow-loan indicator from the owner user 50 and, in response, prepares a loaner-license and directs said loaner-license to the borrower client 35.
It should be appreciated that, according to one variation of the present method, a loan-limit indicator comprises a share-quantity limit indicator (step 170). The share-quantity limit indicator, as discussed above, provides an indication of how many times a current license can be shared. Typically, the share-quantity indicator is created by extracting a share-quantity indicator from a source license (e.g. a current license to be shared maintained in the owner client 30) and decrementing the extracted share-quantity indicator whenever a loaner-license is created according to the current license.
It should be appreciated that, according to one variation of the present method, a loan-limit indicator comprises a share-depth limit indicator (step 172). The share-depth limit indicator, as discussed above, provides an indication as to what extend a current license can be shared by a borrowing client with a second borrowing client. Typically, the share-depth indicator is created by extracting a share-depth indicator from a source license (e.g. a current license to be shared maintained in the owner client 30) and decrementing the extracted share-depth indicator whenever a loaner-license is created according to the current license.
According to yet another variation of the present method, a loan-limit indicator is created by creating an expiration epoch indicator (step 175). It should be appreciated that, according to the sires of an owner user 50, a loaner-license may be temporal in nature. Accordingly, an expiration epoch indicator is created by determining a current time at which a loaner-license is created and then adding to the current time an amount of time for which the loaner-license is to remain valid.
According to yet another example variation of present method, a loan-limit indicator is created by creating to use-limit indicator (step 180). It should be appreciated that an owner user 50 may only wish to allow a borrowing client a limited number of accesses to a particular media file. Accordingly, a use-limit indicator indicates the number of times a loaner-license may be used to access a media file. It should be appreciated that, according to this variation of the present method, a borrowing client 35 may need to relinquish the loaner-license once it has been used a discrete number of times in accordance with the use-limit indicator.
According to yet another example variation of the present method, a loan-limit indicator is created by creating a borrower-specific indicator (step 185). As already discussed supra, a loaner-license may be created specifically for particular borrowing client 35. As such, a borrower-specific indicator, which is typically received from the borrowing client 35, is included as a loan-limit indicator in a loaner-license created according to this variation of the present method.
Various example embodiments of an apparatus for sharing a digital access license 305 as heretofore described further include various functional modules each of which comprises an instruction sequence that can be executed by the processor 300. An instruction sequence that implements a functional module, according to one alternative embodiment, is stored in the memory 310. The reader is advised that the term “minimally causes the processor” and variants thereof is intended to serve as an open-ended enumeration of functions performed by the processor 300 as it executes a particular functional module (i.e. instruction sequence). As such, an embodiment where a particular functional module causes a processor 300 to perform functions in addition to those defined in the appended claims is to be included in the scope of the claims appended hereto.
The functional modules (and their corresponding instruction sequences) described thus far that enable sharing a digital access license are, according to one alternative embodiment, imparted onto computer readable medium. Examples of such medium include, but are not limited to, random access memory, read-only memory (ROM), Compact Disk (CD) ROM, Digital Versatile Disk (DVD), floppy disks, hard disk drives and magnetic tape. This computer readable medium, which alone or in combination can constitute a stand-alone product, can be used to convert a general-purpose computing device into a device for sharing a digital access license wherein said device is capable of sharing a digital access license according to the techniques and teachings presented herein. Accordingly, the claims appended hereto are to include such computer readable medium imparted with such instruction sequences that enable execution of the present method and all of the teachings herein described.
Stored in the memory 310 of this example embodiment are several functional modules including a protocol stack 340 and a license manager 350. According to one alternative illustrative embodiment, an apparatus for sharing a digital access license 305 further includes an electronic mail module 345, which is also stored in the memory 310. In yet another alternative embodiment, an apparatus for sharing a digital access license further comprises an encryption module 355 that is also stored in the memory 310. In yet another alternative embodiment, an apparatus for sharing a digital access license further comprises a content provider module 360. The content provider module 360 of this alternative embodiment is also stored in the memory 310. It should be appreciated that the memory 310 is also used to store information. For example, the memory 310 can, according to various alternative embodiments, be used to store a received request for a loaner-license 365, a license table 370 a content cache 375 and a loaner-license 380 that is being prepared to be conveyed to a borrowing client.
In yet another alternative embodiment, the digital access license 420 includes a share quantity limit field 440. The share quantity limit field 440 is used to store a value that specifies the number of times either an original (e.g. a current) license or a loaner-license can be shared. In yet another alternative embodiment, the digital access license 420 includes a share depth limit field 445. The share depth limit field 445 is used to store a value that specifies the extent to which a loaner-license can be shared with subsequent borrowing clients. According to yet another alternative embodiment, the digital access license 420 includes an expiration epoch field 450. The expiration epoch field 450 is used to store a time at which a loaner-license is to expire. In yet another alternative embodiment, the digital access license 420 includes use-limit field 455. The use-limit field 455 is used to store a value that indicates how many times a loaner-license can be used before it expires (i.e. a play limit). One additional illustrative embodiment of a digital access license further includes an on-loan flag 460. The on-loan flag 460 is used to indicate that a current license (or a loaner-license that is used to create another loaner-license) has been loaned to another user. Typically, a digital access license can not be used to access a media file when the on-loan flag 460 is set.
In one alternative illustrative embodiment, the license manager 350 causes the processor to receive a request to share a digital access license by minimally causing the processor to execute an electronic mail module 345. When executed by the processor 300, the electronic mail module 340 interacts with the protocol stack 340 to establish a connection with a mail server by means of the communications interface 340. Accordingly, the electronic mail module 345 further minimally causes the processor to receive 465 an electronic mail message. The electronic mail module 345 conveys the electronic mail message to the license manager 350, which further minimally causes the processor 300 to extract a request to share a digital access license from the received electronic mail message. It should be appreciated that the received electronic mail message can be received either from a borrowing client 35 directly or through an intermediary such as a license authority 40.
According to one alternative embodiment, an apparatus for sharing a digital access license 305 include a user input device 330 and the user output device 325. In this alternative embodiment, the license manager 350 further minimally causes the processor to direct 500 to the user output device 325 an indication that the license manager 350 has received 470 a request to share a digital access license. An owner user 50 can acknowledge the request. When the license manager 350 receives 505 an allowance indication from the user input device 330, the license manager 350 further minimally causes the processor to prepare a loaner-license according to a current license which is identified in the license table 370.
According to yet another alternative illustrative embodiment, the license manager 350 causes the processor to receive a request to share a digital access license by minimally causing the processor 300 to receive by means of the communications interface 320 an encryption key. It should be appreciated that the encryption key is typically included in a request for a loner license 390 and is included in an encryption key field 405 included therein. Typically, the encryption key included in a request for a loaner-license comprises a public-key that can be used to encrypt a loaner-license prepared in response to the request.
According to yet another alternative example embodiment, the license manager 350 causes the processor to receive a request to share a digital access license by minimally causing the processor 300 to receive by means of the communications interface 320 a borrower-specific identifier. It should be appreciated that the borrower-specific identifier is typically included in a request for a loner license 390 and is included in a borrower-specific identifier field 400 included therein. Typically, the borrower-specific identifier included in a request for a loaner-license is used to personalize a loaner-license prepared in response to the request.
According to yet another illustrative alternative embodiment, the license manager of 350 of the causes the processor to receive a request to share a digital access license by minimally causing the processor to receive a request to share digital access license by means of the user input device 330. Accordingly, an owner user 50 can issue a request 100 to share a digital access license. As such, this alternative embodiment of the license manager 350, when executed by the processor, minimally causes processor to receive 505 the owner user's 50 request 100 by means of the user input device 330.
According to yet another alternative embodiment, the license manager 350 causes the processor to prepare a loaner-license by minimally causing the processor to determine when a current identified license stored in the memory 310 is shareable. Typically, the license manager 350 minimally causes the processor 300 to retrieve 480 a current identified license from the license table 370. This alternative example embodiment of a license manager 350 further minimally causes the processor 300 to create a loaner-license according to the current identified license stored in the memory 315 once it determines that the current identified license is shareable.
In one example alternative embodiment, the license manager 350, using a current identified license retrieved 480 from the license table 370, minimally causes the processor to determine if a current identified license is shareable by minimally causing the processor 300 to examine a share-quantity limit included in a share quantity limit field 440 included in the current identified license. This alternative embodiment of a license manager 350 causes the processor 300 to note that the current identified license is shareable when the share-quantity limit indicates that the current identified license is shareable. This can be accomplished in a wide variety of manners. For example, the share-quantity limit can be a numeric value that indicates how many times a license can be shared. As such, this alternative embodiment of a license manager 350 updates the share-quantity limit in the current identified license in order reflect the creation of a loaner-license. For example, the processor 300, according to this alternative embodiment, is minimally caused to decrement the share-quantity limit included in the current identified license stored in the license table 370. The decremented value is also reflected in any loaner-license created according to the current identified license.
In yet another example alternative embodiment, the license manager 350, using a current identified license retrieved 480 from the license table 370, minimally causes the processor to determine if a current identified license is shareable by minimally causing the processor 300 to examine a share-depth limit included in a share depth limit field 445 included in the current identified license. This alternative embodiment of a license manager 350 causes the processor 300 to note that the current identified license is shareable when the share-depth limit indicates that the current identified license is shareable. This too can be accomplished in a wide variety of manners. For example, the share-depth limit can be a numeric value that indicates how many times a sub-license can be created based on an instant license. As such, this alternative embodiment of a license manager 350 updates the share-depth limit in a loaner-license created according to the current identified license in order reflect the creation of a loaner-license. For example, the processor 300, according to this alternative embodiment, is minimally caused to decrement the share-depth limit retrieved from the current identified license stored in the license table 370 and to incorporate the decremented value into a newly created loaner-license.
It should be appreciated that, according to one alternative example embodiment of a license manager 350, the license manager 350 causes the processor to prepare a loaner-license by minimally causing the processor to create a loaner-license 380 in the memory 310. As this alternative embodiment of the license manager 350 causes the processor 300 to prepare a loaner-license, it should also be appreciated that, according to one alternative example embodiment of a license manager 350, the license manager 350 causes the processor 300 to create a loan-limit indicator, which can include but is not limited to at least one of a share-quantity limit indicator, a share-depth indicator, and expiration epoch indicator, a use-limit indicator, a frequency limit indicator and a borrower-specific identifier commensurate with the teachings of the present method as heretofore described. The license manager 350 then further minimally causes the processor 300 to include the loan-limit indicator in a loaner-license that it creates according to an identified current license stored in the memory 315, which can be stored as a record in the license table 307. It should further be appreciated that, according to one alternative embodiment, the license manager 350 causes the processor 300 to create an expiration epoch indicator according to a time value received from the time-clock 317.
According to yet another alternative embodiment, the license module 350 causes the processor 300 to convey a loner-license to a borrowing client 35 by minimally causing the processor 300 to execute an encryption module 355. According to this alternative example embodiment, the license manager 350 minimally causes the processor 300 to retrieve a prepared loner-license 380 from the memory 310 and to direct 520 the prepared loner-license to the encryption module 355 along with an encryption key received in association with a request 365 for a loner-license. Accordingly, the encryption module 355, as it is executed by the processor 300, minimally causes the processor 300 to encrypt the prepared loner-license 380 according to the encryption key. The license manager 350 further minimally causes the processor to direct 475 the encrypted loner-license to the protocol stack 340, for example to a communications connection established by the processor 300 as it executes the protocol stack 340.
According to yet another alternative example embodiment, the license manager 350 causes the processor 300 to execute the protocol stack 340 in order to establish a communications connection with a license authority 40 or another arbitrary intermediary. A prepared loner-license 380 is then retrieved 530 from the memory 310 and directed to the communications connection established by the processor 300 with an intermediary or with a license authority 40 as the processor 300 executes the protocol stack 340.
According to one alternative embodiment, an apparatus for sharing a digital access license 305 also includes a content provider module 360 stored in the memory 310. According to this alternative example embodiment, the license manager 350 examines an incoming request for a loner-license, which is typically stored 365 in the memory 310, to determine whether or not the request includes an active “content-also” flag 415. If so, this alternative example embodiment of a license manager 350 further minimally causes the processor 300 to execute the content provider module 360. When executed by the processor 300, the content provider module 360 minimally causes the processor 300 to retrieve 490 a media file from the content cache 375 and to direct 495 the media file to a communications connection established by the processor 300 when it executes the protocol stack 340. Typically, the communications connection is established with a borrower client 35 and is used to affect the conveyance of a media file which is associated with a loner-license prepared in response to the request to borrow a digital access license. It should also be appreciated that, according to yet another alternative example embodiment, the license manager 350 further minimally causes the processor to mark a current identified license as “on-loan”. Accordingly, this alternative embodiment of the license manager 350 causes the processor 300 to update an identified current license stored in the license table 370, for example by setting an “on-loan” flag 460 included in the identified current license.
While the present method and apparatus has been described in terms of several alternative and exemplary embodiments, it is contemplated that alternatives, modifications, permutations, and equivalents thereof will become apparent to those skilled in the art upon a reading of the specification and study of the drawings. It is therefore intended that the true spirit and scope of the claims appended hereto include all such alternatives, modifications, permutations, and equivalents.
