WO2015079004A1

WO2015079004A1 - Method and apparatus for supporting verification of a contract

Info

Publication number: WO2015079004A1
Application number: PCT/EP2014/075893
Authority: WO
Inventors: Jie Gu; Xin Ge; Jin Qu; Changjie Wang; Cheng Wang
Original assignee: Koninklijke Philips N.V.
Priority date: 2013-11-29
Filing date: 2014-11-28
Publication date: 2015-06-04

Abstract

The embodiments disclose a method and a network device for supporting verification of a contract signed between a first party and a second party. The method comprises receiving contract information of the contract; communicating with a first user device of the first party and a second user device of the second party to confirm validity of the contract information; receiving a request of a third user device of a third party for supporting the verification of the contract; encrypting the contract information into a permission token with a private key of the network device; adding the permission token and the contract information to a licence associated with the contract; and sending the licence to the third user device for verification.

Description

METHOD AND APPARATUS FOR SUPPORTING VERIFICATION OF A CONTRACT

TECHNICAL FIELD

The present technology relates to the field of digital rights management (DRM), particularly to a method of supporting verification of a contract signed between a first party and a second party with respect to DRM. The technology also relates to a device and a computer readable storage medium for performing the method.

BACKGROUND

In the field of DRM, such as electronic books (e-books), there is a business model according to which the content provider of an e-book will provide the e-book to a content distributor and then the content provider provides the content to customers or other content distributors. The content distributor may sign a buyout contract with the content provider, that is to say, the content distributor makes a deal with the content provider to let her/him sell the e-book exclusively. In this case, the content provider cannot authorize other content distributors to sell this e-book, and only this content distributor can sell it. It is possible that the content provider violates the buyout contract and sells the already bought out e-book to other content distributors. Conventionally, the buy-out content distributor has to collect evidence and retrospect passively after the content provider has already violated the buyout contract. Such a solution is inefficient and may lead to a loss of time and money.

US2005108556 discloses a digital rights management system for the distribution, protection and use of electronic content. The system includes a client architecture which receives content, where the content is preferably protected by encryption and may include a license and individualization features. Content is protected at several levels, including: no protection; source-sealed; individually-sealed (or "inscribed"); source-signed; and

fully- individualized (or "owner exclusive"). US2005108556 fails to point out the buyout issue described above and does not disclose any possible solutions.

WO 99/57847 discloses methods and apparatus which are provided that implement digital signing and/or encryption for the electronic transmission, storage and retrieval of authenticated documents and that enable the establishment of the identity of the originator of an electronic document and of the integrity of the information contained in such a document.

SUMMARY

Based on the understanding of the technical problems and prior art described above, it would be desirable to proactively verify the contract signed between the content provider and the content distributor to ensure that both of them don't violate the contract.

A first aspect of the present disclosure is a method in a network device for supporting a verification of a contract signed between a first party and a second party. The method comprises receiving contract information of the contract; communicating with a first user device of the first party and a second user device of the second party to confirm validity of the contract information; receiving a request of a third user device of a third party for supporting the verification of the contract; encrypting the contract information into a permission token with a private key of the network device; adding the permission token and the contract information to a licence associated with the contract; and sending the licence to the third user device for verification.

A second aspect of the present disclosure is a method in a third user device for verifying a contract signed between a first party and a second party. The method comprises sending a request for supporting a verification of the contract to a second user device of the second party; receiving a licence associated with the contract from a network device, the licence including a permission token and contract information, the permission token being generated by performing encryption on the contract information; and verifying the contract based on the permission token and the contract information.

A third aspect of the present disclosure is a network device configured to support a verification of a contract signed between a first party and a second party. The network device comprises a first receiving unit, a communicating unit, a second receiving unit, an encrypting unit, an adding unit and a first sending unit. The first receiving unit is adapted to receive contract information of the contract. The communicating unit is adapted to communicate with a first user device of the first party and a second user device of the second party to confirm validity of the contract information. The second receiving unit is adapted to receive a request of a third user device of a third party for supporting the verification of the contract. The encrypting unit is adapted to encrypt the contract information into a permission token with a private key of the network device. The adding unit is adapted to add the permission token and the contract information to a licence associated with the contract. The first sending unit is adapted to send the licence to the third user device for verification.

