Method for sharing rights objects between users

[0001] The subject of the invention is a method of providing all or part of authority objects (OU) to users.

[0002] Rapid development of wireless internet and communication technologies has recently been observed, and portable or hand-held terminals with advanced multimedia functions are widely used by users on a daily basis. Cell phones have been equipped with a huge number of additional functions. For example, cameras with monophonic ring tones are replaced by polyphonic models capable of reproducing 16 or even 32 instruments simultaneously. Recently, models capable of imitating the sound of 64 instruments have also been developed. In addition, the demand for mobile phones with digital cameras is increasing. As customers became more and more interested in mobile, multimedia terminals, individual companies and even entire industries offering content and services for these devices, such as new ring tones, began to develop quickly. audio played while waiting for a connection, pictures and photos of artists or favorite characters, as well as video materials such as films or recordings of sporting events. In the past, content sharing services were usually free. However, the trend towards charging for them is beginning to emerge. At the beginning of this activity, the primary goal of content providers was to increase the ability to protect content offered to users against illegal copying. As a result, content providers and distributors have developed many mechanisms based on anti-piracy security technology. Today, more and more companies are using digital rights management (DRM) mechanisms that allow you to conveniently and flexibly manage entitlement objects (OUs).

[0003] Although the DRM mechanism allows free access to encrypted content to users, it prevents the content from being used before buying the rights objects that have been associated with them. The ability to freely distribute po2 content allows users to pass on DRM-protected content to friends and family members who want to show it, which promotes the dissemination of high-quality content, distribution and promotion by the users themselves. To play encrypted content, the recipient must have an authority object associated with that content. In other words, the recipient cannot play content that he has received from another user without purchasing the rights object.

[0004] Figure 1 shows a traditional method of distributing DRM protected content.

[0005] The first user 101 receives the encrypted content from the content provider 130 for playback. Although this encrypted content can be freely sent and distributed, you must have the authority object associated with it to play it. When the first user 101 requests (buys) a rights object from the publisher 100 rights because he wants to play the content, the 100 rights publisher sends the first user 101 the requested (purchased) OU, and the user is then entitled to play the content and use the multimedia information contained therein.

[0006] When the first user 101 likes the content he has played, and wants to share it with a friend who is the second user 102, then the first user 101 transfers the content to the second user 102. The second user 102 must have the RO to be able to play the encrypted content received from the first user 101. The second user 102, who does not have the rights object associated with the content, asks the publisher 100 to send the RO necessary to play. The second user 102 may receive the desired content directly from the content provider 300 as well as from the first user 101.

[0007] The traditional DRM mechanism, shown in figure 1, does not allow a user using the service to share the rights objects necessary to play content with another user. To solve this problem, published Japanese Patent Application No. 2003-58657 proposed a way to share the license necessary to use content with another user who requires:

1. Store license information for tiusc in the private area of ​​the license information database for each user or terminal.

2. After receiving the task of transferring from the party transferring the right, creating an encryption key, encrypting information about the license to be sent using the encryption key, transferring the encrypted information from the private to the public area and issuing the encryption key to the party transferring the right.

3. Providing the created encryption key by the transferring party to the receiving party.

4. After ordering, I will request Jtrorna to send and license the website to the host party by checking that it has the encryption key that was issued to the party making the transfer.

5. After authentication, decrypting information about the license being sent using the encryption key, and then transferring the decrypted information from the public area to the private area of ​​the receiving party. [0008] The proposed solution gives the user in possession of a license to play the content the opportunity to transfer it to another user. In other words, you have permission to share the license of your content with others.

[0009] In a conventional approach, however, the content license provider and content server are responsible for managing content licenses, and license information is only stored on the server. In other words, the server must be involved in the process of exchanging licenses between users. Moreover, after receiving a request to send a license from the party making the transfer of rights, the server performs its initial authentication. This means that in order to transfer the content license to the receiving party, the transferring party receives the appropriate encryption key from the server and forwards it to the receiving party. Then the receiving party is authenticated with an encryption key so that it can use the content. In this way, the conventional approach requires a complex license transfer process.

