JP4765459B2 - License authentication device - Google Patents

Description

The present invention relates to a license authentication apparatus using a network.

Electronic information such as software programs (hereinafter referred to as “software”) has a characteristic that it can be copied many times theoretically while ensuring the identity and quality of the contents. For this reason, in the distribution of software programs, a use restriction program is applied to the software to prevent unauthorized use by users who do not have usage rights. This is to ensure that the developer has an opportunity to get the right price.
On the other hand, a user who purchases a storage medium such as a CD (Compact Disc) at a store or receives a software download through a network download service, accesses a website prepared by the developer and grants permission to use the software. Use restrictions can be lifted by receiving. Hereinafter, an outline of a conventional activation system using the flow diagram of Figure 11. In FIG. 11, the client and the license management server can transmit and receive electronic information through the Internet.

When the user starts the software installed on the personal computer (step S101), the client determines whether there is software license data (hereinafter referred to as “license data”) in the common reference area inside the operating system (step S101). Step S102). If there is no license data (step S103), the product is started from the common reference area asking for input of product specifying information (for example, product number) enclosed in the software package, the user's name, address, etc. Hardware identification information (for example, manufacturing serial number) of the personal computer is read (step S103), an inquiry code is created from the information, and is transmitted to the license management server (step S104).
The license management server analyzes the supplied inquiry code (step S201), registers user information, product identification information, hardware identification information, and a license code to be issued, and then transmits the license code to the client ( Step S202).
When the transmitted license code is input by the user (step S205), the client performs a predetermined calculation process to determine whether the calculation result matches the code stored in advance in the software (step S206). If so (step S206: YES), the software use restriction is removed and the software program body is read (step S207).

  Since the license issuance destination (that is, a specific user or personal computer) remains in the license management server, if a person who has transferred the software from a user who has a post-authoritative authority uses the same software, the license must be acquired again. The request is compared with the contents stored in the license management server. By this comparison, it is determined whether or not the user has a proper use authority, and whether or not the license code is issued is controlled.

Attempts to prevent such unauthorized copying of software have become commonplace, and various improved techniques have been developed in the present age. For example, a technology has been developed in which a license authentication request transmitted from a client is encrypted, and the license management server converts the cipher into flat parts, and determines whether or not to issue a license code based on the flat license information ( Patent Document 1). That is, when a license authentication request is made from a client, the license management server determines whether to issue a license code based on the license information stored in the previous registration process. For this reason, when the license information stored in the license management server is falsified, it is no longer possible to determine whether or not a license code can be issued to the client. In order to solve such a problem, the invention described in Patent Document 1 stores license information stored in a license management server as encryption.
JP-A-9-319571

  However, once the license code is issued, there is a problem that the use restriction can be released even by a person other than the person who has the right to use the software with the license code. For example, after purchasing a piece of software and obtaining a license code, installing this software on another client and entering the license code allows those who do not have the right to use it to use the software. . Developers can only get the first price.

  On the other hand, there is a problem that the license code cannot be released and remains permanently. For example, there is a case where a software sales agent performs a demonstration by actually starting the software at a store for sales promotion. Generally, the software package to be used is the product to be sold. Distributors need to pay developers even for sales promotion. Therefore, the license code is obtained from the license management server in order to remove the usage restriction. However, once the license is registered, the license management data remains on the management server to permanently identify the user, and the license code is released or returned. And cannot be resold. In particular, if the demonstration software is expensive, there is a problem that the cost is high and sales promotion is significantly hindered.

  An object of the present invention is to perform license distribution and re-registration to distribute software properly and smoothly, and to prevent adverse effects such as duplicate registration and diversion of licenses associated with license cancellation and re-registration. is there.