A fourth aspect of the present disclosure is a third user device configured to verify a contract signed between a first party and a second party. The third user device comprises a second sending unit, a third receiving unit and a verifying unit. The second sending unit is adapted to send a request for supporting a verification of the contract to a second user device of a second party. The third receiving unit is adapted to receive a licence associated with the contract from the network device; the licence includes a permission token and contract information, the permission token is generated by performing encryption on the contract information. The verifying unit is adapted to verify the contract based on the permission token and the contract information.

A fifth aspect of the present disclosure is a system configured to verify a contract. The system comprises a network device and a third user device as described above.

In the embodiments above, a network device is introduced to maintain the contract information of a contract signed between the first party and the second party, which involves confirming the validity of the contract information with the first party and the second party.

When receiving the request for supporting the verification of the contract, the network device can provide the contract information in a safe way. Specifically, the network device may add the contract information and the permission token containing the encrypted contract information to the licence associated with the contract and send the licence to the requestor for verification. In this way, the requestor may readily and correctly verify the contract whenever needed, which may effectively prevent any party of the contract from violating it .

BRIEF DESCRIPTION OF THE DRAWINGS

The technology will now be described, by way of example, based on embodiments with reference to the accompanying drawings, wherein:

Fig.l illustrates a schematic networking environment suitable for implementing the embodiments in the present disclosure;

Fig.2 schematically illustrates a flowchart of supporting a verification of a contract in accordance with an embodiment;

Fig.3 schematically illustrates a flowchart of verifying a contract in accordance with an embodiment;

Fig.4 schematically illustrates a block diagram of a network device configured to support a verification of a contract in accordance with an embodiment; and

Fig.5 schematically illustrates a block diagram of a third user device configured to verify a contract in accordance with an embodiment. DETAILED DESCRIPTION

Embodiments herein will be described more fully hereinafter with reference to the accompanying drawings. The embodiments herein may, however, be embodied in many different forms and should not be construed as limiting the scope of the appended claims. The elements of the drawings are not necessarily to scale relative to each other. Like numbers refer to like elements throughout.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" "comprising," "includes" and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

The present technology is described below with reference to block diagrams and/or flowchart illustrations of methods, apparatus (systems) and/or computer programs according to the present embodiments. It is understood that blocks of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by computer program instructions. These computer program instructions may be provided to a processor, controller or controlling unit of a general purpose computer, special purpose computer, and/or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed via the processor of the computer and/or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.

Accordingly, the present technology may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.). Furthermore, the present technology may take the form of a computer program on a computer-usable or computer-readable storage medium having a computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable storage medium may be any medium that may contain, store, or is adapted to communicate the program for use by or in connection with the instruction execution system, apparatus, or device.

Embodiments herein will be described below with reference to the drawings.

Fig.l illustrates a schematic networking environment suitable for implementing the embodiments.

As illustrated in the Fig. l, the networking environment comprises a network device 100, a first user device 140, a second user device 150 and a third user device 160. These devices may communicate with each other in a wired or wireless way. The first user device 140 is used by the first party, the second user device 150 is used by the second party, and the third user device 160 is used by the third party.

Here, the "network device" may be, but is not limited to, a network mainframe, a single network server, a cloud built on a set of network servers. The "user device" may be, but is not limited to, an electronic device that can interact with the user through a keyboard, mouse, touch pad, etc and communicate with the network device, such as a personal computer, tablet, etc. In addition, the user device may also operate as a server such as a lightweight network server that can communicate with the network device.

For purpose of explanation, the embodiments herein will be described in the exemplary scenario of an e-book. In the embodiments, the network device may act as a DRM server, the first party may act as a content provider of the e-book, the second party may act as a buyout content distributor, and the third party may act as a subordinate content distributor or a consumer. In the case that the third party is a consumer, the third user device 160 used by the third party can be the personal computer of the consumer.

Taking the e-book as an example, the first party (i.e. the content provider) and the second party (i.e. the content distributor) may sign a buyout contract to let the second party sell one or more kinds of e-books exclusively. Then a third party (i.e. the subordinate content distributor) may want to sign a contract with the second party (i.e. the content distributor) involving the selling of the e-books that the second party obtains from the first party exclusively. In this case, it would be desirable for the third party to verify the buyout contract signed between the first party and the second party readily and accurately before signing a contract with the second party.

