1. Field of the Invention
The invention described herein relates to digital rights management.
2. Related Art
One of the long-standing problems in the software industry is that of piracy. A software developer creates a software package and, ideally, the software is used only by those parties who have purchased the software or who are otherwise authorized to use it. If the software is copied and used by others who are not authorized to use the software, the software developer may lose money.
Software piracy is traditionally controlled in part through a licensing arrangement. When a software package is purchased by a party, one or more licenses are granted to the buyer. Those who have a license may use the package. Those lacking a license generally cannot. Licensing is typically controlled by a central authority, such as the software developer. The developer makes a sale and issues one or more licenses with the software package. If a prospective customer wishes to purchase the software package, or if the customer has already purchased a package but wishes an additional license, the customer must deal with the software developer in seeking a license. This can be inconvenient. Under this arrangement there is only one source for software licenses. While a customer may go to a local distributor for hardware needs or other commodities, there may not be such an option in the case of software. Indeed, there may be only one source, nationally or internationally, for a software license.
In some cases, a software developer may have one or more intermediate software distributors. In such an arrangement, the intermediate distributor does not generate a software license. Rather, the distributor receives some number of licenses from the software developer and issues those licenses to parties receiving the software package. In this arrangement, the software developer loses a certain amount of control. The issuance of software licenses falls to the distributor, rather than the software developer itself. In the event that the developer chooses to give up such control to an intermediate distributor, security dictates that the intermediate distributor's actions fall under the control of some security policy. Ideally, the licenses would only be distributed to authorized parties, and would include, for example, only certain features that are authorized for use (e.g., purchased) by the licensees. This may not be the case where the intermediate distributor has the authority to distribute licenses. The intermediate distributor's enforcement of a security policy may be unreliable.
What is needed, therefore, is a system or method for software licensing, whereby a user has a local contact with which he may do business, while the ultimate software developer retains control over the licensing process, e.g., which parties receive a license, what features are granted to a specific licensee, and/or when a license expires. Moreover, the developer needs to be in a position to enforce a security policy regarding the software product.
The invention described herein is a system and method for the issuance of software licenses through a tiered structure, whereby a software license is issued from a software developer to an end user through one or more intermediate layers of distribution. The system and method for doing so enforces a predefined security policy. In an embodiment of the invention, the security policy is defined by the security developer. The security policy may, for example, address who may use the software package, how many users there may be, an expiration date for use of the software, and/or specific features that may or may not be used by a particular user. The software developer first issues a license template to the next intermediate layer of distribution. This may be a software distributor, who then specifies one or more restrictions on the use of the software. This is done by articulating these restrictions in the license template, effectively “filling in” some or all of the template. Any such embellishment of the software license template must be in accordance with the security policy. In the final transaction, a final distributor transmits a completed software license to a user. At no time can an intermediate distributor issue a license or template that is less restrictive than what is dictated by the security policy, or less restrictive than the template given to the distributor.
Further embodiments, features, and advantages of the present invention, as well as the structure and operation of the various embodiments of the present invention, are described below with reference to the accompanying figures.
A preferred embodiment of the present invention is now described with reference to the figures, where like reference numbers indicate identical or functionally similar elements. Also, in the figures, the left-most digit of each reference number corresponds to the figure in which the reference number is first used. While specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the relevant art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the invention. It will also be apparent to a person skilled in the relevant art that this invention can also be employed in a variety of other systems and applications.
The invention described herein is a system and method for the issuance of software licenses through a tiered structure, whereby a software license is issued from a software developer to an end user through one or more intermediate layers of distribution. The system and method for doing so enforces a predefined security policy. In an embodiment of the invention, the security policy is defined by the security developer. The security policy may, for example, address who may use the software package, how many users there may be, an expiration date for use of the software, and/or specific features of the software package that may or may not be used by a particular user. The software developer first issues a license template. The next intermediate layer of distribution may be represented by a software distributor, who “fills in” one or more fields of the license template. Any such modification of the software license template must be in accordance with the security policy. In the final transaction, a final distributor transmits a completed software license to a user. At no time can an intermediate distributor issue a license or template that is less restrictive than what is dictated by the security policy, or what is articulated in the received template.
The invention can be implemented as software, firmware, hardware, or any combination thereof.
An embodiment of the invention is illustrated generally in
Software license 137 is sent to end user 140. Generally, a software license is data denoting the usage rights and restrictions placed on a user with respect to the usage of a software package. Such data may be in the form of a file or other data structure. Receipt of such a license permits the recipient to use the software program according to the constraints specified in the license. Software license 137 may, in some circumstances, be sent to end user 140 in response to a request from end user 140. Note that in the illustrated embodiment, developer 130 uses license server 135 only after having received a separate license to use the server 135. This separate license is indicated as server license 125, and is passed to developer 130 from a server licensor 120. Also, server license 125 is passed from server licensor 120 to developer 130 in exchange for compensation, such as a monetary payment. Likewise, software license 137 is sent to end user 140 from developer 130 in exchange for compensation.
An alternative topology for the distribution of a software license is illustrated in
As before, note that in this embodiment of the invention, the developer 240 operates a license server 245 after having received a separate server license 230 from a server licensor 220. Note also that, as before, compensation is transferred between parties as part of the transactions. Here, end user 280 compensates distributor 260 for software license 270. In addition, distributor 260 compensates developer 240 for license template 250. Finally, developer 240 compensates server licensor 220 in exchange for having received server license 230.
Also, a license template such as license template 250 does not represent a complete license. In an embodiment of the invention, a complete, usable license is not produced by any layer of the topology except for the final distribution layer. In
For example, the security policy may dictate that the software being licensed not be used after Jan. 1, 2006. Such a restriction may be specified in license template 250. Alternatively, that particular restriction may not be addressed at all in license template 250. In either event, the software license ultimately generated by distributor 260 and license server 265 may state that the software package cannot be used after Jan. 1, 2006. Alternatively, the software license 270 may state that the software package may not be used after Jun. 1, 2005. In this way, the software license 270 may be more restrictive than the security policy. If this particular restriction is not specified in license template 250, license server 265 may complete software license 270, articulating that the software package not be used after Jun. 1, 2005. Alternatively, if license template 250 states that the software package is not to be used after Jan. 1, 2006, license server 265 may adjust that restriction to say that the software package may not be used after Jun. 1, 2005. Hence, the ultimate software license 270 may be more restrictive than the security policy, but it cannot generally be less restrictive than the security policy.
An example of a license template, such as template 250 sent from developer 240 to distributor 260, is shown below:
Note that the above license template identifies the sender, the publisher Acme, Inc., and the recipient, Software Distributing, Inc. Under the license terms, Software Distributing is authorized to distribute (“canDistribute”) and resell (“canResell”), and can license as many as 1000 ultimate licensees (“NumberOfKeys”), either directly or via one or more lower level distributor(s). The above license template also includes a digital signature, for purposes of authenticating the template to the recipient, Software Distributing, Inc.
The following illustrates an example of a partially completed license template based on the above template, as might be sent from the distributor to another distributor, such as an on-line store:
This template includes the information from the first template. It also identifies the sender, Software Distributing, Inc., and the recipient, OnLine Store, Inc. This license is more restrictive than the previous template. It indicates that OnLine Store can resell, but cannot otherwise distribute, and can grant no more that 100 licenses, for example. This gives OnLine Store the freedom to sell no more than 100 software packages. The above template also specifies that no more than five software packages can be sold to any given customer. Also, an expiration date of Dec. 31, 2008 is now specified, with a two-day grace period. This template also includes a digital signature for authentication of the sender.
The following illustrates an example of a completed license, as might be sent to an end user 280:
This completed license template includes the information from the second template above. It identifies the immediate licensor, OnLine Store, Inc., and the licensee, John Doe. This license is more restrictive than the previous template, e.g., the license expires at the end of 2006 instead of 2008, and Doe can neither resell nor distribute. Also, the license is limited to three users. Again, a digital signature is included to allow authentication of OnLine Store.
Note that in the examples above, each template includes information from the predecessor template, and each licensor adds its own license information at the end. In alternative embodiments of the invention, a license template may not include information from the predecessor template. A distributor, for example, may not want to reveal the terms of its license.
Another exemplary portion of a software license distribution topology is illustrated in
As discussed previously, a developer may operate a license server after having received a separate server license from a server licensor. In
Note that the invention can be implemented in any of the license distribution topologies of
The processing of an embodiment of the invention is illustrated in
In step 750, a determination is made as to whether the level above has an available licensed template that can be transferred to the current license server. If the server at the level above has a template available, the template is transferred, and in step 760, the current license server receives the license template from the level above. Such a template is referred to herein as an acquired license template. In step 770, constraint information may be added to the acquired license template, as described above. Note that in some implementations, constraint information may have already been added to the acquired license template prior to this point, e.g., at a previous level of distribution. Therefore, all necessary constraint information may already be present prior to step 770, making step 770 unnecessary. Alternatively, new constraint information may be added in step 770. Alternatively, existing constraint information already in the acquired license template may be modified to further constrain the conditions of use for the product being licensed. Any modification to the acquired license template in step 770 results in a modified license template. If and when the license server completes the template, the resulting modified license template represents the completed license.
If, in step 730, it is determined that the current license server has a previously acquired license template in hand, then the license server does not need to obtain a license template. Therefore, the process would continue at step 770. At step 780, the completed license is bound and sent to the end user. The process of binding and sending a license to an end user is described in greater detail below. The process concludes at step 790.
Note that when the license server requests a license template from the level above in step 740, the license server at the level above may not have any license templates available. In this case, the license server at the level above would then ask for a license template from the next successive level above. This process would continue until an available license template is found. At that point, the available license template would be sent down (and possibly modified at one or more intervening levels) until reaching the license server that initially requested the license template. If, in step 750, it is determined that there are no license templates available at any level above the requesting license server, then no license can be generated, and the process terminates. In an embodiment of the invention, a suitable error message would be sent to the requesting end user.
Step 780, the step of binding and sending a license to an end user, is illustrated in greater detail in
Note that the signature function 860 can be performed, in an embodiment of the invention, using public key photography. In this case, the signing function 860 would be performed using the private component of a public key pair. As will be described below, the end user would then apply the public component of that public key pair, for purposes of authenticating the license server.
If, in step 1030, the determination is made that the license server has no available license template and therefore needs a template, then the process continues at step 1040. Here, the license server requests a license template from the level above. In step 1050, a determination is made as to whether a license template is available to be sent to the license server. If so, a license template is sent from above to the license server, so that in step 1060, the license server acquires a license template. Again, in some implementations, constraint information may be added to the acquired license template, or existing constraint information may be modified in step 1065. In step 1070, the acquired and possibly modified license template is bound and sent to the level below. The process concludes at step 1080.
If, in step 1050, it is determined that there are no license templates are available from levels above, then the license server cannot send a license template to the requesting level below, and the process concludes. Note that, as discussed above with respect to
Step 1070, the step of binding and sending a license template to the requesting level below is illustrated in greater detail in
The processing performed at the requesting license server in response to receipt of the template is illustrated in
The present invention may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems. In one embodiment, the invention may comprise one or more computer systems capable of carrying out the functionality described herein. An example of a computer system 1300 is shown in
Computer system 1300 may include a display interface 1302 that may forward graphics, text, and other data from the communication infrastructure 1306 (or from a frame buffer not shown) for display on the display unit 1330.
Computer system 1300 may also include a main memory 1308, preferably random access memory (RAM), and may also include a secondary memory 1310. The secondary memory 1310 may include, for example, a hard disk drive 1312 and/or a removable storage drive 1314, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc, but which is not limited thereto. The removable storage drive 1314 may read from and/or write to a removable storage unit 1318 in a well known manner. Removable storage unit 1318, may represent a floppy disk, magnetic tape, optical disk, etc. which may be read by and written to by removable storage drive 1314. As will be appreciated, the removable storage unit 1318 may include a computer usable storage medium having stored therein computer software and/or data.
In alternative embodiments, secondary memory 1310 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1300. Such means may include, for example, a removable storage unit 1322 and an interface 1320. Examples of such may include, but are not limited to, a removable memory chip (such as an EPROM, or PROM) and associated socket, and/or other removable storage units 1322 and interfaces 1320 that may allow software and data to be transferred from the removable storage unit 1322 to computer system 1300.
Computer system 1300 may also include one or more communications interfaces 1324. Communications interface 1324 may allow software and data to be transferred between computer system 1300 and external devices. Examples of communications interface 1324 may include, but are not limited to, a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 1324 are in the form of signals 1328 which may be, for example, electronic, electromagnetic, optical or other signals capable of being received by communications interface 1324. These signals 1328 may be provided to communications interface 1324 via a communications path (i.e., channel) 1326. This channel 1326 may carry signals 1328 and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link and/or other communications channels. Signals 1328 may represent (but are not limited to) an incoming request for a license or a request for a license template, or an incoming license or acquired license template. Signals 1328 may also represent an outgoing license or license template, possibly modified relative to an acquired license template, or an outgoing request for a license or license template.
In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as, but not limited to, removable storage drive 1314, a hard disk installed in hard disk drive 1312, and signals 1328. These computer program media are means for providing software to computer system 1300.
Computer programs (also called computer control logic) may be stored in main memory 1308 and/or secondary memory 1310. Computer programs may also be received via communications interface 1324. Such computer programs, when executed, enable the computer system 1300 to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, may enable the processor 1304 to perform the present invention in accordance with the above-described embodiments. Accordingly, such computer programs represent controllers of the computer system 1300.
In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 1300 using, for example, removable storage drive 1314, hard drive 1312 or communications interface 1324. The control logic (software), when executed by the processor 1304, causes the processor 1304 to perform the functions of the invention as described herein.
In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s). As discussed above, the invention can be implemented using any combination of hardware, firmware and software.
While some embodiments of the present invention have been described above, it should be understood that it has been presented by way of examples only and not meant to limit the invention. It will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Thus, the breadth and scope of the present invention should not be limited by the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This patent application claims priority to U.S. Provisional Patent Application 60/709,814, entitled “N-Tier License Distribution,” filed Aug. 22, 2005, which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60709814 | Aug 2005 | US |