The present invention relates to software licensing techniques and more specifically to a variety of mechanisms for de-coupling software delivery from license delivery and selective activation of software components.
Software vendors have long employed the use of licenses in an effort to minimize unauthorized use of their product. These licenses are for the most part fixed, however, and therefore are limited in their use.
Fixed license 40 can be implemented in numerous embodiments (40A-40F). One example is fixed license 40A wherein a user can install a software product 30 on a computer 20 an unlimited number of times. However, the user is required to input a serial number with each entry. While fixed license 40A is extremely convenient for the consumer, it does not fully protect a software vendor when an unscrupulous individual decides to install the software on more than one machine.
Another example of a software license is fixed license 40B, also associated with software product 30, executing on computer 20. In this instantiation, software product 30 can only be installed in an environment “X”, where “X” can be a particular application or operating environment. This method of licensing also suffers from the drawback that a user is still free to install it on an unlimited number of environments “X”, without the approval of the software vendor.
Fixed licenses 40C and 40D are similar in that they each limit the user in some manner. License 40C only allows a software product 30 to be installed “N” times wherein “N” is some integer. While license 40C is probably convenient for most end users, it is not inconceivable that a user may experience system problems over a period of times and would need to reload software 30 onto computer 20 multiple times. If the user reaches that limit, he obviously would be unhappy when the paid for software is no longer available for use.
License 40D allows a user to install software 30 for a set or fixed period of time. License 40D is useful for allowing a user to “test-drive” a software package 30, it is not inconceivable that a user can adjust a computer system clock (not shown) on computer 20 and thus get around the expiration date of fixed license 40D. Additionally, a user is typically free to re-install software 30 after the expiration date occurs, thus re-starting the clock. While some software vendors have employed mechanisms to prevent this behavior, for example leaving some sort of file on a user's computer 20 that prevents a second installation of software 30 with fixed license 40D, those same mechanisms often dissuade users from trying out the software 30. This is because they do not want unknown files left on their computer 20 after a software product 30 is un-installed.
Another method of licensing is demonstrated via fixed licenses 40E and 40F. Fixed license 40E is typically bundled with software product 30 and for a lower unit price, it typically will not offer all the possible features available. For example, license 40E only includes features A and B, but not feature C. However, license 40F offers all three features (A, B and C), but an associated price for software package 30 will cost more in relation to software 30/license 40E combination. In order to upgrade to a full package, a user typically cannot purchase feature A in a stand-alone upgrade. Most likely, they would have to purchase software package 30/license 40F—thus paying twice for features they already have.
In the case where software is shipped on a machine or device to a consumer or merchant, another issue arises from the use of licenses of the type of 40E and 40F. To build and ship these different products (different sets of features), a unique Stock Keeping Unit (SKU) is used to track each individual product. By necessity, these units must be built, tested, and shipped as separate products. There is often a direct relationship between the cost to produce these products and the number of available variations.
Accordingly, what are needed are methods and techniques for de-coupling the delivery of software from the process of licensing and the enabling of specific software components that allows a software vendor to control when and where their software is used without unduly constraining the end user.
The present invention contemplates a variety of improved methods and systems for providing software licensing and selective activation of software components or features. In short, the present invention teaches a variety of sophisticated mechanisms for enabling software functionality in a manner controlled as desired by the software vendor.
A method for a user computer to selectively activate a feature of a software package executing on the user computer, in accordance with an embodiment of the present invention, includes receiving a feature activation license from a remote server and activating an inactive feature originally present in the software package.
A method for selectively activating a feature of a software package executing on a user computer, in accordance with another embodiment of the present invention includes a remote server receiving a request from a user computer for activation of an inactive feature that is originally present in the software package. The remote server processes the request and the remote server sends a feature activation license to the user computer for activating the inactive feature.
A method for selectively activating a feature of a software package executing on a user computer, in accordance with yet another embodiment of the present invention, includes a user requesting activation of an inactive feature originally present in the software package. The user computer transmits a request for a feature activation license to a remote server of a software vendor and the remote server receives the request. The remote server processes the request and sends the feature activation license to the user computer. The user computer then receives the feature activation license and activates the inactive feature.
A system for selectively activating a feature of a software package, in accordance with another embodiment of the present invention includes a system information interface and a device information segment on the system information interface wherein the device information segment shows a product identification and a box identification. Also included is a software list segment on the system information interface wherein the software list segment shows a plurality of installed software packages. Additionally, a feature activation list segment on the system information interface is present wherein the feature activation list shows a status of installed features related to an individual installed software package. Finally, a software upgrade/installation interface on the system information interface wherein the software upgrade/installation interface is utilized for selectively activating an inactive feature, is included as well.
Because the software components of the present invention can be selectively enabled (selective feature activation), the software developer can build and test a single product that can in turn be delivered in a plurality of varieties. This reduces development, testing and operational costs associated with offering an entire suite of products. Selective feature activation requires little interaction with end users and provides a secure mechanism for licensing individual features within the software product. This can be done on a system specific or group specific level.
These and other advantages of the present invention will become apparent to those skilled in the art upon a reading of the following detailed descriptions and a study of the various FIGS.
In an embodiment of the present invention, an inactive feature can be activated automatically in response to a particular event. Some of these events can include, for example, an expiration date and an activation of another related inactive feature. One skilled in the art will appreciate that other events can trigger the automatic activation of an inactive feature while not departing from the true scope and spirit of the present invention.
Software list segment 100 enumerates the installed software products 130, their versions 140, a short description 150 and an installation date 160. Feature activation list segment 110 lists the available features 170 corresponding to an individual software product 130, an activation date 180, an expiration date 190 and a status 200. Activation date 180 indicates when an individual feature was enabled or “N/A” (not applicable) if that feature was shipped already enabled. Expiration date 190 is used when a feature is to be enabled for a set period of time, for example 30 days. If no expiration date 190 is set, then the feature will stay enabled indefinitely. Status 200 indicates if a particular feature is active or inactive.
Software upgrade/install interface 120 is used for enabling new features. In brief, a user obtains a feature activation license (not shown) from a software vendor and that license allows the user to activate the license. In the context of the present invention, it should be understood that the phrases “feature activation license” and “feature activation file” can be used interchangeably and refers to a data structure for selectively enabling features of a software package or packages. This process of feature activation will be discussed in more detail subsequently. The license can be obtained through various methods such as a through a web browser, FTP (file transfer protocol), SCP (secure copy) or similar methods. Segment 120 can also be used to obtain and install feature enhancement, new features, new software, patches, etc. In one embodiment of the present invention, currency is exchanged between an end user and a software vendor for feature activation, feature enhancements, new features, new software, patches, etc.
Multiple features can be simultaneously enabled using the method as described in
The feature activation license can be a small file containing the necessary attributes (box ID, feature to activate, etc) and an activation key pair whose use will be described in the next section. The feature activation file may also be encrypted to keep users from viewing the contents of the license, using either a shared symmetric key or an asymmetric private key such as the one used for signing. To support third-party developers, the asymmetric private key used for signing (and possibly encrypting) may be part of a certificate chain with the root certificate being issued by the vendor of the primary software application or hardware device. If the application or device that will receive the activation license does not know the vendor's certificate, the public keys of the certificate chain must also be included in the feature activation license.
Referring back to
The method begins at operation 324 and a feature file is obtained from a software vendor at operation 325. The feature file can contain either a patch or new/updated features to install. At an operation 326, a first token of the signature info in the file header (of the feature file) is checked to see if the file is a feature activation or a patch and can be simply denoted as “feature” or “patch”. If it is a patch, it is installed via operation 331. If it is a new feature to be installed, the file is decrypted, verified and the contents of the feature activation file are untarred at operation 327. There will only be one file that is contained within the feature file—the feature activation file and it contains the box ID's and the activation code for the features. It also contains the list of box ID's that this feature activation file can be used for and what features should be activated for each box ID's as well as the services that ought to be restarted after the feature is activated.
The contents of the feature file are verified by ascertaining that there is only one feature activation file contained within the feature file (if it is not of the patch variety) and that it is in the proper format. A box ID of the machine is verified against a known list of box ID's that are included in the feature activation file, at operation 328. If there are no box ID matches, group ID's are then checked. Finally, a check is performed to see if the software has already been installed (in the case of an update to a feature). This is accomplished by checking the version number of the feature in the feature activation file and the version number of the feature already installed on the system, at operation 329. The feature update is installed, if necessary, at operation 331. The method ends at operation 332.
In further regard to the same embodiment of the present invention, the feature activation file will be described in detail. It will be appreciated that this description is not necessarily limited to the patch/feature upgrade embodiment. The design of the feature activation file layout is such that it can accommodate the aggregation of multiple feature files together into a single feature file that can activate different features for each machine. Advantageously, this methodology can keep track of many different patch files for different machines. The format of the feature activation file is designed such that it is easy to parse with a configuration utility. Each feature activation file will also contain a version number corresponding to a version of the activation software that created it.
Further embodiments of the present invention will now be described.
Regarding the generation of box ID's, a box ID is generated based on the MAC addresses of the machine. Each MAC address is 48 bits and the concatenation of two MAC addresses gives a total of 12 bytes. The SHA 1 (secure hash algorithm) hash of the 12 bytes is appended to the concatenated MAC addresses. The hash is 20 bytes which gives a total of 32 bytes. The result is then encrypted with a weak encryption scheme, similar to a “utl_protect” function. The final result is then Base64 encoded.
With further reference to
Because the software components of the present invention can be selectively enabled (selective feature activation), the software developer can build and test a single product that can in turn be delivered in a plurality of varieties. This reduces development, testing and operational costs associated with offering an entire suite of products. Selective feature activation requires little interaction with end users and provides a secure mechanism for licensing individual features within the software product. This can be done on a system specific or group specific level.
In addition to the above mentioned examples, various other modifications and alterations of the invention may be made without departing from the invention. Accordingly, the above disclosure is not to be considered as limiting and the appended claims are to be interpreted as encompassing the true spirit and the entire scope of the invention.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US03/26637 | 8/25/2003 | WO | 4/10/2006 |
Number | Date | Country | |
---|---|---|---|
60405848 | Aug 2002 | US |