Fig.2 schematically illustrates a flowchart for the network device to support a verification of a contract in accordance with an embodiment. Fig.3 schematically illustrates a flowchart for a third user device to verify a contract in accordance with the embodiment. Now the process of the embodiment will be described with reference to Fig. l, Fig.2 and Fig.3.

In step 210, the network device 100 receives contract information of the contract signed between the first party and the second party. The contract information may be received from the first user device 140 used by the first party or the second user device 150 used by the second party. Here, the contract information may comprise, but is not limited to, an identity of the first party, an identity of the second party and an identity of the object of the contract. The object of the contract refers to the content that the first party provides to the second party as agreed in the contract. In this example, the object of the contract is the e-book. The object of the contract can also be video, audio content or other kinds of content. Here, the identity of the individual item in the contract information can be represented in any way that can uniquely identify the individual item, such as the name of the item, the serial number of the item or the like.

In step 220, the network device 100 communicates with the first user device 140 of the first party and a second user device 150 of the second party to confirm validity of the contract information.

In an embodiment, the network device 100 may request each of the first user device 140 and the second user device 150 to digitally sign on the contract information with their own private key. In response to the request, the first user device 140 may digitally sign on the identity of the first user device 140 and the identity of the e-book with it private key. Likewise, the second user device 150 may digitally sign on the identity of the second user device 150 and the identity of the same e-book. As is known, a digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, such that the sender cannot deny having sent the message (authentication and non-repudiation) and that the message was not altered in transit (integrity). Herein, the digital signature can be implemented in any suitable way known in the art, which will not be discussed in more detail for purpose of brevity. After receiving the signatures from the first user device 140 and the second user device 150, the network device 100 may validate the signatures with the corresponding public keys. If these signatures are valid, the network device 100 may determine that the contract information of the contract is valid.

In another embodiment, the network device 100 may request the first user device 140 to digitally sign on all the items in the contract information, including an identity of the first party, an identity of the second party and an identity of the object of the contract. In response to the request, the first user device 140 digitally signs them on and sends the contract information with digital signature back to the network device 100. Then, the network device 100 may receive the contract information with the digital signature of the first user device 140 and forward the received contract information to the second user device 150. Upon receiving this contract information, the second user device 150 may first validate the digital signature of the first user device 140 with the public key of the first user device 140. After validation, the second user device 150 may also digitally sign on the contract information. Now, this contract information is digitally signed by both the first user device 140 and the second user device 150. Finally, the second user device 150 sends the contract information signed by both the first user device 140 and the second user device 150 to the network device 100. This enables the network device 100 to validate these digital signatures with the respective public keys. By this means, all items in the contract information have been confirmed by both the first user device 140 and the second user device 150, thus the credibility of the contract information is further improved. In this way, an independent network device is set up to maintain the contract information and ensure the credibility of the contract information, such that the network device may provide credible contract information to other user devices for verifying the contract associated with the contract information. It will be appreciated that the network device may also maintain contract information of other contracts signed between other entities.

In step 310, the third user device 160 sends a request for supporting a verification of the contract to the second user device 150 of the second party.

Specifically, when the third party is a subordinate content distributor, the third party would like to make a deal with the second party to sell the e-book that the second party has obtained from the first party. When the third party is a consumer, the third party may want to purchase the e-book from the second party. In cases such as this, the third party may need to verify the contract signed between the first party and the second party, therefore, the third user device 160 used by the third party may send a request for supporting the verification of the contract involving the e-book to the second user device 150 used by the second party. After receiving the request, the second user device 150 may delegate the request to the network device 100. In other words, the second user device 150 doesn't process this request itself, but asks the network device 100 to process this request. As indicated, the request for supporting verification of the contract is not sent to the network device 100 directly, but relayed to the network device 100 by the second user device 150. In this way, the network device 100 may determine that the second user device 150 knows about this request from the third user device 160 and allows the third user device 160 to inquire about the contract information of the contract.

Alternatively, it is also possible that the third user device 160 directly sends the request for supporting a verification of the contract to the network device 100.