[0010] WO 02/06931 describes systems and techniques for controlling and managing digital assets. These systems and techniques are particularly useful when digital resources are sent electronically, such as over the Internet, because they can be used to securely distribute and control digital assets over the internet. What's more, they allow for dynamic control and management of digital assets, regardless of where they are located. The use of these systems and techniques enables the development of new distribution models based on the Internet and gives a better insight into the use and condition of digital resources. Selected implementations of these systems and techniques offer features such as digital content control throughout their lifetime, multi-level digital content control (including session encryption, resource encryption and remote management), as well as the "try before you buy" business model. They also support functions such as digital rights transfer, tracking, segmentation, archiving and better implementation of content improvement and updating.

[0011] EP 0 715 247 describes a system for controlling the distribution and use of digital content based on digital tickets. The "digital ticket" entitles its holder to exercise certain rights of use in relation to digital materials. Usage rights determine how a given digital material may be used or distributed. Within each entitlement, you can specify which digital ticket you must have before you can exercise that entitlement. Digital content is stored in repositories, which enforce compliance with usage rights whenever any other repository requests access to content. Each depot has a "general ticket controller" that clears tickets. In some cases, such a general controller is quite sufficient. In others, it may be required to delete the ticket by a 'special ticket controller' located in another store.

[0012] Digital Management Rights, version 1.0-5 September 2002, document Open Mobile Alliance - OMA-Download-DRM-v1_025 20020905-C is an introduction to digital rights management techniques, especially in the aspect of downloading multimedia objects using Wireless Application Protocol.

[0013] The present invention provides a method of freely transferring and sharing entitlement objects (OUs) necessary for viewing specific content between users.

[0014] According to a first aspect of the invention, a method is provided for sharing rights objects associated with content, comprising: creating on the backup server to which a wired or wireless connection is established, a backup of the rights object owned by the first user, where the rights object is issued by the rights issuer or received from another user;

the first user connects to the backup server and creates a permission object for the second user, within the limits imposed by the permission object stored on the backup server; and forwarding the backup server address so that the second user can download the permission object created on the backup server.

[0015] Creating user OU backups on the backup server ensures their very quick recovery in the event of the loss or failure of a portable terminal, it can also reduce the terminal's computational load.

[0016] Preferably, the method also includes encrypting the created authorization object using the second user's public key on the backup server, before the backup server's address is sent to the second user by the first user.

[0017] Preferably, the method also includes sending by the first and second users information about the restrictions of their rights objects to the rights issuer at specified time intervals.

[0018] Preferably, the method also includes electronically signing the created authorization objects using the first user's private key on the backup server, before the backup server's address is sent to the second user by the first user.

[0019] Preferably, the method also comprises encrypting the rights object with the second user's public key before sending the rights object to the second user.

[0020] For a better understanding of the invention and to show how to implement its various forms, it is exemplified in the accompanying schematic drawings in which:

Figure 1 shows a conventional method of distributing content in a manner compatible with the digital rights management mechanism (DRM).

Figure 2 shows how to create and distribute the rights object (OU) necessary to play DRM protected content.

Figure 3A illustrates the format of the OU document shown in figure 2.

Figure 3B illustrates the structure of the OU document shown in figure 2.

Figure 4A shows the formats of OU documents created by modifying the OU for other users.

Figure 4B shows the structures of OU documents created by modifying the OU for other users.

Figure 5 illustrates the method for creating, distributing and managing ROs necessary for playing DRM protected content.

Figure 6 shows a method of creating and distributing ROs necessary for playing DRM protected content in accordance with one embodiment of the invention.

[0021] In the following, preferred embodiments of the invention are described in detail with reference to the accompanying drawings.

[0022] Figure 2 shows a method of creating and distributing a rights object (OU) needed to play DRM protected content.

