Abstract: A computing device communicates a request to a risk determination system to determine whether particular content is malware. The content is oftentimes a file containing a program to be run, but can alternatively take other forms, and an indication of the content is provided to the risk determination system. Additional information describing attributes of the computing device is also provided to the risk determination system. These attributes can include for the computing device hardware specifications, operating system specifications, anonymized information, information describing anti-virus or other anti-malware program settings, information describing programs running on the computing device, and so forth. The risk determination system analyzes the information describing attributes and/or activity of the computing device to determine a risk factor of the content, and from the risk factor determines whether the content is malware for the computing device.

Abstract: A software licensing Application Programming Interface (API) that allows software products to use the license management functionality of a common service. A license specifies rights in a software product. The software product calls a consume method on the API in order to consume a right. If the right exists, the service binds the right to the license in which the right is found. The software product enforces the terms of the license by granting, or denying, access to some or all features depending on whether a valid instance of the right is found. Arbitrary data can be associated with a right. The API includes a method to retrieve data from a right that has been previously bound by the consume method.

Abstract: A software licensing Application Programming Interface (API) that allows software products to use the license management functionality of a common service. A license specifies rights in a software product. The software product calls a consume method on the API in order to consume a right. If the right exists, the service binds the right to the license in which the right is found. The software product enforces the terms of the license by granting, or denying, access to some or all features depending on whether a valid instance of the right is found. Arbitrary data can be associated with a right. The API includes a method to retrieve data from a right that has been previously bound by the consume method.

Abstract: A computing device communicates a request to a risk determination system to determine whether particular content is malware. The content is oftentimes a file containing a program to be run, but can alternatively take other forms, and an indication of the content is provided to the risk determination system. Additional information describing attributes of the computing device is also provided to the risk determination system. These attributes can include for the computing device hardware specifications, operating system specifications, anonymized information, information describing anti-virus or other anti-malware program settings, information describing programs running on the computing device, and so forth. The risk determination system analyzes the information describing attributes and/or activity of the computing device to determine a risk factor of the content, and from the risk factor determines whether the content is malware for the computing device.

Abstract: Systems, methods, and apparatus for generating and validating product keys. In some embodiments, a product key includes security information and identification information identifying at least one copy of a software product. The identifying information may be used to access validation information from at least one source other than the product key, and the validation information may be used to process the identification information and the security information to determine whether the product key is valid. In some further embodiments, the security information includes a first portion to be processed by a first validation authority using first validation information and a second portion to be processed by a second validation authority using second validation information, wherein the second validation information is stored separately from the first validation information.

Abstract: Systems, methods, and apparatus for validating product keys. In some embodiments, a product key includes security information and identification information identifying at least one copy of a software product. The security information may include a first portion to be processed by a first validation authority using first validation information and a second portion to be processed by a second validation authority using second validation information. The second validation information may be stored separately from the first validation information and may not be accessible to the first validation authority. In some embodiments, the first validation authority randomly determines whether a product key is to be audited by the second validation authority. Alternatively, the first validation authority may determine whether to audit based on a type of the software product associated with the product key and/or a perceived level of security risk.

Abstract: Systems, methods, and apparatus for validating product keys. In some embodiments, a product key includes security information and identification information identifying at least one copy of a software product. The security information may include a first portion to be processed by a first validation authority using first validation information and a second portion to be processed by a second validation authority using second validation information. The second validation information may be stored separately from the first validation information and may not be accessible to the first validation authority. In some embodiments, the first validation authority randomly determines whether a product key is to be audited by the second validation authority. Alternatively, the first validation authority may determine whether to audit based on a type of the software product associated with the product key and/or a perceived level of security risk.

Abstract: Systems, methods, and apparatus for generating and validating product keys. In some embodiments, a product key includes security information and identification information identifying at least one copy of a software product. The identifying information may be used to access validation information from at least one source other than the product key, and the validation information may be used to process the identification information and the security information to determine whether the product key is valid. In some further embodiments, the security information includes a first portion to be processed by a first validation authority using first validation information and a second portion to be processed by a second validation authority using second validation information, wherein the second validation information is stored separately from the first validation information.

Abstract: A method and computer-readable medium for deterring software piracy in a volume license environment. An activation bypass message is generated and sent. Information contained in the activation bypass message is compared to a list of machine identifiers. A binding service message contains a count of the machine identifiers in the list. Once the count reaches a predetermined threshold, software activation bypass may occur.

Abstract: To install a black box on a computing device, an administrator has access to the computing device and queries same for machine properties thereof. The administrator sends the machine properties of the computing device to a black box server as part of a request for a new black box for the computing device. The black box server in response constructs the new black box based in part on the machine properties so as to tie the new black box to the computing device, and delivers the new black box to the administrator. The administrator thereafter installs the new black box on the computing device. The administrator may include an activation provider running on the computing device and an activation manager in communication with the activation provider. The administrator may also deactivate the black box if it determines that the black box is no longer trustworthy.