In step 230, the network device 100 receives the request of the third user device 160 of a third party for supporting the verification of the contract. Specifically, the network device 100 may receive the request from the second user device 150. Alternatively, the network device 100 may also receive the request from the third user device 160 directly.

In step 240, the network device 100 encrypts the contract information of the contract into a permission token with the private key of the network device 100. Specifically, after receiving the request for supporting the verification of the contract, the network device 100 may, for example, retrieve the contract information of the contract from the local or remote storage. Then, the network device 100 may encrypt the contract information with its own private key, and the encrypted contract information is the permission token of the contract. Alternatively, the network device 100 may also first hash the contract information to obtain hash value of the contract information and then encrypt the hash value with its own private key. In this case, the encrypted hash value is the permission token of the contract. This alternative encrypting process will be discussed in more detail later.

In step 250, the network device 100 adds the permission token and the contract information to a licence associated with the contract.

In an embodiment, when the network device 100 is a DRM server, the licence can be Marlin DRM licence which is a file in Extensive Makeup Language (XML) format. The network device 100 may create new tags for the permission token and the contract information in the XML file, and insert them into the licence with the tags as illustrated below:

<DRMserver>TWFybGluIERSTSBzZXJ2ZXI=</DRMserver>

<ContentProvider>aHR0cDovL3 d3 dy5uZXd3b3 JsZC 1 wcmVzcy5jb20=

</ ContentPro vider> <ContentDistributor>aHR0cDovL3 d3 dy5kYW5nZGFuZy5jb20=

</ ContentDistributor>

<ContentID>RHJlYW0gb2YgdGhlIFJlZCBDaGFtYmVy</ContentID>

</ContractInfo>

<PermissionToken>GFJyhJmujPXOAY2crOc4IPmFy2WA15YKl+gwYXF7A"CP6a0 U0ykHJ7HdxdSSCe+eWEofuPPdx8rVpglFds0E9xMEAFK0EnZMMJhNYVxbK7+v9jR/reJ 3g524HeKrlsBv4C2F7owfVZOJeEa8/T6AhWFcZ3kuQq+yWr9is4zc2k0=

</PermissionToken>

</Buyout>

In this example, the tag <ContractInfo> is used to accommodate the contract information, while the sub tags <DRMserver>, <ContentProvider>, <ContentDistributor> and <ContentID> respectively represent ID of the network device, ID of the first party, ID of the second party and ID of the e-book. As indicated, before inserting the individual items of the contract information into the licence, the network device 100 encodes the individual items with a base64 encoding scheme. As is well known in the art, Base64 is commonly used for storing complex data in XML, which can help reduce the size of the XML file, thereby saving the network traffic for transmitting the XML file. Moreover, the tag <PermissionToken> is used to represent the permission token, i.e. the encrypted contract information.

Alternatively, instead of being encoded with the base64 encoding scheme, the individual items of the contract information can be directly inserted into the license.

Here, the license is illustrated as a XML file by way of example; it should be appreciated that the license may be represented by other types of structured/semi-structured document in plain text or binary text format.

In step 260, the network device 100 sends the licence to the third user device 160.

Specifically, the network device 100 may obtain the address of the third user device 160 from the request of the third user device 160, and send the licence including the contract information and the permission token to the third user device 160. Alternatively, if the network device 100 receives the request of the third user device 160 from the second user device 150, the network device 100 may request the second user device 160 to provide the address of the third user device 160. Upon receiving the address of the third user device 160, the network device 100 may send the licence to the third user device 160 in terms of this address.

In step 320, the third user device 160 receives the licence associated with the contract from the network device 100.

In step 330, the third user device 160 verifies the contract based on the permission token and the contract information in the licence.

In an embodiment, the third user device 160 may parse the XML file of the licence and retrieve the contract information and the permission token, decrypt the permission token with the public key of the network device 100 to obtain the decrypted contract information, and then verify the contract by comparing the decrypted contract information with the contract information directly retrieved from the licence. If they match with each other, then the network device 100 may determine that the contract signed between the first party and the second party is true and valid.

Alternatively, if the permission token is the encrypted hash value of the contract information, instead of the encrypted contract information, the third user device 160 may compute a hash value of the contract information retrieved from the licence, and compare this hash value with the hash value decrypted from the permission token to verify the contract. This alternative verifying process will be described in detail later.

