Abstract:
Software revalidation or invalidation. In one example embodiment, one or more non-transitory computer-readable media may store one or more programs that cause one or more processors to execute a method for software revalidation or invalidation that may include newly collecting machine configuration information from a machine on which a software application has previously been installed and activated and applying, at the machine, activation rules to the newly-collected machine configuration information from the machine to determine whether a product key remains valid for the newly-collected machine configuration information. In response to determining that the product key remains valid for the newly-collected machine configuration information, the method may include revalidating, at the machine, the software application to authorize continued access to the software application. Alternatively, the method may include invalidating, at the machine, the software application to prevent continued access to the software application.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 15/095,977, filed Apr. 11, 2016, which is a continuation of U.S. patent application Ser. No. 14/868,087, filed Sep. 28, 2015, now U.S. Pat. No. 9,424,404, which is a continuation of U.S. patent application Ser. No. 14/611,504, filed Feb. 2, 2015, now U.S. Pat. No. 9,171,138, which is a continuation of U.S. patent application Ser. No. 14/308,302, filed Jun. 18, 2014, now U.S. Pat. No. 8,997,249, each of which is incorporated herein by reference in its entirety. 
     
    
     FIELD 
       [0002]    The embodiments disclosed herein relate to software revalidation or invalidation. 
       BACKGROUND 
       [0003]    Software activation is a license validation procedure required by some proprietary computer software applications. In general, software activation is used to verify the authenticity of a product key and to ensure that the product key is not being used for multiple installations. Upon activation, the software application generally obtains a license that authorizes continued access to the software application by a user on the user&#39;s machine for the lifetime of the license. 
         [0004]    One common problem associated with software activation involves a user activating a software application on a machine having an initial configuration, and then later attempting to use the license on the same machine but with an updated configuration. For example, a user may initially install a software application on a machine running a lower-priced operating system, and then after activation of the software application the user may upgrade the machine to run a higher-priced operating system. Even though activation of the software application on the higher-priced operating system would require a more expensive license, the user may be able to circumvent paying for the more expensive license by using the less expensive license that was already obtained during the prior software activation, notwithstanding the operating system upgrade. 
         [0005]    The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced. 
       SUMMARY 
       [0006]    In general, example embodiments described herein relate to software revalidation or invalidation. The example methods disclosed herein may be employed to apply activation rules to newly-collected machine configuration information in order to determine whether a product key remains valid for the present configuration of the machine on which a software application is installed. Where the product key remains valid, the software application is revalidated, and otherwise the software application is invalidated. In this manner, the example methods disclosed herein may employ activation rules that were current at the time of the software activation, or in some embodiments activation rules that have been updated subsequent to the software activation, to revalidate or invalidate a software application, thus preventing an originally valid software application from subsequently being employed by a user in an unauthorized manner. 
         [0007]    In one example embodiment, one or more non-transitory computer-readable media may store one or more programs that cause one or more processors to execute a method for software revalidation that may include newly collecting machine configuration information from a machine on which a software application has previously been installed and activated, applying, at the machine, activation rules to the newly-collected machine configuration information from the machine to determine whether a product key remains valid for the newly-collected machine configuration information, and in response to determining that the product key remains valid for the newly-collected machine configuration information, revalidating, at the machine, the software application to authorize continued access to the software application. 
         [0008]    In another example embodiment, one or more non-transitory computer-readable media may store one or more programs that cause one or more processors to execute a method for software invalidation that may include newly collecting machine configuration information from a machine on which a software application has previously been installed and activated, applying, at the machine, activation rules to the newly-collected machine configuration information from the machine to determine whether a product key remains valid for the newly-collected machine configuration information, and in response to determining that the product key does not remain valid for the newly-collected machine configuration information, invalidating, at the machine, the software application to prevent continued access to the software application. 
         [0009]    It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]    Example embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: 
           [0011]      FIG. 1  is a schematic block diagram illustrating an example software activation and revalidation system; and 
           [0012]      FIGS. 2A-2B  are a schematic flowchart diagram of an example method for software activation and revalidation. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0013]      FIG. 1  is a schematic block diagram illustrating an example software activation and revalidation system  100 . As disclosed in  FIG. 1 , the example system  100  includes a local machine  102  and a remote activation server  104 . The example system  100  may also optionally include a local intermediate computer  106 . The local machine  102  and/or the intermediate computer  106  are able to communicate with the remote activation server  104  over a network  108 . The local machine  102  includes an activation module  114 , the remote activation server  104  includes an activation module  116 , and the intermediate computer  106  includes an activation module  118 . 
         [0014]    The local machine  102  may be any computing device capable of having a software application  112  installed thereon. For example, the local machine  102  may be a physical computer such as a file server, a web server, a personal computer, a desktop computer, a laptop computer, a handheld device, a multiprocessor system, a microprocessor-based or programmable consumer electronic device, a smartphone, a digital camera, a hard disk drive, a flash memory drive, or some combination thereof. The local machine  102  may also be a virtual computer such as a virtual machine. The local machine  102  may also include an operating system  110 . The network  108  may be any wired or wireless communication network including, for example, a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a Wireless Application Protocol (WAP) network, a Bluetooth® network, an Internet Protocol (IP) network such as the Internet, or some combination thereof. 
         [0015]    During performance of the example methods disclosed herein, the activation module  114  may collect a product key and machine configuration information from the local machine  102  prior to, during, or subsequent to the installation of the software application  112 . The activation module may then send the product key and the machine configuration information to the activation module  116  of the remote activation server  104 , either directly over the network  108  or via the activation module  118  of the intermediate computer  106 . The activation module  116  may then apply activation rules  120  stored at the remote activation server  104  to determine whether the product key is valid for the machine configuration information. If the product key is valid for the machine configuration information, the activation module  116  may activate the software application  112  by sending license data, such as a signed license file  122  and the activation rules  120 , to the activation module  114  of the local machine  102 , either directly over the network  108  or via the activation module  118  of the intermediate computer  106 . The signed license file  122  may authorize access to the software application  112 . Subsequent to the software activation, the activation module  114  may periodically apply the local copy of the activation rules  120  to newly-collected machine configuration information from the local machine  102  to determine if the product key remains valid for the newly-collected machine configuration information. Where the product key remains valid, the activation module  114  may revalidate the license data. Otherwise, the activation module  114  may invalidate the license data. In this manner, the example methods disclosed herein can employ the activation rules  120  that were current at the time of the software activation, or in some embodiments even more current, to revalidate or invalidate license data, thus preventing an originally valid license from subsequently being employed by a user in an unauthorized manner. 
         [0016]    Although only a single intermediate computer  106  is disclosed in  FIG. 1 , it is understood that more than one intermediate computer may be employed to facilitate communication between the local machine  102  and the remote activation server  104 . The use of one or more intermediate computers may be advantageous where the local machine  102  is an offline computer that is not directly accessible to the remote activation server through any network such as the network  108 . Further, although the activation rules  120  are disclosed in  FIG. 1  as being separate from the signed license file  122 , it is understood that in some embodiments the activation rules  120  may be contained in the signed license file  122 . In these embodiments, the signing of the signed license file  122  may be configured to prevent a user of the local machine  102  from undetectably altering its contents, including the activation rules  120  contained in the signed license file  122 . In particular, the signing of the signed license file  122  may be accomplished creating a digital signature using a private key in a key pair which is only known to the activation module  116 , for example, and appending, prepending, and/or otherwise associating the digital signature to or with the signed license file  122 . This signing then enables the activation module  114  to detect, using a public key in the key pair which is known to the activation module  114 , if any changes have been made to the contents of the signed license file  122 . If the contents of the signed license file  122  have been altered, such as by a user trying to enhance the license contained in the signed license file  122  or modify the activation rules  120  contained in the signed license file  122 , for example, then the alteration may be detected by the activation module  114  because the digital signature will no longer be valid, and the activation module  114  may then treat the signed license file  122  as invalid. Also, although the activation module  114  is disclosed in  FIG. 1  as being separate from the software application  112 , it is understood that in at least some embodiments the activation module  114  may be contained in the software application  112 . Further, although the activation modules  114 ,  116 , and  118  are the only modules disclosed in the example system  100  of  FIG. 1 , it is understood that the functionality of the activation modules  114 ,  116 , and  118  may be replaced or augmented by one or more similar modules residing on the local machine  102 , the remote activation server  104 , the intermediate computer  106 , or another machine or system. 
         [0017]    Having described one specific environment with respect to  FIG. 1 , it is understood that the specific environment of  FIG. 1  is only one of countless environments in which the example methods disclosed herein may be practiced. The scope of the example embodiments is not intended to be limited to any particular environment. 
         [0018]      FIGS. 2A-2B  are a schematic flowchart diagram of an example method  200  for software activation and revalidation. The method  200  may be implemented, in at least some embodiments, by the activation modules  114  and  116 , and optionally  118 , of the example system  100  of  FIG. 1 . For example, the activation modules  114  and  116 , and optionally  118 , may be configured to execute computer instructions to perform operations of activation of the software application  112  and subsequent and periodic revalidation of license data associated with the activation of the software application  112 , as represented by one or more of steps  202 - 238  of the method  200 . Although illustrated as discrete steps, various steps may be divided into additional steps, combined into fewer steps, or eliminated, depending on the desired implementation. The method  200  will now be discussed with reference to  FIGS. 1 and 2A-2B . 
         [0019]    The method  200  may include a step  202  in which a software application is installed on a local machine. For example, a user of the local machine  102  may, at step  202 , install, or at least partially install, the software application  112  on the local machine  102 . This installation may also include the installation of the activation module  114 , which may be part of the software application  112  or may be a separate module, as disclosed in  FIG. 1 . 
         [0020]    The method  200  may include a step  204  in which machine configuration information is collected. For example, the activation module  114  may, at step  204 , collect machine configuration information from the machine on which the software application  112  is installed, which is the local machine  102  in  FIG. 1 . The machine configuration information may include a variety of information associated with the local machine  102  including, but not limited to, information regarding the operating system  110  installed on the local machine  102 , information regarding other software applications installed on the local machine  102 , hardware installed on the local machine  102 , whether the local machine  102  is a physical computer or a virtual computer, or some combination thereof. This collecting of machine configuration information may also include collecting a product key associated with the software application  112 . The product key may be collected using the software application  112 , or using a product installer executable associated with the software application  112 , such as by prompting a user to enter the product key during installation of the software application  112  or after the expiration of a free trial period subsequent to the software installation. 
         [0021]    The method  200  may include a step  206  in which the machine configuration information and the product key are sent and a step  208  in which the machine configuration information and the product key are received, as well as an optional step  210  in which the machine configuration information and the product key are passed along. For example, the activation module  114  of the local machine  102  may, at step  206 , send the machine configuration information and the product key and the activation module  116  of the remote activation server  104  may, at step  208 , receive the machine configuration information and the product key. Also, the machine configuration information and the product key may first be transferred to the activation module  118  of the intermediate computer  106 , via a local connection or manually using a storage device, for example, after which the activation module  118  of the intermediate computer  106  may, at optional step  210 , send the machine configuration information and the product key to the activation module  116  of the remote activation server  104 . The intermediate computer  106  may be employed in situations where the local machine  102  is not online and not capable of communicating directly with the remote activation server  104 , for example. 
         [0022]    The method  200  may include a decision step  214  in which it is determined whether the product key is valid for the machine configuration information. For example, the activation module  116  of the remote activation server  104  may, at decision step  214 , apply the current activation rules  120  to the machine configuration information and the product key that were received at step  208  to determine whether the product key is valid for the machine configuration information. The activation rules  120  may map, for example, certain product keys to certain authorized machine configurations. In one example embodiment, the activation rules  120  may specify particular operating systems that are authorized for particular product keys. Where the machine configuration information includes information regarding the operating system  110  of the local machine  102 , the activation module  116  may apply the activation rules  120  by checking whether the operating system  110  is listed in the mapping as being authorized for the particular product key. 
         [0023]    If it is determined at decision step  214  that the product key is not valid for the machine configuration information (No at step  214 ), then the method  200  may include a step  216  in which an invalid product key message is sent and a step  218  in which the invalid product key message is received, as well as an optional step  220  in which the invalid product key message is passed along. For example, the activation module  116  of the remote activation server  104  may, at step  216 , send an invalid product key message and the activation module  114  of the local machine  102  may, at step  218 , receive the invalid product key message. Also, the invalid product key message may first be transferred to the activation module  118  of the intermediate computer  106 , via the network  108 , after which the activation module  118  of the intermediate computer  106  may, at optional step  220 , send, via a local connection or manually using a storage device for example, the invalid product key message to the activation module  114  of the local machine  102 . In addition, the invalid product key message may be presented to a user, during optional step  220  at the intermediate computer  106  and/or during step  218  at the local machine  102 . For example, the invalid product key message may be displayed on a visual display of the intermediate computer  106  and/or on a visual display of the local machine  102 . 
         [0024]    If it is determined at decision step  214  that the product key is valid for the machine configuration information (Yes at step  214 ), then the method  200  may include a step  222 , in which license data is sent and a step  224  in which the license data is received and access to the software application is authorized, as well as an optional step  226  in which the license data is passed along. For example, the software application  112  may be activated by the activation module  116  of the remote activation server  104 , at step  222 , sending license data and the activation module  114  of the local machine  102 , at step  224 , receiving the license data that authorizes access to the software application  112 . This activation of the software application  112  may include analysis by the activation module  114  of the local machine  102  of the license data to determine that the activation has been authorized by the activation module  116  of the remote activation server  104 . As noted elsewhere herein, the license data may include the signed license file  122  and/or the activation rules  120 , as separate data or the signed license file  122  may contain the activation rules  120 . Also, the license data may first be transferred to the activation module  118  of the intermediate computer  106 , via the network  108 , after which the activation module  118  of the intermediate computer  106  may, at optional step  226 , send, via a local connection or manually using a storage device for example, the license data to the activation module  114  of the local machine  102 . 
         [0025]    Continuing with the above example, by the conclusion of step  224  the software application  112  that was installed on the local machine  102  will be activated. In addition, in at least some embodiments the license data received at the local machine  102  at the time of activation will include the current activation rules  120  from the remote activation server  104 . This reception of the activation rules  120  that are current at the time of the software activation may enable periodic revalidation of the software application  112 , as discussed below in decision step  234 , using the activation rules  120  that are more current than any activation rules that may have been included with the files that were used to install the software application  112 , such as the files included in a product installer executable. The activation rules  120  stored on the remote activation server  104  may be more current because the activation rules  120  may require periodic updates to account for, among other things, updates to the software application  112 , new or updated operating systems, other new or updated software applications, new or updated hardware, new or updated virtual machines or hypervisors, or some combination thereof. For example, when a new version of the operating system  110  is released, which can be a fairly common occurrence, the activation rules  120  on the remote activation server  104  may be updated to account for the new version in the mappings of certain product keys to certain authorized machine configurations. Where updated activation rules  120  can be sent to the local machine  102  at the time of software activation, a new product installer executable with updated activation rules for the software application  112  may no longer need to be released each time that a new version of the operating system  110  is released. Further, where the capability exists for the local machine  102  to periodically communicate with the remote activation server  104 , the activation rules  120  may be periodically updated subsequent to the time of the software activation, as discussed below in optional steps  228 - 232 . 
         [0026]    The method  200  may include an optional step  228  in which updated license data is sent and an optional step  230  in which the updated license data is received, as well as an optional step  232  in which the updated license data is passed along. For example, the activation module  116  of the remote activation server  104  may, at optional step  228 , send updated license data and the activation module  114  of the local machine  102  may, at optional step  230 , receive the updated license data. As noted elsewhere herein, the updated license data may include an updated signed license file  122  and/or the updated activation rules  120 . Also, the updated license data may first be transferred to the activation module  118  of the intermediate computer  106 , via the network  108 , after which the activation module  118  of the intermediate computer  106  may, at optional step  232 , send, via a local connection or manually using a storage device for example, the updated license data to the activation module  114  of the local machine  102 . 
         [0027]    The method  200  may include decision step  234  in which it is determined whether the product key remains valid for newly-collected machine configuration information. For example, the activation module  114  of the local machine  102  may, at decision step  234 , apply the activation rules  120  that were received by the local machine  102  at step  224  or optional step  230  as part of the license data to newly-collected machine configuration information from the local machine  102  to determine if the product key remains valid for the newly-collected machine configuration information. Decision step  234  may be accomplished by the activation module  114  of the local machine  102  in a similar manner as decision step  214  is accomplished by the activation module  116  of the remote activation server  104 , except that the activation rules  120  used in decision step  234  will be stored local to the local machine  102 , and may be more current than the activation rules  120  that were used during decision step  214 , due to any intervening optional steps  228 - 232 . In addition, the machine configuration information of the local machine  102 , which is reflected in the newly-collected machine configuration information, may have changed since the time of decision step  214 . For example, where the newly-collected machine configuration information includes information regarding the operating system  110  installed on the local machine  102 , if the operating system  110  has been upgraded since the time of the software application from a lower-priced operating system to a higher-priced operating system, the newly-collected machine configuration information would reflect this upgrade to the operating system  110 . 
         [0028]    If it is determined at decision step  234  that the product key remains valid (Yes at step  234 ), then the method  200  may include a step  236  in which the license data is revalidated to authorize continued access to the software application. For example, the activation module  114  of the local machine  102  may, at step  236 , revalidate the license data that was received at step  224  or optional step  230  in order to authorize continued access to the software application  112 . Conversely, if it is determined at decision step  234  that the product key is no longer valid (No at step  234 ), then the method  200  may include a step  238  in which the license data is invalidated to prevent continued access to the software application. For example, the activation module  114  of the local machine  102  may, at step  238 , invalidate the license data that was received at step  224  or optional step  230  in order to prevent continued access to the software application  112 . 
         [0029]    Continuing with the above example, where the newly-collected machine configuration information indicates that the operating system  110  has been upgraded since the time of the software activation from a lower-priced operating system to a higher-priced operating system, and the mapping in the activation rules  120  that were received at step  224  or optional step  230  indicate that the product key is authorized for the prior lower-priced operating system but is not authorized for the current higher-priced operating system, then the activation module  114  of the local machine  102  may, at decision step  234 , determine that the license data is no longer valid for the newly-collected machine configuration information of the local machine  102 , and may, at step  238  invalidate the license data that was received at step  224  or optional step  230  in order to prevent continued access by any user to the software application  112  on the local machine  102 . 
         [0030]    Continuing with the above examples, by the conclusion of step  236  or step  238 , it will be determined whether the product key remains valid for the present configuration of the local machine  102  on which the software application  112  is installed, and continued access to the software application  112  will either be reauthorized or denied. Where the product key remains valid, the license data received by the local machine  102  at the time of software activation is revalidated, and otherwise the license data is invalidated. In this manner, the example methods disclosed herein can employ the activation rules  120  that were current at the time of the software activation, or in some embodiments even more current, to revalidate or invalidate license data, thus preventing an originally valid license from subsequently being employed by a user in an unauthorized manner. 
         [0031]    Subsequently, the method  200  may also periodically include additional iterations of optional steps  228 - 232  in order to periodically update the activation rules  120  stored at the local machine  102 . For example, each time the activation rules  120  are updated at the remote activation server  104 , optional steps  228 - 232  may be performed in order to download a current copy of the activation rules  120  to the local machine for use in revalidation of the software application  112 . Also, the method  200  may periodically include additional iterations of steps  234 - 238  in order to periodically revalidate the license data of the installed software application  112 . For example, each time that the software application  112  is executed, steps  234 - 238  may be performed to revalidate or invalidate the license data in light of any changes to the configuration of the local machine  102 . 
         [0032]    The embodiments described herein may include the use of a special-purpose or general-purpose computer including various computer hardware or software modules or filters, as discussed in greater detail below. 
         [0033]    Embodiments described herein may be implemented using computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general-purpose or special-purpose computer. By way of example, and not limitation, such computer-readable media may include non-transitory computer-readable storage media including RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other storage medium which may be used to carry or store desired program code in the form of computer-executable instructions or data structures and which may be accessed by a general-purpose computer, special-purpose computer, or virtual computer such as a virtual machine. Combinations of the above may also be included within the scope of computer-readable media. 
         [0034]    Computer-executable instructions comprise, for example, instructions and data which cause a general-purpose computer, special-purpose computer, or virtual computer such as a virtual machine to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or steps described above. Rather, the specific features and steps described above are disclosed as example forms of implementing the claims. 
         [0035]    As used herein, the term “module” may refer to software objects or routines that execute on a computing system. The different modules described herein may be implemented as objects or processes that execute on a computing system (e.g., as separate threads). While the system and methods described herein are preferably implemented in software, implementations in hardware or a combination of software and hardware are also possible and contemplated. 
         [0036]    All examples and conditional language recited herein are intended for pedagogical objects to aid the reader in understanding the example embodiments and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically-recited examples and conditions.