Abstract: A flexible use licensing system for an application comprising a plurality of licensable products is provided comprising an application level product policy definition license, and a licensable product policy definition license corresponding to each licensable product. The flexible use license further comprises a rights account certificate for validating the use license against a variety of environmental conditions, and an external validation component for validating the use license at a licensing authority without the transmittal of the entire use license.

Abstract: A state store having state information therein is stored on a computing device. Information at least nearly unique to the computing device is obtained, and a number of locations at which at least a portion of the state store is to be stored at is determined. Pseudo-random file names and corresponding paths are generated based at least in part on the obtained information, whereby the generated file names and corresponding paths are likewise at least nearly unique to the computing device, and the generated file names and path are paired to form the locations. Thereafter, the state store is stored according to the generated locations.

Abstract: A centralized process is provided for elevating portions of an application running under a user account to administrator privilege. A service security identifier is temporarily associated with the user and the portions of the application to be elevated to administrator privileges. The service security identifier is registered in the access control list to be accessed by the operating system. The centralized process may be used in the activation of software products.

Abstract: An application includes a plurality of features. A transaction is engaged with a retailer to obtain a product license corresponding to the application. The product license defines at least one feature of the application that may be employed. A base copy of the application is obtained from a distributor and is actuated. A use license corresponding to the product license is acquired from a licensor by way of the actuated application sending the product license to the licensor along with an identification of at least one of a user, the computing device, and a trusted component operating on the computing device, where the use license includes feature policy granting rights to employ each feature defined in the product license.

Abstract: A state store having state information therein is stored on a computing device. Information at least nearly unique to the computing device is obtained, and a number of locations at which at least a portion of the state store is to be stored at is determined. Pseudo-random file names and corresponding paths are generated based at least in part on the obtained information, whereby the generated file names and corresponding paths are likewise at least nearly unique to the computing device, and the generated file names and path are paired to form the locations. Thereafter, the state store is stored according to the generated locations.

Abstract: An application includes a plurality of features. A transaction is engaged with a retailer to obtain a product license corresponding to the application. The product license defines at least one feature of the application that may be employed. A base copy of the application is obtained from a distributor and is actuated. A use license corresponding to the product license is acquired from a licensor by way of the actuated application sending the product license to the licensor along with an identification of at least one of a user, the computing device, and a trusted component operating on the computing device, where the use license includes feature policy granting rights to employ each feature defined in the product license.

Abstract: A first process operating on a computer comprises code to be executed in connection therewith, where the code includes at least one triggering device. A digital license corresponds to the first process and sets forth terms and conditions for operating the first process. A second process operating on the computer proxy-executes code corresponding to each triggering device of the first process on behalf of such first process. The second process includes a license evaluator for evaluating the license to determine whether the first process is to be operated in accordance with the terms and conditions set forth in such license, and the second process chooses whether to in fact proxy-execute based at least in part on determination of the license evaluator. Thus, the first process is dependent upon the second process for operation thereof.

Abstract: Distributed module authentication allows security checks to be initiated by multiple software modules. Module authentication processes can be inserted into two or more modules in an operating system and/or various other applications. These module authentication processes can verify the integrity of binaries associated with one or more modules in computer memory. Security checks can be performed on modules stored on disk, in active system memory, or in any other location. Various security checks can be coordinated with each other to ensure variety and frequency of module authentication, as well as to randomize the module authentication process that performs a particular security check. In addition, security processor code can be interleaved within normal application code, so the security code is difficult for attackers to remove or disable without damaging the useful functionality of an application.

Abstract: Systems and methods for implementing a hardware ID with time- and weight-based flexibility use a hardware ID (HWID) including identifying information about hardware components. When software is run, a current HWID is generated. When the current HWID is compared to a stored HWID to determine if the two HWIDs match, a time vector and a weight vector are used in the comparison. A running matching score is kept of matches. For each hardware component, the weight vector indicates the weight given to a correct match of the hashed value for the hardware component. For example, if the weight value for the hardware component is three and there is a match, then the running total is increased by three. For each hardware component, the time vector may indicate an expiration period after which a change in the component may be allowed.

Abstract: A state store having state information therein is stored on a computing device. Information at least nearly unique to the computing device is obtained, and a number of locations at which at least a portion of the state store is to be stored at is determined. Pseudo-random file names and corresponding paths are generated based at least in part on the obtained information, whereby the generated file names and corresponding paths are likewise at least nearly unique to the computing device, and the generated file names and path are paired to form the locations. Thereafter, the state store is stored according to the generated locations.