According to the first aspect of the present invention, there is provided a client that is connected via a network and that transmits issuance request data for execution license code of software executed by the client, and that receives the execution license issuance request data to the client. In a software license authentication apparatus comprising a license management server for notifying an execution license code,
The client includes transmission means for generating the execution license issuance request data from network communication address data and transmitting the generated data to the license management server, and the client is further provided with a verification key indicating correspondence with the software. , Including the verification key data in the execution license code issuance request data,
The license management server
Extraction means for extracting the network communication address data from the execution license issue request data;
Search means for searching for data matching the network communication address data from a database pre-stored with the execution license code issue destination;
A license issuing means for notifying the client of the execution license code when there is no data matching the network communication address data as a result of the search by the search means ;
The extraction means further extracts data of the verification key,
The retrieval means further retrieves a collation key included in the execution license issuance request data from the database further storing the collation key data,
Result of the search, when there is no data matching key that matches the data of the matching key, characterized in Rukoto includes a license issue means for notifying said execution license code to the client.

The invention according to claim 2 is the license authentication apparatus according to claim 1 ,
The client further comprises execution license release requesting means for requesting the license authentication server to release the execution license code after obtaining the execution license code,
The license management server receives the execution license code release request data from the execution license release request unit, and deletes any of license data, network communication address data, and verification key stored in the database. Is further provided.

The invention described in claim 3 is the license authentication apparatus according to claim 2 ,
The client is characterized in that when the execution license release requesting unit requests the license management server to release the execution license code, the client's verification key is rewritten with a different verification key.

The invention according to claim 4 is the license authentication apparatus according to claim 2 or 3 ,
Execution license acquisition status confirmation means for storing that the execution license has been acquired when the client has the execution license when the client backs up the system;
An execution license deleting unit that refers to the execution license acquisition status unit each time the client starts up the software and deletes the execution license code when the execution license has been acquired. To do.

The invention according to claim 5 is the license authentication apparatus according to claim 4 ,
After the execution license deletion unit deletes the execution license code, the execution license deletion unit further includes a warning unit that suggests a reissue request for the execution license to a software user.

According to the present invention, the network execution address issuance request data of software transmitted from the client to the license management server is included in the network communication address data (for example, MAC address) of the client, and the license management server based on this data, By performing a client search from a database storing past address issue destinations, it is possible to prevent duplicate execution license codes from being issued. In particular, since the network communication address data (for example, MAC address) is a unique code that does not exist in principle in the same network environment within the same standard, the client can be reliably identified.
Also, a unique verification key is assigned to each client, this verification key is included in the execution license issue request data, and more reliable identification is performed when searching for a client from a database storing past address issue destinations. be able to.
In addition, with a configuration that allows the execution license to be released, the execution license is acquired, released, and re-registered, unlike the license authentication device that previously bound the client permanently once the execution license was issued. be able to. As a result, it is possible to remove the constraint imposed by the software execution license that has hindered the software distribution.
Furthermore, in response to the problem of execution license free (unauthorized release) of software caused by the configuration that enables acquisition, release, and re-registration of execution licenses, when the execution license is released, Perform processing such as rewriting the verification key with another verification key, and compare the verification key when starting up the software on the client or receiving the execution license issuance request data at the license management server. If it is, it is possible to restrict the use of software or prohibit the issuance of an execution license code. As a result, in the management of software execution licenses using the network, the reliability is remarkably improved, the opportunity for developers to acquire a reasonable price for software development is secured, and the sales promotion costs of distributors in software distribution are reduced. Can be realized.

[First Embodiment]
Next, the best mode for carrying out the present invention will be described with reference to the drawings. In the first embodiment, in a license authentication system that includes a client that makes a software use license request and a server machine that issues a software use license in response to the request, the license request transmitted from the client is unique. Information is added to prevent duplicate licenses from being issued to the same client on the server machine.