[0023] As can be seen in figure 2, the first user 201 has the authority object (OU) issued by the authority issuer. The OU owned by the first user 201 gives permissions to play encrypted material a predetermined number of times. In the non-limiting example shown, the permissions may allow encrypted content to be played up to 10 times.

[0024] When the first user 201 shares the RO containing play permission with friends, i.e. with the second user 202 and the third user 203, the second and third users, 202 and 203, gain the right to play the encrypted content. The first user 201 creates OU, giving permission to play content 5 and 3 times, based on OU, granting the right to play content 10 times. As a result, the first user 201 will have the right to play the material twice. Created

The ROs will be transferred to the second user 202 and the third user 203, respectively. In the preferred form, the ROs giving the rights to play content 5 and 3 times are encrypted using the recipient's public keys (second user 202 and third user 203), and then transferred to those second and third, 202 and 203, who in turn decrypt the received OU using their private keys. Transmitting encrypted OUs protects them against unauthorized use by other people. Preferably, OUs sent are electronically signed using the sender's private key (first user 201), which prevents them from falsification, illegal access and denial of transmission on the sender's side.

[0025] When the third user 203 likes the result of playing the encrypted content using the OU received from the first user 201, the third user 203 creates the OU allowing one-time playback based on the OU, allowing the content to be played twice and forwards the created OU to the fourth user 204. Before sending OU, it must be electronically signed and encrypted.

[0026] The ROs of the invention are not limited to the number of plays, but may also include playing time. In this case, each newly created RO is obtained by dividing the reproduction time into several parts, which is part of the present invention.

[0027] Figures 3A and 3B show the document format and structure of the OU shown in figure 2. According to figure 3A, the element <rights> comprises <uid> and <KeyValue>, which specify the content identifier (cid) of the OU and the key value, respectively, which is the encrypted content. The <permission> element contains various permissions: <play>, <copy> and <move>, for playing, copying and moving content, respectively, each limited by the <constraint> element. For example, the <constraint> element for permission <play> could be <count>, specifying how many times the content can be played, <duration>, specifying how long the content can be played, or <datetime>, which specifies the date or date and time after which the permission <play> expires. In figure 3A, the <constraint> element defines the playback limit to 10 times.

[0028] Figure 3B illustrates an exemplary structure of an OU document. According to figure 3B,

The OU contains restrictions, metadata, permits and the issuer's signature. The restrictions include the OU ID and key value, and the metadata contain information about the OU version and issuer. Permits include the ability to play, copy and move content, and the issuer's signature identifies the issuing entity

OU.

[0029] Figures 4A and 4B show document formats and structures of an RO created after modification of the RO for other users. According to figure 4B, user A has an OU issued to the respective issuer of allowances. Based on the permits defined in the RO, which are reproduction rights up to 10 times, user A creates the RO with the right to play the corresponding content 5 times, to forward the created RO to user B. In this case, in addition to the OU issued by the issuer of permissions, user A creates an OU representing the tenfold reproduction rights and the right to transfer the fivefold reproduction rights to demonstrate modifications made by user A during the subsequent periodic communication with the issuer. The modified OU metadata indicates that an OU has been created for user B and the permissions specify that the right to play five times has been transferred. Finally, user A leaves his signature in the appropriate column, certifying that he has personally modified it. On the other hand, the metadata of the OU created for user B specifies that the OU was received from user A, and the permissions allow it to be replayed five times. Finally, a signature is created indicating that the OU was created by user A. The OU created for user B is forwarded to user B and the content is reproduced within the limits of the permissions defined in the OU.

[0030] Figure 4A shows the OU document formats created for user B, as shown in figure 4B, and the modified user OU. The modified OU includes a new authorization <move>, specifying the transfer of the five-time playback rights, user A's signature and other information. The OU created for user B contains five-time restore permissions, the signature of user A and other information.

[0031] Figure 5 illustrates the process for creating, disseminating and managing an RO that is not needed to play content protected by a digital rights management (DRM) mechanism.

