Activation system architecture

BACKGROUND

p-0002Computer software may be purchased in various forms, such as on a computer readable medium. A user may then install the software on his/her computer system. The same purchased copy of software may be easily replicated and also installed on multiple machines. The software product vendor may want to control use of each purchased copy of the software product in accordance with the scope of the user's license such as, for example, not allow use of a same purchased copy on more than one computer system. In order to control use of purchased copies of the software product in accordance with a purchaser's license terms, different techniques may be utilized. One existing technique includes requiring activation of the software product after installation in order to use the installed software. For activation purposes, a product key consisting of letters and/or numbers may be included with each purchaser's copy of the software product. A different product key may be included with each purchaser's copy of the software product. After the software is installed on a computer by a user, a hardware identifier is generated. The hardware identifier may be characterized as a “fingerprint” of the user's computer on which the software has been installed. The hardware identifier may be produced using multiple hardware attributes of the user's computer. As part of the activation process, the user registers the hardware identifier with the product key. The hardware identifier is associated with the product key and may be used to track and control subsequent activations of the same purchased copy. For example, a same purchased copy of software may be installed on two computer systems each having a different hardware identifier. Activation may be completed for a first of the computer systems having a first hardware identifier. The user may attempt to activate the software for use on the second computer system. If the license terms only allow the purchased copy of the software to be activated on a single computer system, the activation process for the second computer may fail. As part of activating the software on the second computer, it is determined that the software having the product key is already activated on the first computer having the first hardware identifier.

SUMMARY

p-0003This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

p-0004Techniques are described herein for activating software for licensing purposes. An entitlement certificate is generated including one or more entitlements describing license characteristics of the software. The one or more entitlements are determined in accordance with first information about the software. A binding certificate in accordance with a binding type included in the one or more entitlements for the software is generated. The binding certificate identifies an entity to which the license is bound. A license in accordance with the binding certificate and the entitlement certificate is generated.

DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become more apparent from the following detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> is an example of an embodiment illustrating an environment that may be utilized in connection with the techniques described herein;

<figref idrefs="DRAWINGS">FIG. 2</figref> is an example of an embodiment of components that may comprise a device of <figref idrefs="DRAWINGS">FIG. 1</figref>;

<figref idrefs="DRAWINGS">FIG. 3</figref> is an example of an embodiment of components that may be used in connection with online activation processing;

<figref idrefs="DRAWINGS">FIG. 3A</figref> is an example representation of an entitlements database;

<figref idrefs="DRAWINGS">FIG. 4</figref> is an example of information that may be included in an entitlement certificate;

<figref idrefs="DRAWINGS">FIG. 5</figref> is a flowchart of processing steps that may be performed by a licensing service in connection with online activation processing;

<figref idrefs="DRAWINGS">FIG. 6</figref> is a flowchart of processing steps that may be performed in connection with launching software on a device having a license stored thereon;

<figref idrefs="DRAWINGS">FIG. 6A</figref> is an example representation of a license database;

<figref idrefs="DRAWINGS">FIG. 7</figref> is an example of an embodiment of components that may be used in connection with offline activation processing;

<figref idrefs="DRAWINGS">FIG. 8</figref> is an example of an installation identifier;

<figref idrefs="DRAWINGS">FIG. 9</figref> is an example illustrating how the Offline Activation Service (OAS) parses an installation identifier;

<figref idrefs="DRAWINGS">FIG. 10</figref> is a flowchart of processing steps that may be performed by the OAS in connection with generating the confirmation identifier;

<figref idrefs="DRAWINGS">FIG. 11</figref> is an example of a confirmation identifier;

<figref idrefs="DRAWINGS">FIG. 12</figref> is a flowchart of processing steps that may be performed in connection with launching software on a device; and

<figref idrefs="DRAWINGS">FIG. 13</figref> is a flowchart of processing steps that may be performed in connection with launching software on a device using information associated with having previously performed offline activation processing.

DETAILED DESCRIPTION

p-0021Referring now to <figref idrefs="DRAWINGS">FIG. 1</figref>, illustrated is an example of a suitable computing environment in which embodiments utilizing the techniques described herein may be implemented. The computing environment illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref> is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the techniques described herein in connection with enabling software products to be activated for licensing purposes. The techniques herein may utilize an entitlement service, an optional binding service and a license service to establish the rights associated with the software package installed by a user and the identity to which any issued license is required to be bound. In connection with an online activation mode, the license service may issue a license which is verified each time the software for which the license was issued is invoked. In connection with an offline activation mode, the user may be provided with a confirmation identifier used in connection with other information for verification each time the software for which the license was issued is invoked.

p-0022The techniques set forth herein may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments. Those skilled in the art will appreciate that the techniques described herein may be suitable for use with other general purpose and specialized purpose computing environments and configurations. Examples of well known computing systems, environments, and/or configurations include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, network PCs, wireless devices such as cellular phones, PDAs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

p-0023Included in <figref idrefs="DRAWINGS">FIG. 1</figref> are a device <b>12</b>, a network <b>14</b>, and a server <b>15</b>. The device <b>12</b> may be, for example, a computer, such as a personal computer, having a display output device and an input device providing for interactive I/O with a user thereof. In following paragraphs, additional details are provided with respect to the device <b>12</b>. However, the same details may also apply to one or more other devices that may be connected to the network <b>14</b> in an embodiment. Although the example <b>10</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> includes only a single device and a single server, an embodiment utilizing the techniques herein may include any number of devices and other components.

p-0024The device <b>12</b> included in <figref idrefs="DRAWINGS">FIG. 1</figref> is exemplary for purposes of illustrating the techniques described herein in connection with software components. In one embodiment, any device <b>12</b> providing the functionality described herein may be included in an embodiment. The device <b>12</b> may include a processor used to execute code included in one or more program modules. Described in more detail elsewhere herein are program modules that may be executed by the device <b>12</b> in connection with the techniques described herein. The device <b>12</b> may operate in a networked environment and communicate with the server <b>15</b> and other computers or components not shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. As described herein, the device <b>12</b> may be a personal computer. In other embodiments, the functionality of device <b>12</b>, or the device <b>12</b> itself, may be included in another component in accordance with a particular environment in which the device <b>12</b> is utilized. As will be described in following paragraphs in more detail, software may be installed on the device <b>12</b> which needs to be activated prior to use. The techniques herein may be used to activate the installed software on the device <b>12</b>.

p-0025In connection with the online activation mode described in more detail in following paragraphs, the device <b>12</b> may communicate with one or more services of the server <b>15</b> for activating the software installed on device <b>12</b>. The online activation mode is one way in which installed software may be activated for use when the device <b>12</b> has connectivity to one or more servers providing services for product activation.

p-0026It will be appreciated by those skilled in the art that although the device <b>12</b> is shown in the example as communicating in a networked environment, the device <b>12</b> may communicate with other components utilizing different communication mediums. For example, the device <b>12</b> may communicate with one or more components utilizing a network connection, and/or other type of link known in the art including, but not limited to, the Internet, an intranet, or other wireless and/or hardwired connection(s) to the server <b>15</b> and/or other components.

p-0027It should be noted that although the device <b>12</b> is illustrated as having network connectivity to the server <b>15</b>, the techniques described herein may be used in connection with a device directly connected to the server <b>15</b> without a network. Furthermore, it should also be noted that the device <b>12</b> may also operate in a standalone mode with no connectivity to a server. In such instances, software installed on the device <b>12</b> may be activated using an offline activation mode also described in more detail in following paragraphs.