FIG. 1 shows an outline of the overall configuration of a software license authentication system 1 to which the present invention is applied.
The license authentication system 1 is configured such that a client 2 and a license management server 3 are connected via a network 5 so that bidirectional communication is possible. A plurality of clients can be installed according to various rules and processing capabilities of the network 5 and the license management server 3.
As the client 2, a PC, a workstation, a mobile phone, a PHS (Personal Handyphone System), a PDA (Personal Digital Assistant), a game machine, or the like can be applied.
The license management server 3 may be configured to apply a workstation and a PC including a large server. Similar to the client 2, it can be changed as appropriate according to the rules and processing capability with the network 5 and the client 2. In this embodiment, a large server machine is applied. The license management server 3 also includes software license information issued to each client in the past, information about each client, a client that newly requests license authentication, and a database 4 that stores the license information.
The network 5 includes a communication network (communication network) such as a LAN (Local Area Network), a MAN (Metropolitan Area Network), a WAN (Wide Area Network), and the Internet. In the present invention, description will be made by applying the Internet.

FIG. 2 shows a schematic configuration of the client 2.
The client 2 includes a CPU 6, a RAM 7, a storage unit 8, a display unit 9, an input unit 10, and a communication unit 11. The CPU 6 develops an operation program and various application programs in a RAM 7 as a work area and performs overall control of the client 2. A license request signal, which will be described later, is generated, the request signal is transmitted, and a license signal is received from the license management server 3.
The storage unit 8 includes a nonvolatile memory such as an EPROM (Erasable Programmable Read Only Memory) or a hard disk. In addition to the operation program and application program used in the client 2, various data generated in cooperation with these software are stored, and application software for which a use license request is made is stored.

  The display unit 9 is composed of a CRT (Cathode Ray Tube), a TFT (Thin Film Transistor) liquid crystal display element, and an FDP (Flat Display Panel) using an organic EL element, and displays various processes in the client 2. . The input unit 10 is composed of a keyboard, a numeric keypad, a mouse, or a combination thereof, and inputs various instructions by user operations. As a configuration in which a touch panel is provided on the display unit 9, the display unit 9 and the input unit 10 may be combined.

  The communication unit 11 communicates with an external device. It is composed of a communication device such as a NIC (Network Interface Card) and performs communication via the Internet or the like in accordance with a predetermined protocol (protocol). An address on the Internet (hereinafter referred to as “MAC address”) is given to the client.

Next, various data used when the client 2 generates a license request signal to be transmitted to the license management server 3 will be described. FIG. 3A shows a configuration example of the license request file 15 that stores various data for generating a license request signal.
The license request file 15 includes a lineup code 20, a CD key 21, MAC address data 22, a verification key 23, and a license code 24.
The lineup code 20 is a product code attached to the software. A configuration in which an original standard code is provided in advance or an existing standardized code (for example, JAN (Japanese Article Number) code) or the like may be used. The line-up code 20 is preferably assigned a different number for each software type and version. This is to ensure uniqueness. For example, in the distribution stage, a set sale in which a plurality of software is packaged may be performed, but the user may desire to use only a part of the bundled software. In such a case, a part of software desired to be used can be specified individually.
The CD key 21 is a serial number assigned to the software. In principle, there is no same serial number in the same software, and uniqueness can be guaranteed.
The MAC (Media Access Control) address data 22 is an address given to the communication unit 11 based on the communication protocol of the network 5. In this embodiment, it corresponds to the Internet address assigned to the client 2 based on the Internet protocol. In a communication environment under the same convention, the same MAC address does not exist and uniqueness can be ensured.
The collation key 23 is a specific code stored in a management database (for example, a registry) that manages various settings of the client 2 by the application software. When a user inserts a recording disk or the like on which application software is stored, a specific code is written as a verification key in this management database. The collation key may be any number, symbol, character code, or a combination thereof, but is preferably a different code so that there is no same thing. This is because uniqueness is ensured, and the license management server 3 becomes one of the elements for specifying the client for the subsequent software license processing.
The license code 24 is an area in which a license code for canceling the use restriction when a use license for software is acquired is stored. If a use license has been obtained in the past, the use restriction of the software can be lifted by inputting this license code when the software is subsequently used.

