KR20200000448A - Systems and methods for software activation and license tracking - Google Patents

Abstract

Systems and methods for software activation and status tracking on end-user computing devices (computers) have been developed to provide software developers with a flexible and secure tool for collecting software distribution and software activation usage statistics. The method consists of the following logical steps: (a) acquiring acquisition confirmation; (b) request a license; (c) issue a license and provide it to the end user, where the license is protected by the server with the private key and the private key is not stored on the client; (d) verify the license on the user's computer; (e) store the license on the user's computer; (f) periodically track the activation status; (g) Take any other action on your license. Validating the license includes checking the license received from the server without modification at the client associated with the application and storing the license on the client.

Description

Systems and methods for software activation and license tracking

FIELD OF THE INVENTION The field of the present invention relates to software activation systems and methods.

Currently, there are methods of software activation of various related technologies. Most related software activation methods require an internet connection. However, using an Internet connection for software activation can cause a variety of problems and drawbacks. For example, but not limited to, there are problems with using unauthorized (eg illegal) software. Unless the software activation method is more sophisticated than the prior art, the prior art problem of security and prevention of illegal software use will remain in the field of software activation.

Some related technical approaches include a client associated with the application that generates a fake license file that contains incorrect parameter information, performs validation of the license, and replaces the incorrect parameter information with the correct parameter information when the license validation is complete. Validation techniques for licenses can be used. However, this method can have several problems and disadvantages. For example, but not by way of limitation, the fake license approach assumes that the contents of the license file are written on the client's machine and not on the server side. Thus, a keygen app can generate these files in the same way as a vendor app, without having to destroy the vendor app.

The present invention relates to the following aspects: simplifies the activation process for the end user; Secure the activation method at each stage of the activation process to prevent unauthorized (eg illegal) software use; Track future activation status to reduce the number of customer support calls related to unexpected problems such as software reactivation on the new computer or accidental loss of the activation number.

The first step in the activation process is to acquire an application. Acquisition of applications can be through purchases, giveaways or other methods defined by the supplier. The user must be confirmed for the application acquisition. This confirmation of the acquisition of the application is not limited thereto, and may exist in the form of: (a) an activation key—for example, a unique symbol combination provided by a software developer; Or (b) a record in the database of the activation system that is associated with a particular user.

Acquisition of such an application can be performed in various ways. For example, but not limited to, software can be purchased from online stores, and delivery can occur on physical media, including but not limited to CD, DVD, or USB drives, including software associated with OEM supply sets. have. In each of these application acquisition modes, there is a unique mechanism for establishing the suitability of acquisition commitments, and there are also license issuance rules.

Acquisition confirmation may include an activation number. From one side, the acquisition confirmation may be human readable, which may reduce the number of possible errata. On the other hand, acquisition confirmation is long enough to prevent indiscriminate searches. In addition, a URL-specific activation scheme has been developed that allows developers to give users the option to activate the software as a user action, including, but not limited to, selection or click actions for email or on buttons on the web. have.

Records in the database of the activation system associated with a particular user may be initiated in one or more ways. For example, but not by way of limitation, records in the database of the activation system may be initiated after (a) purchasing software at an online or offline store; Or (b) manually initiated by an activation system administrator. The user must provide identification information to obtain a software license. The identification information may comprise (a) a unique login identifier and password pair; (b) a secure connection to an activation server protected by a security key provided by the activation server; Or (c) a method defined by the administrator of the activation system, which allows for a clear identification of the user.

After initiating a record in the activation system's database, the next step is to generate a license request. This step requires an internet connection. According to this example implementation, a protocol is provided. A mechanism is also provided for how data is processed at the activation server. Requests from user computers may include the following data, including but not limited to one or more of the following: (a) an application bundle ID (eg, a specific format of a product name); (b) bundled versions (such as product versions); (c) an additional data set maintained for current activation; (d) the user's account identifier (eg, email address); (e) two values for a unique computer identifier; (f) confirmation of acquisition; (g) the user's first and last name; (h) random data blocks to enhance security; (i) a password for opening data on the server side; And (j) the language of the error message.

Once a license request is generated, the third step is to issue a license and deliver it to the user, the license is protected by the server with the private key and the private key is not stored on the client. After receiving the license request, if the activation request is valid, the server issues a license or otherwise sends an error message. The server response contains the following information: (a) error code (eg 0 if successful); (b) error messages or encrypted licenses; (c) The signature or error message of the license file generated using the software's private key.

After the software license is delivered to the end user's computer, the software license must pass a confirmation by the client associated with the application to verify the license received from the server without modification and to store the license on the client. The license file is written to a specific location on the user computer file system. License validity is checked as understood by the skilled person after the first release of the application, during the app installation, during the first release after the trial period of the app, or in other appropriate circumstances. The user can continue working on the software after the license source verification (eg verification by public key) and integrity is complete.

 The activation status is periodically sent to the activation server. Reporting rules can be defined by the developer. The activation state can be triggered according to various conditions defined by the developer (eg software reactivation if reactivation is allowed).

