Abstract: A digital rights management (DRM) system distributes the storage of rights and/or the rights management decision making process between a DRM client and a DRM server, in order to overcome the shortcomings inherent in exclusively client-side or exclusively server-side DRM systems.

Abstract: A digital rights management (DRM) “bureau” server can be used in many different ways. In one example, a system distributes the storage of rights and/or the rights management decision making process between a DRM client and a DRM server, in order to overcome the shortcomings inherent in exclusively client-side or exclusively server-side DRM systems. In another example, a system manages rights to content on behalf of plural publishers.

Abstract: Digital rights (110) are associated with a semi-unique node identifier obtained or calculated from characteristics of a mobile device (302) attached to a consumer device, rather than with the node identifier of the consumer device itself (106, 206). The user of the consumer device (106, 206) may access the digital rights management encrypted content (which may come from local persistent storage or a network) by attaching the mobile device (302) to the consumer device (106, 206). In this way, the rights can be associated with the node identifier of the mobile device (302), and the rights are thus usable for the consumer device to access the encrypted content.

Abstract: A method of protecting Java bytecode is provided that includes the steps of encrypting at least one Java class file to produce at least one encrypted Java class file (414a) which is archived in an archive (414). A Java application that depends on the encrypted Java archive (414) is configured to run by first loading an application stub class (414b) and calling an entry point within the application stub class (414b). A method is provided of running a Java application that uses such a previously encrypted Java archive (414). The method includes the steps of loading an application stub class (414b). An entry point within the application stub class (414b) is called thereby to call a secure class loader to enable the at least one encrypted Java class file (414a) to be loaded from the archive (414) and decrypted.