As described, when receiving the request for supporting the verification of the contract, the network device may provide the contract information in a safe way. Specifically, the network device may add the contract information and the permission token containing the encrypted contract information to the licence associated with the contract and send the licence to the requestor for verification. In this way, the requestor may readily and correctly verify the contract whenever needed, which may effectively prevent any party of the contract from violating it.

Optionally, before delegating the request of the third user device 160 for supporting verification of the contract, the second user device 150 may further confirm the validity of the request among the parties involved such as the third user device 160 and the network device

100. Specifically, in response to the third user device 160 sending a request for supporting a verification of the contract to the second user device 150, the second user device 150 may generate an action token which can be a random number for example, and send the action token to the third user device 160. Upon receiving the action token from the second user device 150, the third user device 160 may send the action token to the network device 100.

After receiving the action token from the third user device 160, the network device 100 may send the action token back to the second user device 150. If the second user device 150 determines that the received action token is equal to the original action token that it sent to the third user device 160, it will delegate the request of the third user 160 to the network device 100, such that the network device can process the request. Through circulating the action token among the network device 100, the second user device 150 and the third user device 160, the network device 100 can further make sure that the third user device 160 indeed sends such a request.

Optionally, in order to facilitate the comparison between the contract information and the decrypted contract information to verify the contract on the side of third user device 160, during encrypting the contract information, the network device 100 may compute a hash value of the contract information using a predetermined hash function, and then encrypt the hash value with the private key of the network device to generate the permission token. As such, when obtaining the contract information and the permission token, the third user device 160 may decrypt the permission token with the public key of the network device to obtain a first hash value, hash the obtained contract information with the same hash function to obtain a second hash value, and then compare the first hash value with the second hash value to verify the contract.

Here, the hash function may be, but is not limited to, a Bernstein hash, Jenkins hash function, Pearson hashing and Zobrist hashing. As is known in the art, hash functions are primarily used to generate fixed-length output data that acts as a shortened reference to the original data. In this way, the third user device doesn't have to care about the specific content in contract information when performing a comparison; rather, it can readily verify the contract by comparing the hash values.

Optionally, when the second user device 150 delegates the request of the third user device 160 to the network device 100, it may also send a content key to the network device 100 . Here, the content key is the key to decrypt the e-book encrypted by the second user device 150. In this case, the network device 100 may forward the content key to the third user device 160 by adding the content key to the licence. As such, the third user device 160 may use the content key to decrypt the encrypted e-book provided by the second user device 150. Alternatively, the second user device may encrypt the content key with the public key of the network device 100 and then send the encrypted content key to the network device 100.

Optionally, in order to verify the contract more accurately, the contract information may further comprise duration of the contract, geographical scope constrained by the contract, and the like. The duration of the contract may indicate the beginning and ending dates of the contract. The geographical scope constrained by the contract may indicate the geographical regions designated in the contract, in which regions the second party may exclusively sell the e-books provided by the first party.

Fig.4 schematically illustrates a block diagram of a network device 400 configured to support a verification of a contract in accordance with an embodiment. As shown, the network device 400 comprises a first receiving unit 410, a communicating unit 420, a second receiving unit 430, an encrypting unit 440, an adding unit 450 and a first sending unit 460. Fig.5 schematically illustrates a block diagram of a third user device 500 configured to verify a contract in accordance with an embodiment. As illustrated, the third user device 500 comprises a second sending unit 510, a third receiving unit 520 and a verifying unit 530.

It should be appreciated that the network device 400 and the third user device 500 are not limited to comprising the shown elements, and can comprise other conventional elements and the additional elements for other purposes. Here, the network device 400 acts as the network device 100 in Fig.l, the third user device 500 acts as the third user device 160. Now, by describing the collaboration between the network device 400 and the third user device 500, the functions of the individual units in the network device 400 and the third user device 500 will be described.

The first receiving unit 410 of the network device 400 receives contract information of the contract signed between the first party and the second party. The contract information may be received from the first user device 140 used by the first party or the second user device 150 used by the second party. Here, the contract information may comprise, but is not limited to, an identity of the first party, an identity of the second party and an identity of the object of the contract. The object of the contract refers to the content that the first party provides to the second party as agreed in the contract. In this example, the object of the contract is the e-book.