Next, the license issuance file 16 that stores data referred to by the license management server 3 in the license issuance processing performed by the license management server 3 will be described. FIG. 3B schematically shows the file structure of the license issuance file 16.
The license issuance file 16 stores a product master table 26, a license issuance table 25, and a customer data table 27.
The product master table 26 includes a line-up code group 32 such as line-up codes N1a, N1b, and N1n for each software to be licensed, and a CD key group such as CD keys N1a, N1b, and N1n stored in association with the line-up codes. 33. That is, the line-up code and the CD key for each software product are stored in the database 4 when the software product is shipped.
The license issuance table 25 stores a MAC address group 30 such as MAC addresses N1a, N1b, and N1n and a collation key group 31 such as collation keys N1a, N1b, and N1n when issuing a license. The MAC address data N1a, N1b and N1n and the collation keys N1a, N1b and N1n are associated with the line-up codes N1a, N1b and N1n stored in the product master table 26, respectively.

  The customer data table 27 stores data related to software owners registered at the time of license issuance. This data is referred to by the license management server 3 when requesting a license.

The operation of the license authentication system 1 having the above configuration will be described with reference to FIGS. In the following description, it is assumed that the software subject to the license request is recorded on an optical disc such as a CD (Compact Disc) or a DVD (Digital Versatile Disc), and the user records the software on the optical disc. Assume that you have purchased and installed it in a bootable state.
Also, the software that is the target of the license request may be downloaded from an external device via a communication network (communication network) such as the network 5 and the installation is completed in a startable state.

In FIG. 4, when the user instructs to start the software and the reading of the software is started (step S301), the CPU 6 reads the software line-up code 20 and the CD key 21 from the recording medium (step S302).

  Next, the MAC address is read and acquired from the setting management database that stores various setting data of the client (step S303). Further, it is searched whether there is a collation key 23 in the setting management database (step S304). If the collation key 23 is already stored (step S305: YES), the collation key 23 is acquired. On the contrary, when there is no collation key 23 (step S305: NO), the collation key 23 memorize | stored in the recording medium is written in a setting management database, and is read simultaneously (step S306).

  Next, license request data is generated from the lineup code 20, the CD key 21, the MAC address data 22, and the verification key 23 (step S307). At this time, the license request data is encrypted by a known technique. Thereafter, the license request data is transmitted to the license management server 3 via the communication unit 11 (step S308).

Next, the processing of the license management server 3 that has received the license request data will be described with reference to the flowchart shown in FIG.
The license management server 3 decrypts the encrypted license request data, and acquires the lineup code 20, the CD key 21, the MAC address data 22, and the verification key 23 (step S401). Thereafter, the corresponding line-up code N00a is searched from the line-up code group 32 using the line-up code 20 as a search key, and the CD key group 33 corresponding to this line-up code N1a is further searched and acquired (step S402). That is, a serial number group assigned to each software product of a specific type or version is acquired.

  Next, it is determined whether or not the CD key 21 acquired from the license request data exists in the CD key group 33 (step S403). In principle, the CD key attached to the software product distributed in the regular process is always stored in the product master table 26. Therefore, if the CD key 21 acquired from the license request data does not exist in the CD key group 33 (step S403: NO), it is processed as a license request for illegally distributed merchandise or a data error (step S409). On the other hand, if the corresponding CD key exists in the determination in step S403 (step S403: YES), the process proceeds to step S404.

  In step S404, the corresponding MAC address data N1a and collation key N1a are searched from the license issuance table using the line-up code 20 and CD key 21 acquired in step S402 as search keys. The license issuance table 25 is data stored as issuance history in the database 4 when a license has been issued for the same software product in the past. Accordingly, when a new license request is made, naturally, the data corresponding to the MAC address data 22 and the verification key 23 does not exist in the license issuance table 25.