Example implementations also relate to the possibility of deactivating a license remotely (eg, from an activation server side) and directly (eg, initiated by a user).

1 illustrates an example process of a protocol including a client and a server according to an example implementation.
2 shows an example for a first protocol according to an example implementation.
3 shows an example for a second protocol according to an example implementation.
4 illustrates an example process of a protocol including a server according to an example implementation.
5 illustrates an example process of a protocol including a client in accordance with an example implementation.
6 illustrates an example environment suitable for some example implementations.
7 illustrates an example computing environment having an example computing device associated with an external host for use in some example implementations.

The subject matter described in this specification is taught by example implementations. Various details have been omitted for clarity and to avoid obscuring the subject. The examples shown below relate to the structure and functionality for software activation and license tracking.

It is to be understood that the terminology used herein has the general meaning common to those skilled in the art. The term may be defined by way of example, but is not limited to the definition provided. For example, but not limited to, a "user" or "end user" obtains a copy of the software (eg, legally) in an authorized manner and on a computing device. It may include entities such as individuals that operate the software correctly. A "developer" or "vendor" may also be an entity, such as a person or legal entity that distributes one or more copies of software, such as a logically completed computer program. A "software installation" is also a copy of a computer program disposed on a user computing device associated with a user, in a manner that operates the computer program in a manner intended by the developer.

In addition, "activation" may include a procedure or set of procedures that establishes the legitimacy of a software installation (eg, whether the software installation is authorized) and removes any functional restrictions (if any) designed by the developer. A "trial" may include a type of software installation use with limited functionality to familiarize the user with the software. In addition, an "acquisition confirmation" is a digital entity that establishes the user's right to legally use the software (eg, authorization) and must be provided to the user after the acquisition process (eg, purchase, giveaway, etc.).

Further, the "activation number" or "activation key" may be a human readable combination (e.g., alphanumeric symbol) used as the type of acquisition confirmation. A "license" may also include a computer file that contains data used to identify whether a software installation can be used on a particular computer device. The "license type" may include a set of license generation rules, which are set by the developer to vary the software license terms. Such rules include, but are not limited to, software usage periods (eg, one year, six months, lifetime), various reactivations, and specific features to be provided.

In addition, an "Activation Server" or "Server" is a remote computing device for a user's computing device and performs the operations required for software installation activation. According to an example implementation, the server may include hardware known to those skilled in the art. A "bundle ID" is also a special type of application identifier that can be read by the operating system of the end user's computer.

Aspects of the example implementation simplify the activation process for the end user; Secure the activation method to prevent unauthorized (eg, illegal) use of the software at each stage of the activation process; It involves tracking future activation status to reduce the number of customer support inquiries related to unexpected problems such as re-activation of software on new computers, accidental loss of activation number.

 To overcome the security gap of the prior art described above, an example implementation is directed to an asymmetric manner of digital signatures. More specifically, the example implementation uses a unique key pair for each vendor application; Public keys integrated into all vendor apps and private keys securely stored on the server side. To protect a private key located on a server, the example implementation may use a variety of techniques and methods, including but not limited to an isolated storage system available only to internal servers, where the server is not connected to the Internet. It uses SSL to establish an encrypted connection and uses the AWS Virtual Private Cloud service for provisioning in the virtual isolation section of the cloud.

Use a network firewall to protect against illegal access

When the server receives the request, the server generates the contents of the license file and signs the license file with a unique and secure private key. Thus, the server creates a digital signature. The signed license file with a unique secure private key is specific to each vendor app.

The vendor app receives the license file with the digital signature and stores it on the user's machine (client). If a malicious actor (e.g. a hacker) tries to do something malicious (e.g. attempts to change the license file or generates a fake license), the signature validation of this license file will be Fail on As a result, the contents of the license file become invalid and the vendor app withstands malicious attempts (e.g. attempts to crack the vendor app).

To achieve these and other aspects, various steps may be performed in the activation process 100 as shown in FIG. 1, without being limited thereto. At 101, the user acquires an application. Further, at 103, the user receives a confirmation of the acquisition of the application by one of various modes. Each acquisition mode of the application has its own mechanism related to the set of license issuance rules and the conformance of acquisition commitments. The acquisition confirmation may include an activation number and is human readable, but long enough to prevent indiscriminate searches by unauthorized parties to determine the activation confirmation. In addition, the activation method for each URL according to an exemplary implementation may enable a developer to provide a user with an option of activating the software by a user action.

A record of the database of the activation system associated with a particular user may begin at 105. The user must provide identification information to obtain a software license at 107. After the record is started in the database of the activation system, a license request is generated by the protocol at 109. According to the protocol, a license is generated on the server and signed with a secure private key. If a license request is generated at 109, the license is provided to the user at 111, and the user receives the license with a digital signature at 113 and stores the license file on the user device.