p-0028Referring now to <figref idrefs="DRAWINGS">FIG. 2</figref>, shown is an example of components that may be included in the device <b>12</b> as may be used in connection with performing the various embodiments of the techniques described herein. The device <b>12</b> may include one or more processing units <b>20</b>, memory <b>22</b>, a network interface unit <b>26</b>, storage <b>30</b>, one or more other communication connections <b>24</b>, and a system bus <b>32</b> used to facilitate communications between the components of the device <b>12</b>.

p-0029Depending on the configuration and type of user device <b>12</b>, memory <b>22</b> may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. Additionally, the device <b>12</b> may also have additional features/functionality. For example, the device <b>12</b> may also include additional storage (removable and/or non-removable) including, but not limited to, USB devices, magnetic or optical disks, or tape. Such additional storage is illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref> by storage <b>30</b>. The storage <b>30</b> of <figref idrefs="DRAWINGS">FIG. 2</figref> may include one or more removable and non-removable storage devices having associated computer-readable media that may be utilized by the device <b>12</b>. The storage <b>30</b> in one embodiment may be a mass-storage device with associated computer-readable media providing non-volatile storage for the device <b>12</b>. Although the description of computer-readable media as illustrated in this example may refer to a mass storage device, such as a hard disk or CD-ROM drive, it will be appreciated by those skilled in the art that the computer-readable media may be any available media that can be accessed by the device <b>12</b>.

p-0030By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Memory <b>22</b>, as well as storage <b>30</b>, are examples of computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by device <b>12</b>.

p-0031The device <b>12</b> may also contain communications connection(s) <b>24</b> that allow the computer to communicate with other devices and components such as, by way of example, input devices and output devices. These and other devices are well known in the art and need not be discussed at length here.

p-0032In one embodiment, the device <b>12</b> may operate in a networked environment as illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref> using logical connections to remote computers through a network. The device <b>12</b> may connect to the network <b>14</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> through a network interface unit <b>26</b> connected to bus <b>32</b>. The network interface unit <b>26</b> may also be utilized in connection with other types of networks and/or remote systems and components.

p-0033One or more program modules and/or data files may be included in storage <b>30</b>. During operation of the device <b>12</b>, one or more of these elements included in the storage <b>30</b> may also reside in a portion of memory <b>22</b>, such as, for example, RAM for controlling the operation of the user computer <b>12</b>. The example of <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates various components including an operating system <b>40</b>, one or more application programs <b>46</b>, installation and activation software <b>50</b>, and other components, inputs, and/or outputs <b>48</b>.

p-0034The application program <b>46</b> may be software installed by a user on the device <b>12</b>. Once the application program <b>46</b> has been installed, it may be activated in order to enable the application program to execute. As a result of the activation process, verification data is obtained for use in connection with verifying that subsequent attempts to launch the program are in compliance with licensing terms. The verification data used may vary with the particular activation mode. In one embodiment, the activation process may be performed using one of two different activation modes, the online activation mode and the offline activation mode mentioned briefly above and described in more detail below. Each mode may result in different verification data for use on the device <b>12</b>. The online activation mode may be used when the device <b>12</b> has connectivity to the server <b>15</b>. The verification data generated as a result of the online activation mode may include a license in an electronic form. The license may be generated by the server <b>15</b> and communicated to the device <b>12</b>. The license may be stored on the device <b>12</b> and used in connection with each subsequent launch of the application program. In connection with an offline activation mode, the device <b>12</b> does not obtain verification data over a connection to the server <b>15</b>. In connection with the offline activation mode, the device <b>12</b> may not be connected to any network and may be operating standalone. The verification data may include information obtained through other communication means such as, for example, over the phone with a user communicating with a Customer Service Representative (CSR) or Interactive Voice Recognition (IVR) system. This verification data obtained as a result of the offline mode activation process may include a confirmation identifier obtained over the phone or alternative communication medium besides a computer network. The verification data may be entered, such as by manual data entry on the device <b>12</b>, and stored for subsequent use on the device <b>12</b> when launching the application program <b>46</b>.

p-0035The device <b>12</b> also includes installation and activation software <b>50</b> used in connection with installing and activating the software in accordance with techniques herein. The component <b>50</b> may also include software used in connection with each program launch or invocation. Each time program <b>46</b> is invoked, the component <b>50</b> may perform verification processing to ensure compliance with the license or other verification data previously obtained in accordance with the particular activation mode used.

p-0036The operating system <b>40</b> may be any one of a variety of commercially available or proprietary operating systems. The operating system <b>40</b>, for example, may be loaded into memory in connection with controlling operation of the device <b>12</b>.

p-0037It should be noted that the server <b>15</b> of <figref idrefs="DRAWINGS">FIG. 1</figref> may include one or more computers with components similar to those described in connection with <figref idrefs="DRAWINGS">FIG. 2</figref>. The different services or modules that may be included in the server <b>15</b> for use with the activation techniques herein are described in more detail in following paragraphs.

p-0038Referring now to <figref idrefs="DRAWINGS">FIG. 3</figref>, shown is an example of components that may be used in connection with the activation techniques herein for the online activation mode. As described above, the online activation mode provides for activation of installed software on the computer <b>102</b> when the computer <b>102</b> is connected to the server <b>15</b>. Included in <figref idrefs="DRAWINGS">FIG. 3</figref> are an entitlement service (ES) <b>104</b>, a binding service (BS) <b>110</b>, and a license service (LS) <b>120</b>. In one embodiment, all of the components <b>104</b>, <b>110</b> and <b>120</b> may be included on a single server. Alternatively, it will be appreciated by those skilled in the art that one or more of the services <b>104</b>, <b>110</b> and <b>120</b> may be located on different servers in communication with the computer <b>102</b>.

p-0039The activation process may be commenced after installation of the software on the computer or other device <b>102</b>. As part of the installation dialogue, the user may be prompted as to whether to perform activation processing. In an embodiment providing multiple activation modes, the user may also be prompted to select one of the possible activation modes, such as the online activation mode. Upon selection of the online activation mode, the computer <b>102</b> may commence processing for the online activation process that will now be described. In connection with performing the online activation process, the computer <b>102</b> may contact each service <b>104</b>, <b>110</b> and <b>120</b> on the server. Information regarding the server address, such as an Internet address, and other data needed to connect to connect to the server and appropriate services may be included in, or otherwise communicated to the component <b>50</b>. The component <b>50</b> may be located on the computer <b>102</b> as a result of installation of the software for which activation is being performed. A location, such as an Internet address, for each of the ES, BS and/or LS may be included with the component <b>50</b>. Such information may be incorporated into a data file or coded portion of software for the component <b>50</b>. As also described in following paragraphs, a location of one or more of the services may be communicated using other means. For example, the ES may provide an Internet address of the LS to be used.

p-0040The computer <b>102</b> may contact the ES <b>104</b>. The computer <b>102</b> may send to the ES <b>104</b> a purchase token and package information <b>106</b> and receive an entitlement certificate (EC) <b>108</b>. The purchase token and package information may be stored on the computer <b>102</b> for use in connection with subsequent processing when launching the application program or other software for which activation processing is being performed.

p-0041The ES <b>104</b> determines, based on the purchase token and package information <b>106</b>, what rights or entitlements are associated with the installed software on the computer <b>102</b>. The purchase token may be a product key received with the purchased copy of the software installed on the computer <b>102</b> for which activation is being performed. The purchase token may be a string of alphanumeric and/or other characters used to distinguish or differentiate between different purchased copies of a same software product. Each purchased copy of the software product, such as a word processor, may include the same software for installation on a computer. The purchase token may be used to differentiate between these purchased copies. The purchase token may be provided, for example, on a label or with other papers included with the purchased software. The user may be prompted to enter the purchase token as part of the installation dialogue prior to activation. For example, a purchase token may be the information included on a shrink-wrap package of the software product. The purchase token may include a 5-bit product code, a 3 bit site value indicating a place of manufacture for the software product, and a 7 bit serialized number that is incremented with each instance of the product manufactured. The package information may be information identifying the software product such as, for example, a string of alphanumeric and/or other characters identifying the software product by a name to distinguish this software product from possibly other software products. The package information may be provided by the installation software for use in connection with activation. Alternatively, the user may be prompted prior to activation to enter package information as may be included with the purchase token of the software product.