The communicating unit 420 of the network device 400 communicates with the first user device 140 of the first party and a second user device 150 of the second party to confirm validity of the contract information. For example, the communicating unit 420 may request each of the first user device 140 and the second user device 150 to digitally sign on the contract information with their own private key. In response to the request, the first user device 140 may digitally sign on the identity of the first user device 140 and the identity of the e-book with its private key. Likewise, the second user device 150 may digitally sign on the identity of the second user device 150 and the identity of the same e-book. After receiving the signatures from the first user device 140 and the second user device 150, the

communicating unit 420 may validate the signatures with the corresponding public keys. If these signatures are valid, the communicating unit 420 may determine that the contract information of the contract is valid.

In this way, an independent network device is set up to maintain the contract

information and ensure the credibility of the contract information, such that the network device may provide credible contract information to other user devices for verifying the contract associated with the contract information.. It will be appreciated that the network device may also maintain contract information of other contracts signed between other entities.

The second sending unit 510 of the third user device 500 sends a request for supporting a verification of the contract to the second user device 150 of the second party. Specifically, when the third party is a subordinate content distributor, the third party would like to make a deal with the second party to sell the e-book that the second party obtained from the first party. When the third party is a consumer, the third party may want to purchase the e-book from the second party. In these cases, the third party may need to verify the contract signed between the first party and the second party; therefore, the third user device 500 used by the third party may send a request for supporting the verification of the contract involving the e-book to the second user device 150 used by the second party. After receiving the request, the second user device 150 may delegate the request to the network device 400. In other words, the second user device 150 doesn't process this request itself, but asks the network device 400 to process this request. As indicated, the request for supporting verification of the contract is not sent to the network device 400 directly, but relayed to the network device 400 by the second user device 150. In this way, the network device 400 may determine that the second user device 150 knows about this request from the third user device 500 and allows the third user device 500 to inquire about the contract information of the contract.

Alternatively, the second sending unit 510 of the third user device 500 may directly send the request for supporting a verification of the contract to the network device 400.

The second receiving unit 430 of the network device 400 receives the request of the third user device 500 of a third party for supporting the verification of the contract. Specifically, the second receiving unit 430 may receive the request from the second user device 150. Alternatively, the network device 100 may also receive the request from the third user device 500 directly.

The encrypting unit 440 of the network device 400 encrypts the contract information of the contract into a permission token with the private key of the network device 400.

Specifically, after receiving the request for supporting the verification of the contract, the encrypting unit 440 may, for example, retrieve the contract information of the contract from the local or remote storage. Then, the encrypting unit 440 may encrypt the contract information with its own private key, and the encrypted contract information is the permission token of the contract. Alternatively, the encrypting unit 440 of the network device 400 may also first hash the contract information to obtain a hash value of the contract information and then encrypt the hash value with its own private key. In this case, the encrypted hash value is the permission token of the contract. This alternative encrypting process will be discussed in more detail later.

The adding unit 450 of the network device 400 adds the permission token and the contract information to a licence associated with the contract.

In an embodiment, when the network device 400 is a DRM server, the licence can be a Marlin DRM licence, which is a file in Extensive Makeup Language (XML) format. The adding unit 450 may create new tags for the permission token and the contract information in the XML file, and insert them into the licence with the tags as illustrated in the method embodiment as described above. In this example, the tag <ContractInfo> is used to

accommodate the contract information, while the sub tags <DRMserver>, <ContentProvider>, <ContentDistributor> and <ContentID> respectively represent ID of the network device, ID of the first party, ID of the second party and ID of the e-book. As indicated, before inserting the individual items of the contract information into the licence, the adding unit 450 encodes the individual items with a base64 encoding scheme. As is well known in the art, Base64 is commonly used for storing complex data in XML, which can help reduce the size of the XML file, thereby saving the network traffic for transmitting the XML file. Moreover, the tag <PermissionToken> is used to represent the permission token, i.e. the encrypted contract information.

The first sending unit 460 of the network device 400 sends the licence to the third user device 500. Specifically, the first sending unit 460 may obtain the address of the third user device 500 from the request of the third user device 500, and send the licence including the contract information and the permission token to the third user device 500.