As described above, after the license request is received, the server determines at 115 whether the activation is correct, issues a license at 119 if the activation request is correct, or sends an error message at 117. After the software license is delivered to the end user's computer, it must pass validation at 119. The license file is written to a specific location on the user computer file system. When the application is executed, the license validity is checked at 121 without modifying the license received from the server; If you attempt to change the signed license file or generate a fake license, these attempts will fail on the vendor side and the contents of the license file will be invalid, resulting in the vendor app not cracking. After verifying the verification and completeness of the license source, the software installation is complete and the software is ready for use at 123. The activation status is periodically sent to the activation server. In addition, licenses can be deactivated remotely or directly.

Further details of various operations are described in more detail below.

Obtaining an Acquisition Confirmation

In order to use the software in an authorized manner (eg legally), the user must obtain an acquisition confirmation. Such acquisition confirmation may exist in a variety of forms, including but not limited to: (a) an activation key (eg, a unique combination of symbols provided by a software developer); Or (b) a record in the activation system database associated with a particular user. After completing the acquisition, the user should be provided with instructions on how to exchange the acquisition confirmation for a software license.

As mentioned above, the user must acquire an acquisition confirmation (eg an activation number). Software vendors may have one or more other activation number distribution options:

Direct sales (for example, online sales on a supplier's website or direct sales through a supplier's retail store);

Sales through third party resellers or partners;

Boxed version on physical media (e.g. CD, USB stick or SD card) or distributed via online

The distribution method described above may require different ways and order of obtaining acquisition confirmation. In some cases, as soon as a payment is received, an acquisition confirmation may be provided upon request; In other cases, it may be necessary to provide a large number of pre-generated activation numbers for delivery to some physical medium. In each case, the supplier must know additional information associated with the conditions (eg, partners, marketing campaigns, data, counts and other conditions) in which the activation number was generated (eg for marketing and analysis purposes).

An example implementation includes at least three basic mechanisms of acquisition confirmation generation:

Generation by URL-Each request for acquisition confirmation will be redirected to a specific URL associated with the activation server. In the case of a complete and correctly configured request, the server responds with an acquisition confirmation.

'Bulk' Generation-The server generates a finite number of activation numbers that are provided 'as is' to the software distributor or spread through the user.

Single Generation-This method of generating acquisition confirmations is primarily used for testing and support purposes, such as when one acquisition confirmation needs to be created.

Acquisition confirmation may be sent 'as is' by the server without encryption.

Generation by URL

This method includes a request for one or more acquisition confirmations. This method is most commonly used when buying directly online, but can be used in other modes of acquiring an application. 2 shows an example implementation 200 of a process for requesting an activation code based on generation by URL. In FIG. 2, a user workstation 201, payment system 203 and activation server 205 are disclosed. However, as will be appreciated by those skilled in the art, other implementations may be substituted without departing from the scope of the present invention.