p-0042Based on the purchase token and package information <b>106</b>, the ES <b>104</b> determines the rights or entitlements for the installed software on the computer <b>102</b>. The ES <b>104</b> may use the purchase token and package information <b>106</b> to index into an entitlements database <b>104</b><i>a </i>to obtain corresponding entitlements. The entitlements indicate the attributes of the license or license characteristics such as the license terms and conditions and other aspects related to the terms and conditions of the license. For example, the entitlements use attributes to describe various terms and conditions of the license such as license expiration date and/or start date and how many computers can execute the same software copy, as well as related aspects such as the type of license and type of binding. Each of the foregoing types of entitlements, and others are described in more detail in following paragraphs.

p-0043Referring to <figref idrefs="DRAWINGS">FIG. 3A</figref>, shown is an example representation of the entitlements database. The example <b>150</b> illustrates how the purchase token and/or package information <b>156</b> may be used to index into the database <b>154</b> to obtain the corresponding one or more entitlements <b>152</b>. As a further illustration, the database may use as a first index the package information included in column <b>160</b>. The database may be logically organized so that entitlements for each product are grouped together as illustrated by <b>166</b><i>a</i>. In this example, each product having a first set of package information, package info <b>1</b>, is included in <b>166</b><i>a</i>. Each product may have a range of one or more associated purchase tokens for which a set of one or more entitlements may be included in the database. For example, package info <b>1</b> may have a first set of entitlements, entitlement set <b>1</b>, included in column <b>164</b> for a first purchase token, purchase token <b>1</b>, of column <b>162</b>. The purchase token <b>1</b> may be used as a secondary index into the entitlements database to obtain the entitlement set <b>1</b>. The database <b>154</b> may also specify a range of purchase tokens in column <b>162</b> for which a set of entitlements are retrieved. For example, if the purchase token is within the range designated by “Purchase token 2 . . . Purchase token m”, a second set of entitlements, entitlement set <b>2</b> of column <b>164</b>, may be used.

p-0044The entitlements may indicate the type of license. Examples of different license types may include, but are not limited to, perpetual, trial-based license, subscription, and per use or number of uses license. The trial-based license may be a license for a defined time period such as 30 days. The subscription license may also be a time-based license for a defined time period or duration. With a subscription license, the user may be given/prompted with a chance to renew the license in connection with processing steps performed at application launch or invocation time. A number of uses license indicates a number of times that the software product may be launched or invoked for execution.

p-0045The entitlements may indicate an overall license expiration date so that regardless of the type of license, the license may expire on a certain date. For example, the software may be a field test version and may not be used after a particular date regardless of when the licensing period commenced. As another example, the software product may be an electronic encyclopedia or other item containing dated information so that the license may expire at a definite date at which the information is deemed to be outdated. The entitlements may also indicate a start or beginning date, for example, for software that only may be used from a particular starting date.

p-0046The entitlements may indicate how many computer systems the software may be activated upon. For example, shrink-wrapped software may be a single user license so that each copy of the installed software may only be activated on one computer. As will be described in connection with the license server <b>120</b>, such attributes may be used so that subsequent attempts to activate the same software copy on a different computer will fail. It should be noted that this entitlement may also be characterized as indicating the number of activation bindings possible. As described in more detail elsewhere herein, an activation binding is when a license is bound to an instance of a binding entity in connection with the activation of a software product.

p-0047The entitlements may indicate what one or more types of binding may be used. In connection with the activation service, the license generated for a purchase token is bound to a particular binding type instance. The entitlements may indicate the type or types of binding to which the license may be bound. In one embodiment, different possible binding types that may indicated include a hardware identifier, user authentication information, a USB key identifier, and a trusted platform module (TPM). A different license may be issued for an activation binding which is then bound for a particular instance of a binding type.

p-0048An instance of the hardware identifier binding type may be a hardware identifier describing the hardware of a computer having installed software thereon for which activation processing is being performed. The hardware identifier may be characterized as a hardware “fingerprint” of a computer based on the particular hardware of the computer or other device upon which the software is installed. The hardware identifier may be a multi-bit value. Each grouping of one or more bits of the multi-bit value may be determined from a different hardware component of the computer or other device. For example, one or more bits in the hardware identifier may be derived from a global address of a network card of the computer. Other bits in the hardware identifier may be derived from other hardware components such as, for example, the serial number of the hard drive, the number of bytes of RAM, and the like. Generating a hardware identifier is described in more detail, for example, in U.S. Pat. No. 6,243,468, Jun. 5, 2001, Pearce et al., SOFTWARE ANTI-PIRACY SYSTEM THAT ADAPTS TO HARDWARE UPGRADES. An embodiment may also use other techniques such as described, for example, in U.S. Publication No. 2004/0177354, published Sep. 9, 2004, Gunyakti et al, COMPACT HARDWARE IDENTIFICATION FOR BINDING A SOFTWARE PACKAGE TO A COMPUTER SYSTEM HAVING TOLERANCE FOR HARDWARE CHANGES (U.S. patent application Ser. No. 10/378,294, filed Mar. 3, 2003). The size of the hardware identifier may vary in an embodiment. For example, an embodiment may use a hardware identifier which is 32 bits or larger.

p-0049The hardware identifier is meant to identify a particular computer system and distinguish one computer system from another as needed to limit software piracy. A different hardware identifier suggests that the underlying hardware components upon which the identifier is based differ in some manner as may be the case with different computer systems. In such cases, attempting to bind a license based on a purchase token to one hardware identifier when an existing license based on the same purchase token is already bound to another hardware identifier may be detected and disallowed for a single computer system license using the activation techniques herein as described in connection with the license service. However, it may also be the case that a same computer system's hardware identifier has changed due to changes in hardware configuration of the same computer system. For example, installing a new hard drive may change the hardware identifier of the computer. An embodiment may also utilize a level of tolerance in connection with determining whether two hardware identifiers identify the same computer system. The tolerance may account for a degree of allowable differences between hardware identifiers of a same computer system generated at different points in time, for example, as may occur due to hardware upgrades or replacements. For example, in an embodiment having a multi-bit hardware identifier, the tolerance may allow for a difference of one or more bits in two hardware identifiers and the two hardware identifiers may be deemed to still identify the same computer system. An embodiment may use different levels of tolerances and techniques in connection with generating hardware identifiers and determining whether two hardware identifiers refer to the same computer system for purposes of binding with a license. The foregoing U.S. Pat. No. 6,243,468, and U.S. Publication No. 2004/0177354 describe different tolerance levels and techniques used in determining whether two hardware identifiers refer to a same computer system. In connection with a hardware identifier binding type, the license is bound to the hardware identifier, and thus the corresponding computer system for the hardware identifier, as a result of the activation process. The computer <b>102</b> may include software thereon capable of generating a hardware identifier in accordance with the particular hardware identifier technique used in an embodiment.

p-0050An embodiment may also allow other types of bindings such as binding a license to user authentication information. User authentication information may include, for example, a user login name/identifier and password, and the like. With such a license binding type, a single user license allows execution of the software installed on different computers as long the software execution is associated with the user authentication information specified in the binding. For example, software product <b>1</b> may be installed on 10 computers. Software product <b>1</b> may have a single user license for which activation is performed resulting in the generation of a license which is bound to account information for User <b>1</b>. User <b>1</b> may log on to any one of the 10 computers with User <b>1</b> account and credentials and execute software product <b>1</b>.