The third receiving unit 520 of the third user device 500 receives the licence associated with the contract from the network device 400.

The verifying unit 530 of the third user device 500 verifies the contract based on the permission token and the contract information in the licence.

In an embodiment, the verifying unit 530 may parse the XML file of the licence and retrieve the contract information and the permission token, decrypt the permission token with the public key of the network device 400 to obtain the decrypted contract information, and then verify the contract by comparing the decrypted contract information with the contract information directly retrieved from the licence. If they match with each other, then the verifying unit 530 may determine that the contract signed between the first party and the second party is true and valid.

Alternatively, if the permission token is the encrypted hash value of the contract information, instead of the encrypted contract information, the verifying unit 530 may compute a hash value of the contract information retrieved from the licence, and compare this hash value with the hash value decrypted from the permission token to verify the contract. This alternative verifying process will be described in detail later.

Optionally, before delegating the request of the third user device 500 for supporting verification of the contract, the second user device 150 may further confirm the validity of the request among the parties involved such as the third user device 160 and the network device 100. Specifically, in response to the second sending unit 510 of the third user device 500 sending a request for supporting a verification of the contract to the second user device 150, the second user device 150 may generate an action token which can be a random number for example, and send the action token to the third user device 500. Upon receiving the action token from the second user device 150, the third user device 500 may send the action token to the network device 400. After receiving the action token from the third user device 500, the network device 400 may send the action token back to the second user device 150. If the second user device 150 determines that the received action token is equal to the original action token that it sent to the third user device 500, it will delegate the request of the third user 500 to the network device 400, such that the network device can process the request. Through circulating the action token among the network device 400, the second user device 150 and the third user device 500, the network device 400 can further make sure that the third user device 500 indeed sends such a request.

Optionally, in order to facilitate the comparison between the contract information and the decrypted contract information so as to verify the contract on the side of third user device 500, during encrypting the contract information, the encrypting unit 440 of the network device 400 may compute a hash value of the contract information using a predetermined hash function, and then encrypt the hash value with the private key of the network device to generate the permission token. As such, when obtaining the contract information and the permission token, the verifying unit 530 of the third user device 500 may decrypt the permission token with the public key of the network device to obtain a first hash value, hash the obtained contract information with the same hash function to obtain a second hash value, and then compare the first hash value with the second hash value to verify the contract.

Here, the hash function may be, but is not limited to, a Bernstein hash, Jenkins hash function, Pearson hashing and Zobrist hashing. As is known in the art, hash functions are primarily used to generate fixed-length output data that acts as a shortened reference to the original data. In this way, the third user device 500 doesn't have to care about the specific content in contract information when performing the comparison; rather, it can readily verify the contract by comparing the hash values.

Optionally, when the second user device 150 delegates the request of the third user device 500 to the network device 400, it may also send a content key to the network device 400 . Here, the content key is the key to decrypt the e-book encrypted by the second user device 150. In this case, the first sending unit 460 of the network device 400 may forward the content key to the third user device 500 by adding the content key to the licence. As such, the third user device 160 may use the content key to decrypt the encrypted e-book provided by the second user device 150. Alternatively, the second user device may encrypt the content key with the public key of the network device 100 and then send the encrypted content key to the network device 100.

While the embodiments have been illustrated and described herein, it will be

understood by those skilled in the art that various changes and modifications may be made, and any equivalents may be substituted for elements thereof without departing from the true scope of the present technology. In addition, many modifications may be made to adapt to a particular situation and the teaching herein without departing from its central scope.

Therefore, it is intended that the present embodiments not be limited to the particular embodiment disclosed as the best mode contemplated for carrying out the present technology, but that the present embodiments include all embodiments falling within the scope of the appended claims.

Claims

1. A method (200) for used in a network device (100, 400) for verifying a contract signed between a first party acting as a content provider and a second party acting as a content distributor in a digital rights management system, comprising:

receiving (210) contract information of the contract;

communicating (220) with a first user device (140) of the first party and a second user device (150) of the second party to confirm validity of the contract information;

receiving (230) a request of a third user device (160, 500) of a third party for supporting the verification of the contract;

encrypting (240) the contract information into a permission token with a private key of the network device (100, 400);