1. The user visits a purchase page (such as a developer's website or a third-party web resource or product purchase method). (207)

2. The User will provide the necessary information such as first name / last name, email address, telephone number, product quantity, software usage period, etc. (207)

3. If the purchase is successful, the billing system sends the information collected by the specific API to the server of the software vendor; Order information is stored in the activation server and an activation key is generated (209, 211a, 211b).

4. The user obtains an activation key from the activation server. The activation key is sent to the e-mail specified / indicated on the purchase page. (213, 215)

5. If for some reason the payment cannot be completed, the user is informed that the transaction cannot be completed with instructions for further action (re-entering billing information, checking the bank account, attempting later, etc.). (217)

Bulk generation

In another example implementation, 'bulk' activation may be used to provide a lot of code for the partner: producer, affiliate, reseller of physical media (CD, USB).

In this example implementation, the software vendor may use a certain amount of activation number (e.g., a number of marketing parameters or contract terms (e.g. 500 licenses are provided to Resell LLC and used by December 25, 2017). In advance).

In this example implementation, a database with an empty order record is created, and the developer can specify a specific pattern of activation numbers. The application asks the end user for personal data (name and e-mail address). Therefore, the order record is filled after the software is activated.

Single Generation

This option can be implemented for customer support as well as promotional or test purposes.

According to this example implementation, the software vendor generates an activation code through a special admin panel on the server and then sends the code to the customer or the required party. The order record is then filled in by the administrator.

Creating a Record in Activation System's Database

The operation of creating a record in the database of the activation system after obtaining the software is as follows. The user must identify himself or herself in the activation system. This can be done in one or more of the following ways, but not limited to:

By providing unique login and password information pairs;

By establishing a secure connection with the activation server, which is protected by a security key (eg encrypted) provided by the activation server;

Establish a connection with the activation server and transmit the parameters, such as by providing a session identifier from a third party service or by providing other parameters defined by the activation system administrator to enable clear identification of the user. by doing.

After the user has identified himself in the activation system, information about the software acquisition is stored as a record in the activation system database.

Issuing a License

After receiving the confirmation of the acquisition, the user must request a license to use the software without restriction.

The license issuance process is similar for each type of acquisition confirmation. The difference lies in the way the user provides acquisition confirmations for licensing:

By entering an activation number in the application;

By activating the application by the URL method;

By authenticating on the activation system:

By providing unique login and password pairs;

By establishing a secure connection with an activation server, protected by a previously provided security key;

By establishing a connection with the activation server and sending the parameters (eg, by providing a session identifier from a third party service or any other parameter defined by the activation system administrator) to allow clear identification of the user.

The process of license request 300 is as follows, as shown in FIG. As shown in FIG. 3, a user computing device (eg, workstation) 301, an application side operating space 303 (eg, a user control device) and a server side space (eg, a database) Server 305 is provided. Tasks include, but are not limited to:

1. The user provides acquisition confirmation by one of the methods described above. (307)

2. The software generates a license request and sends the license request to the activation server. (308)

3. The activation server checks whether activation is allowed for this acquisition confirmation (eg the activation server may retrieve the 'activation' parameter from the activation number record of the database). (309)

4. If yes (ie, activation is allowed), the activation server issues a license based on the identification information (311) and sends a response to the application including the license file. (317)

5. The license file passes validation on the application side of the activation system. (319)

6. Inform the user that activation was successful. (321)

7. If the activation server determines that an error occurred during the activation process (for example, a license could not be issued at 309 and a license was not previously issued at 313), the activation server sends an error code and message to the application. And therefore send back to the user (315). On the other hand, if the activation server cannot issue a license at 309 but determines to have issued a license prior to 313, the process continues to transfer the previously issued license at 317 as described above.

8. The software informs the user of the type of error (eg validation of activation code, contact customer support, etc.) with instructions for further action to correct the error. (323)

In order to reduce the number of requests to the server and simplify the user's input requirements, a pattern recognition system for an activation key was implemented according to this example implementation. More specifically, an activation key is generated using a specific pattern, which pattern is recognized by the software installation and triggers the software installation for a particular action. For example, but not limited to, an activation key with a particular suffix may initiate an appearance of a form requesting personal data from a user. Vendors can set specific patterns and software installation behaviors to match unique patterns and behaviors.

After the software is registered with the activation server, the activation server issues a private key and a public key pair for signature of the license. The private key is stored on the server and used to sign each license before the license is sent to the application. The public key is integrated into the application side part of the activation system and is later used to verify the license signature, as described below.

After a successful activation request occurs, a license is generated on the activation server. The license is one of the parameters and contains a hash generated based on the following application identifier:

Bundle ID of the application;

MAC address of the network interface card; Hard disk drive or solid state drive; Motherboard identifiers, or other identifiers known to those skilled in the art; One or more identifiers of a user's computing device (eg, hardware), which may be, but is not limited to, a user name used to authorize a user in an operating system; And

Randomly generated string to be included in the license (e.g. 'salt').

Before sending the license file to the end user, the license file is encrypted with a symmetric encryption algorithm and signed with a server signature based on the private key issued during software registration at the activation server.

Reactivation

In order to reduce the number of support inquiries due to the need to continue using the software after a hardware change (eg, a new computer), a reactivation system according to the example implementation has been implemented.

When an activation number is issued, the activation number has a limited number of activations. For example, if for some reason the user deactivates the software installation on his computer device and reactivates the software on the same computer device using the same activation number, a previous license is issued.

On the other hand, even if the user changes the computing device, he still has the ability to activate the software using the same activation number. Information on the number of possible reactivations is stored on the activation server. The activation server automatically adds one additional reactivation after a specified time period (eg 6 months by default, but not limited to this). As a result, the user can reactivate the software if the computing device or operating system changes.

Validation of License

In order for the software installation to work properly, you must check and validate the validity of the license on your computer. Verification consists of a check of the following parameters: (a) license source (eg whether the license was issued by the correct server); (b) whether a license has been issued to this computer (eg whether a license has been issued to the correct computer); And (c) the license is not expired.

In the related art, the verification process is a period of time during which hackers can receive the information necessary to break into code and crack an application. To address this risk, the example implementation includes several mechanisms.

If a license check has not been initiated at the time a license check is required (this can be defined by the developer, for example, to start an application, upgrade or perform a specific action), the application side of the activation system will modify the license. It checks the line access received from the server and stores the validated license on the client side, user or computer. In the case of internal intrusion, unauthorized parties (e.g. hackers) do not get data.

More specifically, as described above, to overcome the security issues of the related art described above, an example implementation relates to an asymmetric manner of digital signatures. More specifically, the example implementation uses a unique key pair for each vendor application: a public key integrated in every vendor app and a private key securely stored on the server side.

When the server receives the request, the server generates the contents of the license file and signs the license file with a unique and secure private key. Thus, the server generates a digital signature. The signed license file with a unique secure private key is different for all vendor apps.

The vendor app receives the license file along with the digital signature and stores it on the user's machine (for example, the client). If a malicious actor (e.g. a hacker) tries to do something malicious (e.g. attempts to change the license file or attempts to generate a fake license), the signature verification of the license file will fail on the vendor app side. As a result, the contents of the license file become invalid and the vendor app defeats malicious attempts (e.g. attempts to crack the vendor app).

Thus, there is no need to prevent hackers from obtaining license data, because it is impossible for hackers to obtain license data as described above. License data is uniquely generated for each machine and signed with a private key stored on the server (using machine-specific identification information such as network MAC address or serial number). As a result, license data cannot be used or accessed from other machines.

As a license check is required, the application side part of the activation system checks the predefined storage to determine if a license is available.

First, the application side portion of the activation system verifies the server signature using the public key integrated into the application side portion of the application system as described above. If the server signature is determined to be valid using the public key, the activation system receives a key for symmetric decryption. The second part of the license is decrypted using this decryption key. Successful decryption results in license information.

The next step is to validate the license for that particular computer. To perform this check, the application side of the activation system generates a hash string using the following parameters:

Bundle ID of the application

One or more identifiers of the computing device

The string 'salt' stored in the license.

The generated hash string must match the string stored in the license. If they do not match, it is determined that the license is not valid for that particular computer and / or that particular application.

As a next step, the application side portion of the activation system checks to confirm that the license has not expired by comparing the license parameters with the current system and application status. Depending on the license type, the following parameters can be compared:

a) current system time and license expiration time;