If the MAC address data N1a acquired from the license issuance table 25 matches the MAC address data 22 acquired from the license request data in step S405, or the MAC address data N1a exists in the license issuance table 25 Then, it is determined whether the MAC address data N1a and the MAC address data 22 do not match.
If the MAC address data 22 and the MAC address data N1a match or the MAC address data N1a does not exist in the license issuance table 25 (step S405: YES), the process proceeds to step S406. On the other hand, if the MAC address data N1a and the MAC address data 22 do not match (step S405: NO), it is determined that duplicate licenses have been acquired, and the process of step S409 is performed as an illegal execution license acquisition procedure.

  Next, in step S406, it is determined whether or not the verification key N1a acquired in step S404 matches the verification key 23 acquired from the license request data. When a new license request is made, the verification key N1 does not exist on the license issuance table 25 as described in step S405 described above. This case is handled in the same way as when both collation keys match.

  If the collation key 23 and the collation key N1a match (step S406: YES), the process proceeds to step S407. On the other hand, if they do not match (step S406: NO), it is determined that the license is diverted, and the process of step S409 is performed as an illegal acquisition act.

  In step S407, based on the processing results from step S402 to step S406, it is determined that the license request is valid, and a license code for canceling the software use restriction is generated. The license code is generated from the lineup code 20, the CD key 21, the MAC address data 22, and the verification key 23. Thereafter, the license code is transmitted to the client 2 (step S408).

  By the way, if it is determined in steps S403, S404, and S406 that the license has been illegally acquired or a data error (NO in any of steps S403, S404, and S406), a license indicating a message indicating that the license cannot be issued. Unissued data is generated (step S408) and transmitted to the client 2.

  Returning to FIG. 4, the client 2 that has received the license code issued from the license management server 3 (step S309) stores the license code in the storage unit 8 of the client 2 (step S310). Thereafter, the license code is read out and input to the use restriction management tool, the use restriction of the software main body is released, and activation is started (step S311).

  As described above, according to the license authentication system in the first embodiment, in addition to the individual unique code added to the license request data from the client 2 for each software product, the hardware called the MAC address of the client 2 Since the information is included, the client 2 can be identified more reliably when issuing the license. Furthermore, since the unique verification key 23 is stored in the client 2 and the information on the verification key 23 is included in the license request data, the license management server 3 can remarkably identify the client 2. The license management of the software is ensured by referring to the license request data with high certainty from the client having the right to use the software and the information of the license issuance file stored in the database 4. As a result, unauthorized license acquisition can be reliably prevented even if the license is released and re-registered.

[Second Embodiment]
Next, a second embodiment for carrying out the present invention will be described. In the first embodiment, the license request data is generated by including various unique codes, and the license request data and the various data registered in the database 4 are collated to reliably identify the client 2. This was to prevent unauthorized license acquisition such as licenses.
On the other hand, in the second embodiment, processing for canceling the license code once acquired is performed. By releasing the license code, the license for each software will not be bound by a specific client, and in order to facilitate the re-acquisition of the license code, software distribution is ensured while ensuring the developer's price for software development. Can be performed smoothly.
However, when the processing configuration is such that the license code is simply released, there arises a problem of illegal license acquisition such that a plurality of license codes can be acquired by a single client.
Therefore, in the license authentication system 1 of the second embodiment, once a license code release request is made, the client is provided with a function that cannot remove the software use restriction by the previous license code.

The license authentication system 1 of the second embodiment has the same basic configuration as the license authentication system of the first embodiment.
In addition, in the following description, what has the same function as 1st Embodiment is shown with the same code | symbol, and detailed description is abbreviate | omitted.