adding (250) the permission token and the contract information to a licence associated with the contract; and

sending (260) the licence to the third user device (160, 500) for verification.

2. The method of claim 1, wherein the receiving (230) the request of the third user device (160, 500) comprises receiving the request from the second user device (150).

3. The method of claim 1, wherein the encrypting (240) the contract information comprises computing a hash value of the contract information and encrypting the hash value with the private key of the network device (100, 400) to generate the permission token.

4. The method of claim 1, wherein the contract information comprises an identity of the first party, an identity of the second party, and an identity of the object of the contract.

5. The method of claim 4, wherein the contract information further comprises at least one of a duration of the contract, a geographical scope constrained by the contract.

6. A method (300) for used in a third user device (160, 500) for verifying a contract signed between a first party acting as a content provider and a second party acting as a content distributor in a digital rights management system, comprising:

sending (310) a request for supporting a verification of the contract to a second user device (150) of the second party; receiving (320) a licence associated with the contract from a network device (100, 400), the licence including a permission token and contract information of the contract, the permission token being generated by performing encryption on the contract information; and verifying (330) the contract based on the permission token and the contract information.

7. The method of claim 6, wherein the verifying the contract comprises:

decrypting the permission token with the public key of the network device (100, 400) to obtain a first hash value with respect to the contract information;

hashing the contract information to obtain a second hash value; and

comparing the first hash value with the second hash value to verify the contract.

8. A network device (400) configured to -verify a contract signed between a first party acting as a content provider and a second party acting as a content distributor in a digital rights management system, comprising:

a first receiving unit (410) adapted to receive contract information of the contract;

a communicating unit (420) adapted to communicate with a first user device (140) of the first party and a second user device (150) of the second party to confirm validity of the contract information;

a second receiving unit (430) adapted to receive a request of a third user device (160, 500) of a third party for supporting the verification of the contract;

an encrypting unit (440) adapted to encrypt the contract information into a permission token with a private key of the network device (400);

an adding unit (450) adapted to add the permission token and the contract information to a licence associated with the contract; and

a first sending unit (460) adapted to send the licence to the third user device (160, 500) for verification.

9. The network device of claim 8, wherein the second receiving unit (430) is adapted to receive the request from the second user device (150).

10. A third user device (500) configured to verify a contract signed between a first party acting as a content provider and a second party acting as a content distributor in a data rights management system, comprising: a second sending unit (510) adapted to send a request for supporting a verification of the contract to a second user device (150) of a second party;

a third receiving unit (520) adapted to receive a licence associated with the contract from the network device (100, 400), the licence including a permission token and contract information of the contract, the permission token being generated by performing encryption on the contract information.

a verifying unit (530) adapted to verify the contract based on the permission token and the contract information.

11. A system configured to verify a contract, comprising a network device (400) according to any one of the claims 8-9 and a third user device (500) according to claim 10.

12. A computer readable storage medium which stores instructions which, when run on a network device (100, 300), cause the network device (100, 300) to perform the steps of the method according to any one of the claims 1-5.

13. A computer readable storage medium which stores instructions which, when run on a third user device (160, 500), cause the third user device (160, 500) to perform the steps of the method according to any one of the claims 6-7.

14. A network device (100) configured to verify a buy-out contract signed between a first party acting as a content provider and a second party acting as a content distributor in a data rights management system, comprising a processor and a memory, said memory containing instructions executable by said processor, whereby said network device is operative to:

receive contract information of the contract ;

communicate with a first user device (140) of the first party and a second user device (150) of the second party to confirm validity of the contract information;

receive a request of a third user device (160) of a third party for supporting the verification of the contract;

encrypt the contract information into a permission token with a private key of the network device (100); add the permission token and the contract information to a licence associated with the contract; and

send the licence to the third user device (160) for verification.

15. A third user device (160) configured to verify a contract signed between a first party acting as a content provider and a second party acting as a content distributor in a data rights management system, comprising a processor and a memory, said memory containing instructions executable by said processor, whereby said third user device (160) is operative to: send a request for supporting a verification of a contract to a second user device (150) of the second party;

receive a licence associated with the contract from the network device (100), the licence including a permission token and a contract information, the permission token being generated by performing encryption on the contract information; and

verify the contract based on the permission token and the contract information.