b) current system time and license termination time;

c) current application version and license expiration version;

d) Flags for current application version and license beta only.

In addition, the application-side portion of the activation system may periodically send a request to the activation server for license confirmation. The request may include the activation identifier and the information needed to identify the user's workstation. If the license is still found to be valid, the server responds with the same license. However, if the license still turns out to be invalid, the server responds with an error message. Since the expiration time is confirmed according to the server system time, this method prevents the operation by extending the license period using the system time of the user workstation.

Application-side Part Security

The application side part of the activation system is uniquely created for each application registered with the activation server. For security purposes, the functions, methods and variables of the programming code of the application side part of the activation system are obfuscated (eg, made unreadable by humans).

Functions to be obfuscated are marked with special markers, and during compilation the names are replaced with arbitrary ones from predefined alphabets (usually alphanumeric: including uppercase and lowercase letters and numbers). The obfuscated name is unique for each application.

Another mechanism to improve security is to use a function that changes the destination address in memory during runtime. More specifically, while compiling the program code, functions used for license validation intentionally return incorrect parameters, but while the software is running, they are redirected to the address of memory, which returns the correct parameters. Contains functions These functions are randomly named during compilation, so in reverse engineering, software hackers will not be able to determine what the functions actually do. This mechanism can be implemented even when license checking is required, as defined by the developer.

According to the example implementation, the developer is not provided with the name of the function during operation and need not have this information. For example (but not by way of limitation) a developer writes a software program (e.g. code) and then the function is named pseudo-random (e.g. obfuscation) when the application is compiled, so as a security measure a function based on the name of the function It is not possible to determine

Remote Disabling License

If the user requests a refund and the refund request is approved, the user loses the right to use the software. Therefore, a mechanism for revoking the license remotely is required. This mechanism is also used to process subscription plan plans if the user has to pay for software monthly or yearly. For example, the user may choose not to simply update the software without providing an indication of aggressive cancellation.

If a license is marked invalid on the server due to a refund or outstanding subscription (e.g. renewal), the license is also displayed in the application portion of the activation system and the user cannot use the application until payment is confirmed.

Disabling License on the Application Side

In addition, developers can add the ability to deactivate licenses within an application. After the user initiates the license deactivation, the application side of the activation system sends a request to the server side. Thus, the server responds with a license for that particular workstation and it is marked as deactivated. This procedure is useful if you want to use the software on another workstation. The user can start deactivating licenses on the first workstation and repeat the steps required to activate the application on a second (for example) other workstation.

Using app store receipt as license

If the vendor sells the application (for example, through the Apple App Store and other sources), the activation server can match the app store receipts with the license.

For example, but not limited to, a user has purchased an application through an app store (e.g., an Apple App Store), and information about the purchase is sent to the activation server via a public API. If the user needs to reactivate the software on the computing device, the software installation is recognized as activated and a license is automatically issued.

Example Process

4 illustrates a process 400 performed at a server in accordance with an example implementation, and includes the foregoing disclosure of FIGS. 1-3. At 401, after a user acquires an application and receives confirmation of acquisition of the application by one of various modes, a record in the database of the activation system associated with the particular user is started at the server side. Further, at 403, the server receives identification information and a license request from the user to obtain a software license. After the record is started in the activation system's database, a request for a license is generated by the protocol at 405. According to the protocol, licenses are generated on the server and signed with a secure private key. If a license request is generated at 109, a license with a digital signature is provided to the user at 407 and the license file is stored on the user device.