FIG. 6 is a flowchart showing the processing of the license authentication system 1 in the second embodiment.
When the license release application is activated by a user operation (step S501), the CPU 6 accesses the setting management database and reads and acquires the verification key 23 and the MAC address (step S502). Thereafter, a license release request code is generated from the license code 24, the lineup code 20, the CD key 21, and the verification key 23, and encrypted by a predetermined method (step S503).

  Next, the CPU 6 rewrites the collation key 23 stored in the setting management database with the collation key 23B (step S504). This rewriting is to change to “2” if the previous verification key 23 is “1”. As a result, the client 2 has a different verification key in the license management server 3 thereafter in relation to the software that issues the license release request. When the rewriting of the verification key 23 is completed in step S504, the license release request data is transmitted to the license management server 3 (step S505).

  Upon receiving the license release request, the license management server 3 decrypts the license release request and obtains the license code 24, the lineup code 20, the CD key 21, the MAC address data 22, and the verification key 23 (step S601). Thereafter, the database 4 is accessed to perform processing for deleting (invalidating) each data from the license issuance file 16 (step S602).

As described above, in the second embodiment, the transmission of the license release request data from the client 2 changes the verification key 23 in the client 2 to a different code (verification key 23B). Even when activated, activation of the software main body is restricted by the software use restriction management tool in the client 2. Specifically, this will be described with reference to the flowchart shown in FIG.
When the software program is started after releasing the license (step S701), the CPU 6 develops the software use restriction management tool according to the program and starts checking the software use license of the client 2 (step S702).

The license code 24 stored in the storage unit 8 or the like is read (step S703), the lineup code 20, the CD key 21, the MAC address data 22 and the collation key 23 included in the license code 24, the software lineup code 20, It is determined whether the MAC key data 22 stored in the CD key 21 and the setting management database matches the verification key 23 (step S704).
If it is determined in step S704 that there is a mismatched code or the like (step S704: NO), the license code is recognized as an error (step S705), and a warning display prohibiting activation of the software is performed (step S706). ). That is, if the verification key 23 is the verification key 23B, the software license code is recognized as an error.
If the element data constituting the license code 24 match in the determination in step S704, it is recognized that the license code is valid (step S707), the use restriction is removed, and the activation of the software body is started.

  As described above, according to the license authentication system 1 of the second embodiment, since the verification key on the setting management database is rewritten when the client 2 makes a license release request, the software execution permission when the software is restarted Even if a conventional license code is input in the process, the use restriction can be surely executed without starting the software body.

[Third Embodiment]
Next, a third embodiment for carrying out the present invention will be described.
In the third embodiment, it is assumed that after the client 2 makes a software license request, the client once makes a license release request, requests the license again, and uses the software. The use of software at this time is based on a legitimate license and is legitimate.
However, the license release request data (hereinafter referred to as “license release”) sent from the client 2 to the license management server 3 when the previous license release request was made in the state where the license was released and then requested again. There is a problem that occurs when a license release request is made using request data A ”). That is, the license release request data transmitted to the license management server 3 when the license release request of the client 2 is made is the same regardless of how many times the license is acquired and released.
Accordingly, as described above, the license code is requested once, and after the license code is issued, a license release request is generated and the license release request data is transmitted to the license management server 3. At this time, the license release request data is backed up (that is, the license release request data A is backed up). Thereafter, a license issuance request is made again to obtain a license code. Then, a license release request is made using the license release request data A that has been backed up. At this time, the license management server 3 releases the license code of the client 2. However, since the client 2 actually deploys the use restriction management tool based on the license code acquired for the second time, it is the same as in the past. You can use the software.
Therefore, in the third embodiment, it is determined whether the license release request data transmitted to the license management server 3 is valid license release data. If the license release request data is invalid, the release request is not accepted. It is characterized by doing so.

  The license authentication system 1 according to the third embodiment will be described with reference to the flowchart shown in FIG. In the following description, detailed description of processes common to the first embodiment and the second embodiment is omitted.

  When license release request data is transmitted from the client 2 (step S801) and received by the license management server 3 (step S901), the license code 24, the lineup code 20, the CD key 21, and the MAC address data 22 included in the license release request data. The collation key 23 is acquired (step S902).