[0032] The first user 501 has OU giving the right to play the content ten times. The first user 501 creates two ROs, giving the right to play five and three times, and transfers them to the second user 502 and the third user 503, respectively. As a result, the remaining RO 50U has the right to play the content twice. When the third user 503 creates a RO that gives once playing rights and transfers it to the fourth user 504, the remaining RO that is held by the third user 503 includes the right to play the content twice.

[0033] However, the first user 501 or the third user 503 may create an RO that exceeds the playback permission restrictions defined in the RO that they own, or send a legally created RO to multiple users simultaneously, e.g., intentionally maliciously modifying the software. To prevent such unauthorized use of users' OUs, the OU must be sent to the issuer 500 allowances at regular intervals. For example, users can send their publisher OU 500 allowances after each OU is created or at regular intervals (e.g. weekly or every 15 days).

[0034] When the OU is sent after a long time, there may be a discrepancy between the restrictions defined in each user's OU and the restrictions in the OU of the issuer's rights. The frequency of these discrepancies is closely related to the length of the period after which OUs are sent to the issuer 500 allowances. As this period extends, the load on the connections decreases, but at the same time the risk of divergence increases. As this period is shortened, the load on the connections increases and at the same time the risk of divergence decreases.

[0035] It is preferred to encrypt the RO created by the recipient's public key. Each user can pass on encrypted content, its address or URL indicating its location to other users, along with the OU associated with the content.

[0036] Figure 6 illustrates a method for creating and disseminating RO, necessary for reproducing DRM protected content, according to an embodiment of the present invention. The first user 601 can store the RO issued by the rights issuer on a backup server 640, wired or wirelessly connected.

As described previously with reference to Figures 2 and 5, the first user 601 may directly create an OU and transfer the OU to the second user 602 and the third user 603. However, in the form shown, the backup server 640 creates the OU for transmission to the second user 602 and the third user 603, to reduce the excessive load on calculations necessary for electronic signing and encryption. This means that the backup server 640 creates the appropriate ROs for the second user 602 and the third user 603 based on the stored RO of the first user 601. The created ROs are then electronically signed and encrypted. Backup server 640 receives the private key of the first user 601 for digital signature, and the public keys of the second user 602 and the third user 603 for encryption from the respective users 601-603 and electronically signs and encrypts each RO with these keys.

[0037] Meanwhile, the first user 601 passes the address or URL of the backup server 640 to the second user 602 and the third user 603, so that users 602 and 603 will be able to download the created RO from the backup server 640. The first user 601 does not necessarily need to provide the address of the backup server 640, but instead may receive from the 640 backup server OU intended for the second user 602 and the third 603, and then send it to the second user 602 and the third 603, respectively.

[0038] Second user 602 and third user 603 may directly use the received OUs or place copies thereof on the backup server 640, like the first user 601. The third user 603 may create an OU for the fourth user

604 via a 640 backup server, within the limits imposed by the OU that it owns.

[0039] Since the first user 601 has already exercised his playback rights 8 times out of 10 possible, he still has the right to play the encrypted content twice. When the first user 601 plays the content, a copy of the information that he has the right to play the material twice will be on the server

640 backups, while the first 601 user has the right to restore only once. This discrepancy can be eliminated by automatically creating a copy of the first user 601 restore count information on the 640 backup server when the first user 601 accesses the 640 backup server and there is a discrepancy in the number of restorations.

In preferred embodiments of the invention, users have the right to share their ROs to other users, within the limits defined in the RO, without being authenticated by the server.

[0041] Furthermore, preferred embodiments of the invention can ensure the safe use of purchased ROs, with the participation of a backup server on which copies of these ROs are placed. When the amount of available memory or terminal processor power is insufficient to create an OU, preferred embodiments of the invention allow this problem to be resolved via the backup server.

[0042] Although only a few preferred embodiments are described and described herein, those skilled in the art understand that various changes and modifications can be made without departing from the scope of the invention as defined in the appended claims.