After the license request is received as described above, at 409 the server determines whether the activation is correct and issues a license at 413 if the activation request is correct or otherwise sends an error message at 411. At 413, after the software license is transferred to the end user's computer, the verification must be passed at 415 without modifying the license received from the server; If you attempt to change the signed license file or generate a fake license, these attempts on the vendor side will fail and the contents of the license file will not be valid and the vendor app will not crack. The license file is written to a specific location on the user computer file system. When the application runs, the license validity is checked at 415. After verifying and verifying the original license, the software installation is complete and the user can use the software. The activation status is periodically received by the activation server. In addition, licenses can be deactivated remotely or directly by the activation server.

5 illustrates a process 500 performed at a server in accordance with an example implementation, and includes the foregoing disclosure of FIGS. 1-3. At 501, the user acquires an application. In addition, at 503, the user receives confirmation of the acquisition of the application by one of various modes.

As mentioned above, each acquisition mode of the application has a distinct and unique mechanism related to establishing a set of license issuance rules and adherence to acquisition commitments. The acquisition confirmation may include an activation number and is human readable but long enough to prevent brute force searches. In addition, the URL-based activation scheme according to the exemplary implementation enables the developer to provide the user with the option of activating the software by user action.

At 505, the user provides a request to obtain identification information and a software license. If the license request is generated with the digital signature by the server as described above, the user receives the license at 507 and the license file is stored on the user device.

After the license request is received at 507, the server determines whether the activation is correct, and if the activation request is correct, the user receives the issuance of a license at 513 or otherwise receives an error message at 511. In 513, the software must be licensed on the end user's computer and pass the verification. The license is written to the user's device without modifying the license received from the server; If you try to change the signed license file or generate a fake license, the vendor's attempt will fail and the contents of the license file will be invalid and the vendor app will not crack. The license file is written to a specific location on the user's computer file system. When the application runs, the license is validated. After verifying the license source and confirming the completeness, the software installation is complete and the software is ready for use at 515. The activation status is periodically sent to the activation server. You can also deactivate a license remotely or directly on the server.

In some examples, the above-described processes shown in FIGS. 1-5 may be implemented in different, fewer, or more blocks. The process may be embodied as computer executable instructions, which may be stored on a medium, loaded into one or more processors of one or more computing devices, and executed as a computer-implemented method.

Example Environment

6 illustrates an example environment suitable for some example implementations. Environment 600 includes devices 605-645, each device being capable of communicating to at least one other device (eg, by wired and / or wireless connection) via network 660, for example. Connected. Some devices may be communicatively coupled to one or more storage devices 630 and 645.

Examples of one or more devices 605-645 may be computing devices 705 and / or 805 described below in FIGS. 7 and 8, respectively. The devices 605-645 are not limited thereto, and may include, but are not limited to, a computer 605 (eg, laptop computing device), a mobile device 610 (eg, a smartphone or tablet), a television 615, Devices associated with the vehicle 620, server computers 625, computing devices 635-640, and storage devices 630 and 645.

In some implementations, the devices 605-620 can be considered user devices 625-645 that can be associated with a server as described above with respect to FIGS. 3-5.

For example, but not limited to, a user having a user device 605 or 610 on a network supported by one or more devices 625-645 can acquire, license an application using the user device 625-645. You can request, receive licenses, and use the software. The server may perform the above-described operations using the devices 625-645 according to the process described with reference to FIGS. 1-5 using the user device 605 or 610.

Example Computing Environment

7 illustrates an example computing environment having an example computing device associated with an external host for use in some example implementations. Computing device 705 in computing environment 700 may include one or more processing units, cores or processors 710, memory 715 (eg, RAM, ROM, etc.), internal storage 720 (eg, Magnetic, optical, solid state storage and / or organic), and / or I / O interface 725, any of which may be connected to a communication mechanism or bus 730 or a computing device ( 705 may be embedded.

Computing device 705 may be communicatively coupled to input / user interface 735 and output device / interface 740. One or both of input / user interface 735 and output device / interface 740 may be a wired or wireless interface and may be removable. Input / user interface 735 may be any device that can be used to provide input (eg, buttons, touch screen interface, keyboard, pointing / cursor control, microphone, camera, braille, motion sensor, optical reader, etc.), It may include a component, a sensor or an interface, a physical or virtual device. Output device / interface 740 may include a display, television, monitor, printer, speaker, braille, and the like. In some example implementations, input / user interface 735 and output device / interface 740 can be embedded in or physically coupled to computing device 705. In other example implementations, other computing devices may function as or provide functionality as input / user interface 735 and output device / interface 740 for computing device 705.

Examples of computing devices 705 include highly mobile devices (eg, smartphones, devices in vehicles and other machines, devices worn by humans and animals, etc.), mobile devices (eg, , Tablets, laptops, laptops, personal computers, portable televisions, radios, etc., and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions embedded in and / or connected to processors, radios, etc.) ), But is not limited to such.