p-0051Another type of binding may be based on an identifier associated with a portable secure identification device such as a dongle, a USB device, a smart card, and the like. A dongle as known in the art is a physical device attached to an I/O port such as a USB port, serial port or a parallel port. In connection with a portable secure identification device binding type, the binding is made to the portable secure identification device. In connection with a USB key identifier associated with a USB device, a single user license allows execution of software based on whether there is a USB device plugged in with the USB key identifier specified in the binding instance. As such, the same software of a single user license may be installed on multiple computer systems. Execution of the software on each of the computer systems is allowed as long as the USB key identifier indicated in the binding is inserted into the computer system. As known in the art, a USB key identifier may be associated with each USB device and may be assigned by each particular USB vendor. It will be appreciated by those skilled in the art that the binding type for a USB device and associated USB identifier may also be used in connection with other portable, non-volatile, memory devices and should not be construed to apply to just USB devices as illustrated herein for exemplary purposes. In following paragraphs, reference is made to the USB key identifier as an example of a portable secure identification device. However, this particular type of portable secure identification device is mentioned for purposes of illustration of the techniques herein. It will be appreciated by those skilled in the art that any other type of portable secure identification device may be utilized.

p-0052Another type of binding may be based on a trusted platform module (TPM). As known in the art, a TPM is a microchip designed to provide some basic security-related functions to the software utilizing it. The TPM chip may be installed, for example, on the motherboard of a PC or laptop, and communicates with the rest of the system via a hardware bus. The TPM has a master key stored within the TPM itself which is never exposed. Systems that incorporate a TPM have the ability to create cryptographic keys using the master key as well as performing encryption and decryption in connection with the master key, and keys generated therefrom. Use of the master key, or key generated therefrom, in connection with binding is described elsewhere herein to create a license bound to a particular TPM. With the TPM binding type, software activated from a computer system having a TPM module is allowed to execute on the computer system having the TPM module.

p-0053The entitlements may also indicate what additional information, if any, is required to receive a license. For example, a user may be required to provide a name, address, phone number, and the like. The foregoing entitlements may be customized for different requirements for license activation that may vary with product, vendor, and the like. For example, if a user is required to provide name and address information, this information may be acquired prior to activation and sent to the ES <b>104</b> as additional data besides the package information and the purchase token. If the additional information including the name and address information is provided, then the ES returns the entitlement certificate <b>108</b>. Otherwise, an error is detected and the activation process may terminate with an appropriate error message displayed on an output device of the computer <b>102</b>. The ES <b>104</b> may check to see that all needed information is supplied. This additional information may be stored, for example, in a database of the server for use by the vendor. Rather than terminate the activation process with an error message if the additional information is not supplied, the ES <b>104</b> may identify the deficiency in information supplied, for example, the address information may be incomplete or missing. The ES <b>104</b> may issue a request for the missing information from the computer <b>102</b> and give the user thereon another chance to supply the missing information and obtain the entitlement certificate (EC) <b>108</b>.

p-0054The entitlements, along with possibly other information, may be returned to the computer <b>102</b> in the EC <b>108</b>. The EC <b>108</b> may be a digitally signed document, such as a digitally signed XML document, including the package information, the purchase token and the entitlement information for the purchase token and package information <b>106</b> received by the ES <b>104</b> from the computer <b>102</b>. The entitlement information may indicate, for example, that the license is a perpetual license for use on a single computer system with a hardware identifier binding. The EC <b>108</b> is certified expression of the licensing rights or entitlements. As described above, the ES <b>108</b> may store in an entitlements database the entitlements for a particular combination of package information and/or purchase token. The database may be indexed to return entitlement information based on package information and/or purchase token. For example, for package information identifying a word processing product, the entitlement information may indicate one or more types of licenses, one or more binding types including a hardware identifier binding, and the like. For the word processing product, a predetermined range of purchase tokens may be associated with trial subscriptions. If the purchase token received is included in the predetermined range, entitlement information may be returned to indicate the trial subscription license, beginning and ending dates, and the like. If the purchase token is not within the predetermined range, the license type may be indicated as perpetual rather than a trial license. In connection with the EC, the EC <b>108</b> may be signed by the ES <b>104</b> using a private key of the ES <b>104</b>.

p-0055In one embodiment, a first portion of information included in the EC <b>108</b> may be used by both the computer <b>102</b> and the LS <b>120</b>. A second portion of the information included in the EC <b>108</b> may be used by just the LS <b>120</b>. As an example that will be illustrated in more detail below, the computer <b>102</b> may read entitlement information related to a required binding type like a hardware identifier binding type. The computer <b>102</b> may generate the binding certificate for the hardware identifier binding type without using a BS <b>110</b>. As such, the computer <b>102</b> may read the binding type included in the EC to see if the computer <b>102</b> should generate the binding certificate or otherwise communicate with the appropriate binding service.

p-0056Referring now to <figref idrefs="DRAWINGS">FIG. 4</figref>, shown is an example representation of an EC <b>108</b>. The example <b>200</b> includes a purchase token <b>204</b>, package information <b>206</b> and entitlements <b>202</b>. The entitlements <b>202</b> may include an unencrypted portion <b>210</b> and an encrypted portion <b>212</b>. The unencrypted portion <b>210</b> may be in a human-readable form, such as plain text. The unencrypted portion may be used by the computer <b>102</b> as well as the LS <b>120</b>. The encrypted portion <b>212</b> may be used only by the LS <b>120</b>. Information included in the unencrypted portion may include the hardware binding type, type of license, date information, number of uses for a use license, number of computers the purchase token is entitled to be activated for, the number of times a single computer may reactivate or repeatedly perform activation for a same license, and the like. As described elsewhere herein, the unencrypted information may be used by the computer <b>102</b> as part of the activation process and also after activation is complete in connection with subsequent program launches or invocations. As described above the computer <b>102</b> may examine the binding type included in portion <b>210</b>. As another example in which the information in <b>210</b> is used by the computer <b>102</b>, a URL or other address information for the LS <b>120</b>, BS <b>110</b>, and the like may be supplied as part of the EC <b>108</b>. As such, the ES <b>104</b> may indicate, using the EC <b>108</b>, different provider sites for the BS and/or LS for different software products. The EC <b>108</b> may also be used to indicate other items which are customized for use in a particular embodiment.

p-0057In one embodiment in which the EC <b>108</b> is an XML document, each entitlement may be represented as an XML attribute. For example, a license type of SUBSCRIPTION, a hardware identifier (denoted HWDID) binding, and a license service URL may be indicated as:

p-0058<License>SUBSCRIPTION</License>

p-0059<Binding>HWDID</Binding>

p-0060<LicenseServiceURL>HTTPS://license.microsoft.com/</LicenseServiceURL>

p-0061It should be noted that the encrypted portion <b>212</b> may be encrypted with the public key of the expected consumer or user of the information in <b>212</b>. In this example, the consumer of the information in <b>212</b> may be the LS <b>120</b>. As such, the ES may encrypt the information in <b>212</b> using the LS's public key which can be decrypted by the LS using the LS's private key. In this way, only the LS <b>120</b> can decrypt and read portion <b>212</b>. Portion <b>212</b> may include information regarding issuance of a license. For example, portion <b>212</b> may indicate to issue a free license every so many days for a particular software product and purchase token.

