Patent Application
20090290716
The present disclosure relates generally to information handling systems, and more particularly to digital software license procurement.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an information handling system (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Software vendors commonly require IHS manufacturers to purchase individual license keys and pay a royalty for the ability to install or use their software. Some software vendors require IHS manufacturers to purchase an expensive paper sticker, for which the IHS manufacturer pays a license fee. Software vendors also may require the IHS manufacturer to install special bits in the IHS basic input/output system (BIOS) to match the operating system (OS) media, with the license key stuck on the media, and provide generic activation bits on the hard drive. Such licensing systems are cumbersome and expensive to operate.
Accordingly, it would be desirable to provide an improved digital software license procurement absent the disadvantages discussed above.
According to one embodiment, a digital software licensing system including one or more subsystems to issue an order for one or more software licenses to a software vendor, receive from the vendor a wrapped license file, decrypt the wrapped license file using a manufacturer private key and verify authenticity of wrapped license file using a vendor public key. The wrapped license file includes a list of license keys which are signed using a vendor private key and encrypted using the manufacturer public key.
For purposes of this disclosure, an IHS 100 includes any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS 100 may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The IHS 100 may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, read only memory (ROM), and/or other types of nonvolatile memory. Additional components of the IHS 100 may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The IHS 100 may also include one or more buses operable to transmit communications between the various hardware components.
Other resources can also be coupled to the system through the memory I/O hub 104 using a data bus, including an optical drive 114 or other removable-media drive, one or more hard disk drives 116, one or more network interfaces 118, one or more Universal Serial Bus (USB) ports 120, and a super I/O controller 122 to provide access to user input devices 124, etc. The IHS 100 may also include a solid state drive (SSDs) 126 in place of, or in addition to main memory 108, the optical drive 114, and/or a hard disk drive 116. It is understood that any or all of the drive devices 114, 116, and 126 may be located locally with the IHS 100, located remotely from the IHS 100, and/or they may be virtual with respect to the IHS 100.
Not all IHSs 100 include each of the components shown in
The process 130 begins at 136 where the manufacturer 132 generates a purchase order (PO) to request one or more license keys from the vendor 134. In an embodiment, the purchase order may apply to a purchase of “x” number of software licenses, software upgrades, software down grades, or a variety of other licenses. At 138, the manufacturer 132 transfers the purchase order to the vendor 134. The transfer 138 may take place via a network channel, such as the Internet, a wide area network, a local area network and/or a variety of other network channels for communicating information. In an embodiment, the channel may be a secure channel. In an embodiment, the manufacturer 132 may sign the information transferred 138 to the vendor 134 so that an encryption system may be used to secure the information transferred at 138. The vendor 134 receives the purchase order at 140 and may process the order and initiate billing for the order. Billing may be billed to the manufacturer 132 for the licenses to be received from the vendor 134 to the manufacturer 132. The vendor 134 may then generate a licensing file at 142. The vendor licensing file includes a list of license keys that may be used to validate use of the software, as should be readily understood by one having ordinary skill in the art.
Using a public-key type cryptographic security system at 144, the vendor 134, may create a wrapped license file. To create the wrapped license file, the vendor 134 may sign the vendor license file with a vendor private key. A manufacturer purchase order may be added to the signed vendor license file for identification purposes for the license keys. Additionally, a confirmation code may be added to the signed vendor license file allowing the simple confirmation of receipt of the license keys by the manufacturer 132. In an embodiment, the signed vendor license file, the manufacturer purchase order number and the confirmation code are “wrapped” together and encrypted using the manufacturer's public key. The wrapped license file at 144 is then transferred to the manufacturer 132 at 146. The manufacturer 132 may then decrypt the wrapped license file using the manufacturer's private key at 148. In addition, the manufacturer 132 may send a confirmation at 150 to the vendor 134 to confirm to the vendor 134 that the license file was received safely. The confirmation may include the manufacturer purchase order number and/or the confirmation code. Upon receipt of the confirmation 150, the vendor may then complete a billing cycle at 152 to bill or charge the manufacturer 132 for the purchased licenses. Returning now to block 148, the manufacturer 132 may send the license file to the manufacturer's factory at 154. Once received at the factory, the manufacturer 132 may verify the license file/the list of license keys using the vendor public key at 156. After verification at 156, the manufacturer 132 may upload or inject the license keys into one or more IHSs 100 at 158 using any system or method to inject the license keys to the IHSs 100. After the manufactured IHSs 100 are equipped with the software and corresponding license keys, the manufacturer 132 may then distribute the IHSs 100 at 160.
This disclosure describes a process for standardizing a procurement and licensing of unique digital software keys. This disclosure may be applied to the license key process for all software vendors to an IHS manufacturer.
In an embodiment, the processes disclosed use standard signing and encrypting processes known today to securely transfer digital license keys through standard procurement practices, at which point the license keys may be separated and transferred to the factory or original design manufacturer (ODM) for consumption (e.g., downloading to an IHS 100). Any method of consumption may be used with this disclosure.
As described above and shown in the Figs., the manufacturer 132 may issue a purchase order for x licenses and supplies in the manufacturer public key (or some other equivalent cryptographic key) to the vendor 134. The Vendor 134 processes this purchase order and has their licensing/software department generate and sign a file of x license keys. The vendor 134 then wraps this with the referenced manufacturer 132 purchase order and a confirmation code (e.g. a delivery/acceptance confirmation). This file is encrypted with the manufacturer public key for security. This signed file is transmitted to the manufacturer procurement, which decrypts the file, using the manufacturer's private key, matches the purchase order, and if all is correct, sends the confirmation code back to complete the vendor billing. It is understood that other forms of encryption, including symmetric keys, could be utilized as well.
The signed license file is then sent to the factory or original design manufacturer, where it is verified and the keys are dispensed through an injection mechanism to the IHS 100. The injection mechanism is not described here, but could be BIOS, HDD bits, TPM, or other as should be readily understood by one having ordinary skill in the art. In an embodiment, the transmissions are to be sent over a secure channel such as SSL. If the transmission medium is unsecured or further security is wanted/needed (such as retransmission to an ODM), additional cryptographic signing/encryption measures may be utilized.
In an embodiment, the processes remove the value from any paper license stickers because the manufacturer 132 has paid the license fee through the digital process. Consequently the manufacturer 132 should be able to print license stickers on demand in the factory and enable other inventory reduction and manufacturing efficiencies, such as not needing secure physical cage storage for the purchased license stickers.
As discussed above, license key returns follow a similar process, substantially in reverse of the procurement process. Because there is not a physical sticker to remove and return when not used, the digital code may be reused (e.g., if the system has not left the factory) or if necessary returned to the vendor (for systems returned by the customer). The vendor 134 may allow a certain percentage of claimed returns unchallenged or can remove the returned code from their validation database if they employ such a mechanism.
Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.