Of these codes, the license issuance file stored in the database 4 is searched using the license code 24 and the MAC address data 22 as keys, and the same data is detected (step S903).
If there is the same data (step S903: YES), the latest collation key N1b among the collation keys N1 is acquired (step S904). That is, in the third embodiment, the client 2 makes a second license issuance request, and the license issuance table 25 stores the rewritten verification key 23B.

  Thereafter, it is compared whether the verification key 23 included in the license release request data matches the verification key N1 (step S905). If they match (step S906: YES), the license release request data is recognized as valid, and the license code is released (step S907). On the other hand, if they do not match (step S906: NO), warning data prohibiting license release is generated assuming that the license release request data is invalid (step S908). Thereafter, license release end data or release prohibition warning data is transmitted to the client 2 (step S909).

  As described above, according to the license authentication system 1 in the third embodiment, in order to determine the validity of the license release request code itself, the license of the software is released using the license release request code used in the past license release request. Can be prevented.

[Fourth Embodiment]
Next, a fourth embodiment for carrying out the present invention will be described.
In the fourth embodiment, it is assumed that the client has restored the client after transmitting the license issuance request data and obtaining the software use license.
Restoration is to restore the client system from the data that was backed up before the client computer system is once brought into a default state and then brought back to the default state. By setting the client to the default state, the license information such as the license code stored in the setting management database is also defaulted (that is, deleted). For this reason, once the software license code is acquired and the license code is stored, the system is backed up to an optical disk or the like. Thereafter, the license release request data is transmitted to the license management server, and the license on the server is released. After making a license release request, the client is once defaulted. At this time, the license data is also defaulted (deleted). Thereafter, the client system is restored with the backup optical disk. After the restoration, the system state before the default, that is, the state before a software release request is issued to the license management server. The client has a problem that the software can be activated even though the license is released on the license management server.
Therefore, the fourth embodiment is characterized in that the use of software is restricted when a client is restored.

  FIG. 9 shows a schematic configuration of the client 40 of the license authentication system 1 in the fourth embodiment. The basic configuration is common to the first to third clients 2. In particular, an NVRAM (Non-Voltage RAM) 41 is provided as a different configuration. The NVRAM 41 is a non-volatile memory, and the stored contents are not deleted even if the computer system is defaulted. A program or the like (for example, BIOS) for instructing the CPU 6 to read operation software when the computer or the like is activated is stored.

  The process in the client 40 of the license authentication system 1 will be described with reference to the flowchart shown in FIG. In the following description, detailed description of the same processing as in the first, second, and third embodiments is omitted.

  When receiving an instruction to back up the system of the client 40 by a user operation (step S1001), the CPU 6 turns on a flag provided in the NVRAM 41 before performing the backup (step S1002). Next, the system is backed up (step S1003), and the system of the client 40 is defaulted (step S1004).

  Thereafter, when the user restores the system of the client 40 from the backup (S1005) and activates the software (step S1006), the CPU 6 develops a software usage restriction management tool and accesses the NVRAM 41 to check the flag state. (Step S1007). If the flag is ON (step S1008: YES), it is determined that the computer system of the client 2 has been backed up (step S1009), and the software license code 24 is deleted (step S1010). Thereafter, the flag is turned off (step S1012), and guidance indicating the acquisition of the license code is displayed again on the display unit 9 (step S1012).

  If it is determined in step S1008 that the flag is OFF (step S1008: NO), it is determined that the computer system of the client 40 has not been backed up (that is, the license is properly operated), and Start-up is started (step S1013).

  As described above, according to the client 40 in the fourth embodiment, when the backup is performed, the flag provided in the NVRAM 41 is turned ON, so that the system is backed up even after the client is defaulted later. Can be determined. When restarting the client 2, if it is determined that the system has been backed up, the license information is deleted and the license issuance procedure is performed again, thereby preventing unauthorized release of the license. it can.

  As mentioned above, although the best form for implementing this invention was demonstrated, this invention is not limited to the said various example.