p-0062Referring back to <figref idrefs="DRAWINGS">FIG. 3</figref>, once the computer <b>102</b> receives the EC <b>108</b>, processing for generating a binding certificate may be performed. As described above, the EC <b>108</b> includes the binding type information which is used by the computer system <b>102</b>. Prior to utilizing information included in the EC <b>104</b>, the computer <b>102</b> may verify the authenticity of the EC <b>108</b> using the public key of the ES <b>104</b>. For example, the ES <b>104</b> may use any one of a variety of different hashing algorithm to generate a hash value for the EC <b>108</b> based on data included therein. The ES <b>104</b> may then encrypt the hash value using the ES's private key and include the encrypted hash value as the ES's digital signature. Upon arrival of the EC <b>108</b> at the computer <b>102</b>, the computer <b>102</b> may generate a first hash value based on the EC using the same hashing technique as the ES <b>104</b>. The computer <b>102</b> may also decrypt the digital signature (the encrypted hash value) using the ES's public key and compare the decrypted digital signature to the computed first hash value. If the values are the same, then the EC verification is successful. The foregoing is an example of how verification of a digitally signed document may be performed by this and other services in connection with verifying a received digitally signed certificate.

p-0063After successfully verifying the EC <b>104</b>, the computer <b>102</b> examines the binding type included in the EC <b>104</b> to determine if the binding type is for a hardware identifier. If so, the computer <b>102</b> may generate the binding certificate (BC) <b>114</b> locally as indicated by element <b>142</b>. Otherwise, an external BS <b>110</b> may be used in generating the BC <b>114</b> as indicated by element <b>140</b>. If the binding type is hardware identifier, the computer <b>102</b> may generate a BC including the hardware identifier or hardware “fingerprint” of the computer <b>102</b>. The BC may then be digitally signed using a private key of the computer <b>102</b>. The private key of the computer <b>102</b> may be included as part of the installation process and stored in a known location on the computer <b>102</b>.

p-0064If the binding type is of another type or than hardware identifier, the appropriate external BS <b>110</b> is utilized. The binding data <b>112</b> as well as the BS may vary with the type of binding. For example, with a TPM binding, a TPM BS may be used. The public key certificate for the TPM of the computer <b>102</b> may be obtained and sent to the BS <b>110</b> for certification. As known in the art, this certification may be performed by a certificate authority (CA) to attest that the public key contained in the certificate belongs to the TPM entity noted in the certificate. If the BS successfully certifies the TPM's public key certificate, the BS <b>110</b> responds by sending a random number to the computer <b>102</b> that is encrypted using the TPM's public key. The computer <b>102</b> having the TPM module therein decrypts the random number using the TPM's private key. The computer then sends to the BS <b>110</b> the encrypted value received from the BS along with the decrypted random number. The BS <b>110</b> responds with a BC <b>114</b> that is digitally signed using the private key of the BS. The BC <b>114</b> includes the random number encrypted with the TPM's public key, and an unencrypted readable form of the random number. It should be noted that the encrypting may use any encryption technique known in the art such as, for example, AES (Advanced Encryption Standard), Triple DES (Data Encryption Standard), RC4 (or ARCFOUR), and the like.

p-0065In connection with other possible binding types, the BC may include appropriate information for the binding type instance and the corresponding BS may perform certification of the binding instance. For example, for a USB or other portable secure device identifier binding type, the BS may certify the USB or other identifier for the binding and generate a BC that is digitally signed by the BS and includes the USB or other identifier associated with the portable secure device. For a user authentication binding type, the BS may certify the user authentication information and generate a BC that is digitally signed by the BS and includes the user authentication information. It should be noted that if the BC includes confidential or sensitive information, such as may be the case with portions of user authentication information, such information may be encoded, encrypted, and the like. For user authentication, the user domain and login name may be stored, or other security identifier (SID) of the operating system for the user.

p-0066Once the computer <b>102</b> has the BC <b>114</b>, the computer <b>102</b> sends the binding and entitlement certificates (EC and BC) <b>122</b> to the LS <b>120</b>.

p-0067Referring to <figref idrefs="DRAWINGS">FIG. 5</figref>, shown is a flowchart of processing steps that may be performed by the LS <b>120</b> in connection with online activation processing. At step <b>252</b>, the LS <b>120</b> verifies the EC and BC using, respectively, the public keys of the ES <b>104</b> and BS <b>110</b>. In the case of a hardware identifier binding type, the BS <b>110</b> is actually the computer <b>102</b> so the computer <b>102</b>'s public key is accordingly used for verification of the BC by the LS <b>120</b>. Otherwise, the public key of the appropriate external BS is used for verification of the BC. The ES's public key may be used for verification of the EC. After both the BC and EC <b>122</b> have been successfully verified, the LS <b>120</b> retrieves the binding type information from the EC and determines whether the BC contains the proper binding type as indicated in the BC in step <b>254</b>. If not, the activation process may terminate with an error condition and message to the computer <b>102</b>. In step <b>256</b>, the number of possible activation bindings and the purchase token are obtained from the EC. In connection with a hardware identifier binding type, the number of possible activation bindings may be the number of computer systems for which licenses may be issued. At step <b>258</b>, a determination is made as to whether there have been any existing licenses issued for the purchase token. In one embodiment, a database <b>120</b><i>a </i>of the LS <b>120</b> may be queried to determine the number of existing licenses already in the database for the purchase token obtained in step <b>256</b> from the EC. If step <b>258</b> evaluates to no, control proceeds to step <b>266</b> to issue a new license. Information regarding the new license issued is recorded in a database <b>120</b><i>a </i>of the LS <b>120</b> for use in connection with other processing steps described herein. The license information recorded includes information regarding each binding instance to which the license is bound for the associated purchase token from step <b>256</b>. For example, for each license issued for a purchase token with respect to a hardware identifier binding, the license service database may associate the hardware identifier of the binding with the purchase token. If the license is bound to a USB key identifier or user authentication information, the corresponding information (e.g., USB key identifier or user authentication information) may be stored in the database and associated with the purchase token. If the license is bound to a TPM instance, a public key certificate for a TPM root of a trusted CA (certificate authority) may be stored. If the license is bound to a user authentication instance, the user's domain and user name or SID may be stored.

p-0068If step <b>258</b> evaluates to yes, control proceeds to step <b>260</b> to determine whether the current activation involves a license reissue. A determination can be made as to whether this is a license reissue by comparing the binding information in the BC, such as the hardware identifier, to information in the license database regarding existing issued licenses. In connection with hardware identifiers bound to an issued license, recall that as described herein, different levels or degrees of tolerance may be used in connection with making a determination as to whether two hardware identifiers match. For example, two hardware identifiers generated for the same computer system may not match exactly if there has been a hardware configuration change, such as a new hard drive installed, memory upgrade, and the like, depending on how the hardware identifiers are generated. Different techniques as described elsewhere herein may be used to determine whether two hardware identifiers are substantially the same and thus identify the same computer system to constitute a license reissuance. If step <b>260</b> determines that this is a license reissue, control proceeds to step <b>266</b> to reissue a license. In connection with reissuance, a new license may be generated based on the current information of the received EC and BC and the license database accordingly updated. With a reissue, the net number of allocated license does not change. If step <b>260</b> evaluates to no, control proceeds to step <b>262</b> to determine whether the number of allowed licenses has already been reached so that issuing another new license would then exceed the maximum allowable number of activations. If step <b>262</b> evaluates to no, control proceeds to step <b>266</b> to issue a new license and record the license information in the license service database as described in connection with other processing steps of <b>250</b>. If step <b>262</b> evaluates to yes, control proceeds to step <b>264</b> and a new license is not issued.

p-0069With respect to the flowchart <b>250</b> processing performed by the license service, possible outcomes are reissuing a license, issuing a new license, or failure to issue a license. The failure may be due to exceeding a number of allowed licenses or other condition, such as a verification failure.

p-0070It should be noted that any encrypted entitlements in the EC may also be decrypted by the LS using the public key of the LS. The decrypted entitlements may be used in connection with license issuance.