Computing device 705 is configured to communicate with any number of networked components, devices, and systems, including one or more computing devices of the same or different configurations (eg, I / O interface 725 May be connected to the external storage device 745 and the network 750. Computing device 705 or any connected computing device may function as, or provide, or refer to as a server, client, thin server, general purpose machine, special purpose machine, or other label.

I / O interface 725 may include a wireless communication component (not shown) that facilitates wireless communication over a voice and / or data network. The wireless communication component can include an antenna system, a wireless system, a baseband system, or any combination thereof with one or more antennas. Radio frequency (RF) signals may be transmitted and received wirelessly by an antenna system under management of a wireless system.

I / O interface 725 is any communication or I / O protocol or standard (eg, Ethernet, 802.11) for communicating information to / from at least all connected components, devices, and networks in computing environment 700. x, universal system bus, WiMax, modem, cellular network protocols, etc.) and / or a legacy and / or wireless interface. The network 750 can be any network or combination of networks (eg, the Internet, local area network, wide area network, telephone network, cellular network, satellite network, etc.).

The computing device 705 may communicate using and / or using computer usable or computer readable media, including temporary media and non-transitory media. Transient media include transmission media (eg, metal cables, optical fibers), signals, carriers, and the like. Non-transitory media include magnetic media (e.g. disks and tapes), optical media (e.g. CD ROMs, digital video disks, Blu-ray disks), solid state media (e.g. RAM, ROM, flash memory, solid state storage) and others Non-volatile storage or memory may be included.

Computing device 705 may be used to implement techniques, methods, applications, processes or computer executable instructions in some example computing environments. Computer-executable instructions can be obtained from a temporary medium, stored in a non-transitory medium, and obtained there. Executable instructions can come from one or more programming, scripting, and machine languages (such as C, C ++, C #, Java, Visual Basic, Python, Perl, JavaScript, etc.).

The processor (s) 710 may run under any operating system (OS) (not shown) in a native or virtual environment. Inter-unit communication mechanism 795, logic unit 760, application programming interface (API) unit 765, input to allow different units to communicate with each other, with the OS, and with other applications (not shown). One or more applications may be used, including unit 770, output unit 775, acquisition confirmation and user request review unit 780, license issue determination unit 785, license generation unit 790. For example, the acquisition confirmation and user request review unit 780, license issue determination unit 785, and license generation unit 790 may implement one or more processes shown in FIGS. 1-5. The units and elements described may vary in design, function, configuration or implementation and are not limited to the description provided.

In some example implementations, one or more other units (eg, logic unit 760, input unit 770, output unit 775, acquisition confirmation, etc.) after API unit 765 receives information or execution instructions. And communicate with the user request review unit 780, license issue determination unit 785, and license generation unit 790.

For example, after input unit 770 receives input from a user, such as an instruction to obtain an application, a license request, or other such user interaction, input unit 770 uses API unit 765. Communicate with the data acquisition confirmation and user request review unit 780. For example, the acquisition confirmation and user request review unit 780 may make a determination as to whether a license should be issued as described above.

The acquisition confirmation and user request review unit 780 may interact with the license issue determination unit 785 via the API unit 765 to provide an output of whether a license has been issued. Using the API unit 765, the acquisition confirmation and user request review unit 780 can interact with the license generation unit 790 to generate a license and provide the license to the user, as described above.

In some examples, logic unit 760 controls the flow of information between units and determines API unit 765, input unit 770, output unit 775, acquisition confirmation and user request review unit 780, license issue determination. 1780 and may direct the services provided by license generation unit 790. For example, the flow of one or more processes or implementations may be performed alone or by an API unit (such as logic unit 760). 765).

Example implementations can have various advantages and advantages. For example, security enhancements are provided to reduce the risk of hackers gaining sensitive information or using applications during the license activation and validation process, and the risk of information leakage from software developers.

While some example implementations have been shown and described, these example implementations are provided to convey the subject matter described herein to those skilled in the art. It is to be understood that the subject matter described herein may be embodied in various forms without being limited to the example implementations described. The subject matter described in this specification may be practiced with other or different elements or matters, without or specifically described or described. It will be understood by those skilled in the art that changes may be made in this exemplary implementation without departing from the subject matter described herein as defined in the appended claims and equivalents thereof.

Claims (17)