It is the schematic which showed the structure of the license authentication system to which this invention is applied. It is the block diagram which showed the outline | summary structure of the client in the license authentication system to which this invention is applied. FIG. 3A is a schematic diagram showing the structure of a client license request file in the license authentication system to which the present invention is applied. FIG. 3B is a schematic diagram showing the structure of the license issuance file of the license management server in the license authentication system to which the present invention is applied. It is the flowchart which showed the operation | movement of the license authentication system in the 1st Embodiment of this invention. It is the flowchart which showed the operation | movement of the license authentication system in the 1st Embodiment of this invention. It is the flowchart which showed the operation | movement of the license authentication system in the 2nd Embodiment of this invention. It is the flowchart which showed the operation | movement of the license authentication system in the 2nd Embodiment of this invention. It is the flowchart which showed the operation | movement of the license authentication system in the 3rd Embodiment of this invention. It is the block diagram which showed the structure of the client of the license authentication system in the 4th Embodiment of this invention. It is the flowchart which showed the operation | movement of the license authentication system in the 4th Embodiment of this invention. It is the flowchart which showed the operation | movement of the conventional license authentication system.

Explanation of symbols

1 License Authentication System 2, 40 Client 3 License Management Server 4 Database 5 Network 6 CPU
7 RAM
8 Storage Unit 9 Display Unit 10 Input Unit 11 Communication Unit 15 License Request File 16 License Issuance File 20 Lineup Code 21 CD Key 22 MAC Address 23 Verification Key 24 License Code 25 License Issuance Table 26 Product Master Table 27 Customer Data Table 41 NVRAM

Claims (5)

A client that is connected via a network and that transmits issuance request data for execution license code of software executed by the client, and a license that receives the execution license issuance request data and notifies the client of the execution license code In a software license authentication apparatus comprising a management server,
The client includes transmission means for generating and transmitting the execution license issuance request data including network communication address data to the license management server, and the client is further provided with a verification key indicating correspondence with the software. Including the verification key data in the execution license code issue request data,
The license management server
Extraction means for extracting the network communication address data from the execution license issue request data;
Search means for searching for data matching the network communication address data from a database pre-stored with the execution license code issue destination;
A license issuing means for notifying the client of the execution license code when there is no data matching the network communication address data as a result of the search by the search means;
Equipped with a,
The extraction means further extracts data of the verification key,
The retrieval means further retrieves a collation key included in the execution license issuance request data from the database further storing the collation key data,
Result of the search, wherein when no data matching key that matches the data for matching key, activation device according to claim Rukoto includes a license issue means for notifying said execution license code to the client. The license authentication device according to claim 1 ,
The client further comprises execution license release requesting means for requesting the license authentication server to release the execution license code after obtaining the execution license code,
The license management server receives the execution license code release request data from the execution license release request unit, and deletes any of license data, network communication address data, and verification key stored in the database. The license authentication apparatus further comprising: The license authentication apparatus according to claim 2 , wherein
The license authentication apparatus, wherein the client rewrites the verification key of the client with a different verification key when the execution license cancellation request means requests the license management server to cancel the execution license code. In the license authentication device according to claim 2 or 3 ,
Execution license acquisition status confirmation means for storing that the execution license has been acquired when the client has the execution license when the client backs up the system;
An execution license deleting unit that refers to the execution license acquisition status unit each time the client starts up the software and deletes the execution license code when the execution license has been acquired. License authentication device. The license authentication device according to claim 4 , wherein
A license authentication apparatus further comprising warning means for suggesting a reissue request for the execution license to a software user after the execution license deletion means deletes the execution license code.

Images