p-0071In one embodiment, a license may be a digital certificate including the EC and BC. The license may be signed with the private key of the LS <b>120</b>. The license received from the LS <b>120</b> may be stored on the computer <b>102</b> for subsequent use in connection with launching the software for which the license has been issued.

p-0072As described herein, the ES <b>104</b> generates entitlements included in the EC that may be consumed by the computer <b>102</b> and the LS <b>120</b> depending on the particular entitlement. The entitlements include specification of license characteristics which are then used by the LS <b>120</b> and the computer <b>102</b> in enforcing the license terms and conditions as expressed therein. The foregoing license conditions or terms are enforced by the LS <b>120</b> as part of the license issuing process performed by the LS <b>120</b>. The license conditions or terms are then also enforced by the computer system <b>102</b> each time the software associated with the license (e.g., having the purchase token and package information) is launched or invoked.

p-0073What will now be described is processing that may be performed by the computer <b>102</b> each time the software for which a license has been issued is invoked. The following description is made with respect to a license binding type of hardware identifier although other binding types may be used. It will be appreciated by those skilled in the art that the steps of <b>280</b> may be adapted for use with the different binding types utilized in an embodiment.

p-0074Referring to <figref idrefs="DRAWINGS">FIG. 6</figref>, shown is a flowchart of processing steps that may be performed on a device, such as the computer <b>102</b>, each time software installed thereon is launched or invoked for execution. Processing steps of <b>280</b> determine if execution of the software on the computer is in accordance with a valid license previously generated using the online activation processing. Prior to executing steps of flowchart <b>280</b>, a license may be located on the device. In one embodiment, the license may be stored in a particular location, such as a directory, file, and the like. If no license is found in the expected location, the software launch is terminated. Processing of <b>280</b> proceeds after a license is determined to be on the computer <b>102</b>.

p-0075At step <b>282</b>, the license signature is verified using the public key of the LS as described elsewhere herein, for example, in connection with verification of the EC <b>108</b> which is digitally signed by the ES <b>104</b> and received by the computer <b>102</b>. At step <b>284</b>, the computer <b>102</b> generates a new hardware identifier based on the current hardware configuration of the computer system <b>102</b>. At step <b>286</b>, the generated hardware identifier from step <b>284</b> is compared to the hardware identifier in the BC to ensure that the two are considered a match. As described elsewhere herein, such a determination may be made with respect to an acceptable tolerance or degree of difference so that a determination is made as to whether the two hardware identifiers are substantially the same identifying the same computer. Unsuccessful verification of step <b>286</b> may indicate that the license was issued for a computer different than the computer upon which the software launch is currently being attempted and the software is not allowed to execute. The execution may terminate with an error message regarding the failure and to suggest contacting a vendor or supplier of the software for assistance. At step <b>288</b>, verification processing is performed to ensure that the purchase token of the EC matches the purchase token as stored from the previous activation process. At step <b>290</b>, processing may be performed in accordance with entitlements in the EC appropriate for launch verification. Step <b>290</b> may include performing processing in accordance with one or more entitlements and taking an action in response such as entering a dialogue with a user or other actions. For example, step <b>290</b> processing may use date information expressed in the entitlements to determine if a license has expired, is being launched in accordance with a specified starting date, and the like. If the license has expired, the user may be prompted with a dialogue inquiring whether the user wants to renew the license. If the user indicates via a user input or selection that he/she wants to renew, the computer <b>102</b> may be connected to a website to begin the renewal process. If the license is based on a number of uses, such as 1000 invocations after which the license expires, a message may be displayed upon each invocation indicating the current use number and the number of remaining invocations. If the license has a license expiration data, a message may be displayed to the user to indicate that license will expire in MM days if the current date is within a predefined time period from the license expiration date. Information regarding the license may be recorded on the user computer <b>102</b> and used in connection with subsequent invocations. Such information may be stored in a known location in a directory, file, registry setting, and the like, on the computer <b>102</b>. Such information may include, for example, the current number of invocations or uses for a particular software application.

p-0076If verification process of steps <b>286</b>, <b>288</b>, and/or <b>290</b> is unsuccessful, the current attempt to execute the software fails and may terminate with an appropriate message, further instructions, and the like.

p-0077As described herein, different binding types besides the hardware identifier may be used in an embodiment. If the binding type is TPM, steps <b>284</b> and <b>286</b> may be replaced with processing related to the TPM instance. As described elsewhere herein for a TPM, the BC may include a random number which is both encrypted and also in an unencrypted form, such as readable text. The encrypted random number has been encrypted using a public key of the TPM. For each program launch, the computer <b>102</b> may decrypt the encrypted random number using the private key of the TPM and compare the decrypted result to the unencrypted random number included in the BC. If the two decrypted random number matches the unencrypted random number of the BC, then the license was issued for the TPM included on the computer <b>102</b>, step <b>286</b> verification processing is successful, and the launched software is allowed to execute. Otherwise, step <b>286</b> using the TPM binding instance fails. If the binding type is USB identifier, then step <b>284</b> obtains the USB identifier of the current USB device plugged into the computer upon which execution is being attempted. At step <b>286</b>, the current USB identifier is compared to the USB identifier of the license as included in the BC. If the two match, then the license was issued for the USB identifier of the device currently plugged into the computer <b>102</b>. Otherwise, step <b>286</b> using the USB identifier instance fails. If the binding type is user authentication information, step <b>284</b> obtains the current user authentication information for the user currently logged into the computer upon which execution is being attempted. At step <b>286</b>, the current user authentication information is compared to the user authentication information of the license as included in the BC. If the two match, then the license was issued for the current user authentication information. Otherwise, step <b>286</b> fails.

p-0078The foregoing describes processing for an online activation mode when the computer <b>102</b> has computer connectivity to the one or more servers including the various services. As an alternative, activation processing in one embodiment may be performed using an offline activation mode.

p-0079Referring to <figref idrefs="DRAWINGS">FIG. 6A</figref>, shown is an example representation of a license database. The example <b>700</b> illustrates information as may be included in the license database of the LS <b>120</b> of <figref idrefs="DRAWINGS">FIG. 3</figref>. The license database <b>702</b> may be logically organized so that for a given purchase token <b>704</b>, corresponding license information <b>706</b> may be retrieved. The license information <b>706</b> identifies the licenses issued for a given purchase token. The example <b>700</b> illustrates in further detail how the license database <b>702</b> may be logically organized and also includes examples of license information <b>706</b>. The purchase tokens are included in column <b>710</b>. The database <b>702</b> may include one or more records of information for a given purchase token. The license information is described in columns <b>712</b> and <b>714</b>. In this example, more than one type of binding may be allowed for each purchase token so the different binding types for a given purchase token are indicated in column <b>712</b>. Column <b>714</b> includes the binding instances for which licenses have been generated. Element <b>722</b> identifies licensing information in the licensing database for first purchase token “Purchase token 1”. Licenses for Purchase token <b>1</b> have been issued for two binding types—hardware identifier (HDWID) and USB identifier (USB ID)—as indicated in <b>712</b>. Two licenses have been issued for Purchase token <b>1</b>. Each license is bound to one of the hardware identifier binding type instances HWDID<b>1</b> and HWDID<b>2</b>. One license has been issued for Purchase token <b>1</b> which is bound to the USB identifier binding type instance USBID<b>1</b>. Licenses for Purchase token <b>2</b> are included in <b>724</b>. Licenses have been issued for the hardware identifier (HDWID) binding type as indicated in <b>712</b>. Two licenses have been issued for Purchase token <b>2</b>. Each license is bound to one of the hardware identifier binding type instances HWDID<b>3</b> and HWDID<b>4</b> of column <b>714</b>.