A method of software activation and license tracking, the method comprising:
(a) acquire an acquisition confirmation associated with acquisition of software and provide the acquisition confirmation to a server associated with software activation and licensing;
(b) request a license so that a client is authorized to use the software, wherein the license is secured with a private key by a server and the private key is not stored on the client;
(c) issue and provide said license to a client;
(d) verify the license at the client;
(e) store the license at the client;
(f) periodically track the activation status of the license; And,
(g) based on the activation state of the license, performing an action on the license at the client,
Verifying the license at the client includes checking the license received from the server at a client associated with the application and storing the license at the client,
Way. The method of claim 1,
The acquisition confirmation includes at least one of an activation key and a record of a database associated with the server;
The server providing instructions to the user for replacing the acquisition confirmation with the software license,
Way. The method of claim 1,
The acquisition confirmation is obtained by either direct sales, sales through third party resellers, and distribution via box version or online on physical media,
Way. The method of claim 1,
The acquisition confirmation is generated by at least one of a URL associated with a server generating the acquisition confirmation, a mass generation of a plurality of acquisition confirmations, and a single generation of the acquisition confirmation,
Way. The method of claim 4, wherein
The acquisition confirmation generated by the URL is,
Provide the user with web page access to obtain the acquisition confirmation;
Receive necessary information associated with the user;
If the purchase of the application is successful, provide the server with the necessary information of the user and the acquisition information to the user, wherein the order information of the application is stored in the server, and the acquisition confirmation is performed by the server. Generated; And,
If the purchase of the application is not successful, providing the user with an indication that the purchase of the application was not successful,
Way. The method of claim 1,
The acquisition confirmation is provided to the user without encryption,
Way. The method of claim 1,
The method,
Generating the acquisition confirmation by at least one of providing a unique login and password information pair, establishing a secure connection with a server protected with a security key, and establishing a connection with the server to transmit a parameter identifying the user Creating a record at the server associated with
After the user provides the identification, storing information about the acquisition of the application on the server,
Way. The method of claim 1,
(C) and (d) above,
Receive the acquisition confirmation from the user;
The client generates the license request and provides it to the server;
The server determines whether activation is allowed for the acquisition confirmation;
If the activation is allowed, the server issues a license based on the user's identification information and provides the user with a file of the license,
Way. The method of claim 1,
The acquisition confirmation comprises one or more activation keys recognized by the installation of the application and generated using a pattern with a specific suffix that will trigger the appearance of a form for the user to provide information to the server,
The supplier of the application can determine the pattern based on its pattern,
Way. The method of claim 1,
The license is generated including parameters associated with at least one of a bundle ID of the application, one or more identifiers of the client, and a randomly generated string,
Way. The method of claim 1,
The verification includes performing verification of the license generated on the server, the license being signed with a unique and secure private key that generates a digital signature, the digital signature being further added by the public key of the software at the client. Verified, the software includes a vendor application,
Way. A non-transitory computer readable medium configured to perform an operation for software activation and license tracking, the operation comprising:
(a) acquire an acquisition confirmation associated with acquisition of software and provide the acquisition confirmation to a server associated with software activation and licensing;
(b) request a license so that a client is authorized to use the software, wherein the license is secured with a private key by a server and the private key is not stored on the client;
(c) issue and provide said license to a client;
(d) verify the license at the client;
(e) store the license at the client;
(f) periodically track the activation status of the license; And,
(g) based on the activation state of the license, performing an action on the license at the client,
Verifying the license at the client includes identifying the license received from the server at a client associated with the application and storing the license at the client;
Non-transitory Computer-readable Media. The method of claim 12,
The acquisition confirmation generated by the URL,
Provide the user with web page access to obtain the acquisition confirmation;
Receive necessary information associated with the user;
If the purchase of the application is successful, provide the server with the necessary information of the user and the acquisition information to the user, wherein the order information of the application is stored in the server, and the acquisition confirmation is performed by the server. Generated; And,
If the purchase of the application is not successful, providing the user with an indication that the purchase of the application was not successful,
Non-transitory Computer-readable Media. The method of claim 12,
The acquisition confirmation is provided to the user without encryption,
Non-transitory Computer-readable Media. The method of claim 12,
The operation is,
Generating the acquisition confirmation by at least one of providing a unique login and password information pair, establishing a secure connection with a server protected with a security key, and establishing a connection with the server to transmit a parameter identifying the user Generating a record at the server associated with the
After the user provides the identification, storing information about the acquisition of the application on the server,
Non-transitory Computer-readable Media. The method of claim 12,
(C) and (d) above,
Receive the acquisition confirmation from the user;
The client generates the license request and provides it to the server;
The server determines whether activation is allowed for the acquisition confirmation; And
If the activation is allowed, the server issues a license based on the user's identification information and provides the file of the license to the user,
The acquiring confirmation includes one or more activation keys that are recognized by the installation of the application and are generated using a pattern with a specific suffix that will trigger the appearance of a form for the user to provide information to the server,
The supplier of the application can determine the pattern based on its pattern,
Non-transitory Computer-readable Media. The method of claim 12,
The verification includes performing verification of the license generated on the server, the license being signed with a unique and secure private key that generates a digital signature, the digital signature being further added by the public key of the software at the client. Verified, the software includes a vendor application,
Non-transitory Computer-readable Media.

Images