p-0080It will be appreciated by those skilled in the art that the example <b>700</b> presents only one possible representation and organization of the license database that may be used in an embodiment. Additionally, other information than as included in the example <b>700</b> may also be included in the license database and may vary with possible binding types.

p-0081Referring to <figref idrefs="DRAWINGS">FIG. 7</figref>, shown is an example illustrating the offline activation processing that may be performed using techniques herein. The example <b>300</b> includes an offline activation service (OAS) <b>302</b> and a CSR/IVR system <b>332</b>. In connection with the offline activation mode, only the hardware identification type binding may be supported. As with the online activation mode, the software being activated is installed on a device <b>336</b>. In this example, the device <b>336</b> may be a computer which does not have connectivity to the server(s) providing the services as described in connection with the online activation mode. The user performing the activation process may initially contact the CSR/IVR system <b>332</b> and provide an installation identifier <b>310</b>. The installation identifier may include one or more components and may be generated by the device <b>336</b> as part of the installation process. As part of the installation process, the user may be asked whether he/she wants to activate using the online or offline activation mode. If the offline mode is selected, the user may be provided with an installation identifier. In one embodiment, the installation identifier may be formed from a hardware identifier for the device <b>336</b>, the package information for the software installed for which activation is being performed, and the purchase token for the software. Software on the device <b>336</b> may be executed to form the hardware identifier. The purchase token and package information may be entered as part of the installation dialogue. The purchase token, package information, and hardware identifier may be stored on the device <b>336</b> for use in connection with verification processing when subsequently launching the program for which activation is being performed.

p-0082<figref idrefs="DRAWINGS">FIG. 8</figref> shows an example representation of an installation identifier that may be used in an embodiment. The installation identifier of the example <b>400</b> may be formed by concatenating the hardware identifier (HWDID) <b>402</b> with the package information <b>406</b> and purchase token <b>404</b> for the software for which activation is being performed. The hardware identifier <b>402</b> may be any one of a variety of different hardware identifiers identifying the hardware of the device <b>336</b>. In one embodiment, the hardware identifier may be a compact hardware identifier (CHWID) as described in U.S. Publication No. 2004/0177354. The CHWID may be formed from a larger, more verbose, hardware identifier (VHWID). The VHWID may be formed from a set of “n” hardware classes. Each class may identify a class of hardware components such as, for example, a hard drive, network card, CPU, and the like, as described elsewhere herein. For each class, a first hash value may be formed for each component class based on the particular components of each class for the device <b>336</b>. For example, an identification string may be formed based on the particular hard drive or CPU in a computer. The string may identify the manufacturer and other information unique to the computer's CPU or hard drive (e.g., “INTEL 989709789798”). A first hash value may be formed for the string identifier. The resulting first hash values for each of the “n” components classes may be concatenated to form the VHWID. The CHWID may be formed by identifying a subset “q” of the “n” classes used for the VHWID. A second hash function may be applied to each of the first hash values for those selected “q” classes to generate “q” second hash values. The “q” second hash values may then be concatenated and used as the CHWID. In connection with performing the hashing for both the first and second hash values, any one of a variety of hashing functions may be used such as, for example, SHA-1, MD5, and the like. Both the VHWID and the CHWID may be formed using code executed on the device <b>336</b>. The resulting CHWID, or VHWID from which the CHWID is formed, may be stored on the device <b>336</b> for later use in connection with performing verification processing when launching the software for which activation is being performed. The CHWID may be used as the hardware identifier component <b>402</b> used in forming the installation identifier although other techniques may be used to generate <b>402</b>.

p-0083The installation identifier <b>310</b> may be a string of alphanumeric characters encoded as decimal digits which are entered over the phone or otherwise communicated to CSR/IVR System <b>332</b>. In one embodiment, the installation identifier may be 128 bits although other sizes may be used. The size of the installation identifier may vary with each embodiment and the size of each of the components (e.g., hardware identifier, purchase token, and package information) used in forming the installation identifier. The system <b>332</b> then provides the installation identifier <b>310</b> to the OAS <b>302</b>. The OAS may be a computer system connected to the CSR/IVR <b>332</b>. Code executing on the OAS <b>302</b> may parse the installation identifier <b>310</b> to extract the purchase token and package information <b>306</b> therefrom.

p-0084<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates how the OAS <b>302</b> may parse the installation identifier <b>310</b> in accordance with configuration data <b>452</b>. The configuration data <b>452</b> may indicate the various fields of the layout or data format of the installation identifier as illustrated in <figref idrefs="DRAWINGS">FIG. 8</figref>. The configuration data <b>452</b> may indicate which fields of the installation identifier are extracted to obtain the purchase token and package information. The configuration data may indicate the appropriate number of bits to extract as well as the starting or offset bit position for the extraction. In one embodiment, the configuration data file <b>452</b> may include a record for each field of the layout of the installation identifier. Each record may indicate a number of bits <b>454</b>, a tag <b>456</b>, and an indicator <b>458</b>. The number of bits <b>454</b> may indicate the size in bits of the field. The tag <b>456</b> may be a text string identifying the particular field. The indicator <b>458</b> may be a flag indicating whether to extract the field for transmission to the ES.

p-0085Referring back to <figref idrefs="DRAWINGS">FIG. 7</figref>, the OAS <b>302</b> extracts the purchase token and package information <b>306</b> and sends the information <b>306</b> to the ES <b>304</b>. The ES <b>304</b> generates a digitally signed EC <b>308</b> as described elsewhere herein in connection with the online activation mode. The EC <b>308</b> is sent to the OAS <b>302</b> which verifies the EC <b>308</b> using the public key of the ES <b>304</b>. The OAS <b>302</b> then generates a BC <b>334</b> using its own private key and the hardware identifier included in a portion of the installation identifier. The BC <b>334</b> includes the hardware identifier and is digitally signed using the private key of the OAS <b>302</b>. The OAS <b>302</b> sends the BC and EC <b>322</b> to the LS <b>320</b> to obtain a license <b>330</b>. The LS <b>320</b> performs processing as described elsewhere herein in connection with the online activation mode for hardware identifiers. The possible outcomes of LS <b>320</b> processing are described above and may include generating a license <b>330</b> which is then sent to the OAS <b>302</b>. As described elsewhere herein in connection with the online activation mode, the license <b>330</b> may contain the BC and EC. The license may be digitally signed using the private key of the LS <b>320</b>. The OAS <b>302</b> performs processing to determine if it received a valid license from the LS <b>320</b>.

p-0086Referring to <figref idrefs="DRAWINGS">FIG. 10</figref>, shown is a flowchart of processing steps that may be performed in an embodiment by the OAS <b>302</b> in processing a received license <b>330</b>. At step <b>502</b>, license signature may be verified. The license may be signed with the private key of the LS. Similar to as described elsewhere herein in connection with other digital signatures generated using a private key, a corresponding public key may be used to verify the digital signature. A step <b>502</b>, the LS public key is used in verification. At step <b>504</b>, verification processing may be performed to determine whether the purchase token of the license matches the purchase token as included in the installation identifier. At step <b>506</b>, verification processing of the BC may be performed. Step <b>506</b> may include comparing the hardware identifier of the BC to the hardware identifier as included in the installation identifier. At step <b>508</b>, the confirmation identifier may be generated if all previous verification processing of steps <b>502</b>, <b>504</b> and <b>506</b> has completed successfully.

p-0087Referring to <figref idrefs="DRAWINGS">FIG. 11</figref>, shown is an example representation of fields of a confirmation identifier. The confirmation identifier <b>600</b> includes an OAS generated data portion <b>602</b> and an encrypted hash value <b>604</b>. The portion <b>602</b> may be generated by the OAS and based on the various entitlements included in the EC. The portion <b>602</b> may be characterized as a representation of the various licensing terms and conditions of the license. As part of generating the confirmation identifier, the OAS retrieves the entitlements of the EC and accordingly forms the portion <b>602</b>. In one embodiment, the portion <b>602</b> may be 30 bits in size encoding various entitlements of the EC. For example, the portion <b>602</b> may include 3 bits representing the type of license, 7 bits representing the license expiration date, 7 bits representing a license start date, and the like. The size of the confirmation identifier may vary with embodiment. For example, an embodiment may use a confirmation identifier which is 114 bits having a field <b>604</b> which is 83 bits and a field <b>602</b> which is 31 bits.

p-0088The confirmation identifier in the example <b>600</b> also includes an encrypted hash value <b>604</b>. Any one of a variety of different techniques may be used in connection with generating the hash value <b>604</b>. For example, in one embodiment, the hash value <b>604</b> may be formed using the installation identifier and the data portion <b>602</b>. The installation identifier and data portion <b>602</b> may have a hashing algorithm applied to generate a hash value. The hashing technique may be any one of a variety of different ones known in the art and as described elsewhere herein. The hash value may then be encrypted using any one of a variety of different techniques and stored as the hash value <b>604</b>. In one embodiment, the hash value may be encrypted using the private key of the OAS which is then decrypted later on by the device <b>336</b> in connection with subsequent program launches and associated verification processing. As another example, the hash value may be encrypted using the encryption technique described in U.S. Pat. No. 7,020,776, Lauter et al, CRYPTOSYSTEM BASED ON A JACOBIAN OF A CURVE, Mar. 28, 2006.

p-0089Other data may be used in forming the confirmation identifier besides the portion <b>602</b> and installation identifier. The data from which the hash value <b>604</b> is produced may be indicated in the entitlements of the EC. For example, the EC may indicate portions of <b>602</b> and/or portions of the installation identifier, as well as other values, from which hash value <b>604</b> is generated. The EC may indicate, for example, the number of days for which to issue a license, a number of machines allowed to be activated for a particular license, and the like. Other examples of information that may be communicated in the EC are described elsewhere herein.

p-0090Once the confirmation identifier <b>312</b> is formed by the OAS <b>312</b>, the OAS <b>312</b> communicates the confirmation identifier <b>312</b> to the CSR/IVR system <b>332</b>. The system <b>332</b> communicates the confirmation identifier <b>312</b> to the user. The user may then enter the confirmation identifier <b>312</b>, such as with an input device, on the device <b>336</b>. The confirmation identifier <b>312</b> may be stored on the device <b>336</b> for use in connection with subsequent program launches. The installation identifier <b>310</b> may also be stored on the device <b>336</b> for use in connection with subsequent program launches. In one embodiment, the installation identifier <b>310</b> and the confirmation identifier <b>336</b> may be concatenated and stored as a single data item on the device <b>336</b>.

p-0091As described above, the license generated from the online activation mode may be used with program launch in performing verification processing to determine whether to allow the program execution to proceed. As will be described in more detail below, the confirmation identifier generated from the offline activation mode may also be used in performing verification processing to determine whether to allow the program execution to proceed.

p-0092Referring to <figref idrefs="DRAWINGS">FIG. 12</figref>, shown is a flowchart of processing steps that may be performed in an embodiment of a device, such as a computer, when attempting to execute software on the device. The software may be installed on the computer and either the online or offline activation processing performed to generate, respectively, a license or confirmation identifier. At step <b>802</b>, the software program is launched or invoked. At step <b>804</b>, a determination is made as to whether online activation has previously been performed. The computer may make the determination by examining the contents of a location on the computer which is expected to contain the license if online activation had been successfully performed. For example, the license may be stored in a particular directory, file, and the like. If the license is in the expected location, step <b>804</b> may evaluate to yes and control proceeds to step <b>806</b> to perform verification processing associated with program launching for online activation as described elsewhere herein. For example, such processing is described in connection with <figref idrefs="DRAWINGS">FIG. 6</figref>. If step <b>804</b> evaluates to no, control proceeds to step <b>808</b> where the installation identifier and confirmation identifier may be retrieved. The installation identifier and confirmation identifier may be stored in a known location similar to that as described with the license. If the installation and confirmation identifiers are located, step <b>810</b> evaluates to yes and control proceeds to step <b>812</b> to perform verification processing associated with program launching for offline activation as described in more detail in following paragraphs. Otherwise, step <b>810</b> evaluates to no and control proceeds to step <b>814</b> to terminate processing with the appropriate error message. The program is not allowed to execute in connection with step <b>814</b>.

p-0093Referring to <figref idrefs="DRAWINGS">FIG. 13</figref>, shown is a flowchart of processing steps that may be performed in an embodiment in connection with execution of installed software on a device, such as a computer. The flowchart <b>900</b> illustrates processing that may be performed in connection with step <b>812</b> of <figref idrefs="DRAWINGS">Figure 800</figref> when information on the computer system is located which is associated with having previously performed offline activation processing. It should be noted that if any of the verification processing of step <b>904</b>, <b>906</b>, <b>908</b>, or <b>912</b> fails, the software is not allowed to execute and processing may terminate with an appropriate message. At step <b>902</b>, a current hardware identifier based on the hardware of the computer upon which the software launch is performed in step <b>802</b>. The same technique used to generate the hardware identifier previously included in the installation identifier is used. At step <b>904</b>, verification processing is performed to ensure that the current hardware identifier of step <b>902</b> matches the hardware identifier of the stored installation identifier. As described elsewhere herein, different techniques may be used to determine whether the two hardware identifiers are substantially the same to indicate the same computer system. For example, if the hardware identifier is the CHWID as described elsewhere herein, the CHWID may be formed as a concatenated set of hash values in which each hash value corresponds to a particular hardware component class. The hash values vary with the particular hardware for each class as included in the configuration of the computer system. A tolerance level may be introduced by having a threshold number of hash value matches between the current hardware identifier and the hardware identifier of the installation identifier. The threshold value may be some number, m, ≦q, the number of hash values and corresponding classes of the CHWID. The number selected for m may vary with an acceptable level of tolerance or variation in configuration of a computer system. At step <b>906</b>, verification processing is performed to ensure that the stored purchase token and package information as previously entered during installation matches those of the stored installation identifier. At step <b>908</b>, verification processing may be performed for the encrypted hash value of the confirmation identifier using the encrypted hash value portion <b>604</b>. A decrypted hash value is generated for <b>604</b> using the public key of the OAS as stored on the computer. The public key may be stored, for example, as part of a previous installation of the software. The computer may perform processing as described elsewhere herein to generate a new hash value based on the stored installation identifier and data portion of the stored confirmation identifier. The new hash value is generated using the same technique as used by the OAS to generate portion <b>604</b>. If the decrypted hash value matches the new hash value, then verification processing is successful. Otherwise, verification processing of step <b>908</b> fails. At step <b>910</b>, the data portion <b>602</b> of the confirmation identifier stored on the computer may be extracted and decoded to determine the license characteristics. As described elsewhere herein, different entitlements describing license characteristics, such as license type, expiration date, and the like, may be encoded in the data portion of the confirmation identifier. The decoding of step <b>910</b> determines the license characteristics. Control then proceeds to step <b>912</b> where the license characteristics are used in connection with verification processing to ensure that a valid license exists. In connection with offline processing, the confirmation identifier is used rather than the license as in connection with online processing. The confirmation identifier is a different representation of the license characteristics. Step <b>912</b> processing may include, for example, determining the license expiration date and start date from the appropriate bits of the data portion <b>602</b> of the confirmation identifier. The current date is compared to both the start date and expiration date to determine if the software may be executed in accordance with the license characteristics.

p-0094Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.