Background Especially in large computer systems, there is a need for vendors to offer optional functions or features that can be made available to an operator if and when they are paid for. In many cases it is feasible to include all features at system generation, to avoid having to make new deliveries each time a customer wants to upgrade his system with a new optional function, which is costly and time consunung. Also the system management becomes increasingly difficult when new deliveries are made.

One example of such a computer system is a modern digital telephone exchange. In telephone exchanges it is particularly important to avoid service interrupt. Therefore, there is a strong desire to be able to change the functionality of a telephone exchange without having to take the exchange out of service.

It is possible to deliver a complete software system to the customer, but to activate only the programs or features the customer has ordered. The other programs or features could then be activated at a later date without new software installation.

This, however, makes it possible for a customer to make unauthorized use of the optional features, if he manages to activate them. Therefore the vendor may wish to check from time to time what features have been used by a particular customer to see if features that have not been paid for have been activated and used in an unauthorized way. This is feasible for vendors of large systems, with a few large customers, where the customers and the vendors stay in close contact over a period of several years, as is the case with telecommunications systems.

Logging functions are commonly used in computer systems to see what functions have been used. A vendor who wishes to verify that only authorized use is being made of a system could at any time request to inspect the log file or log files of the

system. However, log files may be tampered with and erased to hide any unauthorized use of features in the system.

Summary of the Invention It is an object of the invention to enable a system vendor to verify what programs and/or features are used, or not used, by the end users of the system, without the use of additional hardware.

It is another object of the invention to be able to discover any unauthorized use of optional features in the system without the use of additional hardware.

This and other objects are achieved according to the invention by using a log registration file in combination with a log.

In the log, the use of features is logged together with other information about activities that occur regularly in the system, for example about system restarts. In this way, the log is never empty, and log entries occur regularly, unless the log or the logging function has been tampered with. Thus, if someone tries to cheat, it will be revealed in the log.

The invention offers the following advantages: The log enables the vendor of a system comprising optional features to check what features the customer has used since installation.

The log enables the vendor to check that only activated features have been used and that all activation procedures were the result of appropriate business transactions.

The logging of routine activities together with the information about the activationldeactivation of features allows the vendor to check if the logging function and/or the log file has been tampered with.

Brief Description of the Drawings The invention will be described in more detail in the following, with particular reference to the drawings, in which: Figure 1 is a schematic representation of a computer system according to the invention; Figure 2 is a flowchart of the events that occur when someone tries to use an optional feature in a system according to a preferred embodiment of the invention.

Detailed Description of the Embodiments Figure 1 is a schematic representation of a computer system according to the invention. The system comprises a number of basic functions 1, for example an operating system, or, in a telephone exchange, the basic switching functions and the basic subscriber functions.

<BR> <BR> <BR> <BR> <BR> <BR> <BR> There are one or more optional programs and/or features F1, F2, ... , Fn within the programs. As an example, consider an office program package containing a spread sheet, a word processing programming, and file managing program. The word processing program has some optional features, such as a graphics package and an equation editor. If the customer wants only the file managing program and the basic version word processing program, the whole package would be delivered, but the spread sheet program, the graphics package and the equation editor would be locked, or deactivated. Later on, if the customer wanted the graphics functions, it would already be available without any new installation, and would only need to be activated.

If the computer system is a telephone exchange, for example, it may include the basic subscriber services from the beginning, but not optional features such as call waiting and call forwarding, which may be offered to the subscribers, and which may be wanted at a later stage.

The system includes one log indicator 9 stored in such a way that it is not persistent, for example in the random access memory (RAM). In this log indicator it is indicated when a feature is used for the first time. The log records are then written to a log 11 stored on disk, out of reach for the user, so that it cannot be changed or erased manually, as explained in connection with figure 2. It will not be possible to prevent this with 100% certainty, but if attempts to change or erase the log are made, these attempts will leave traces.

When a feature is activated, the feature identity, time of activation, activation state and any other data about the transaction are logged. For example, the vendor may choose to include a transaction-unique seal, which may be stored in the log as an unambiguous indication that the feature was activated as a result of a proper business transaction.

If the system is restarted, the log indicator 9 is erased, but the log 11 is not. When the system is powered up or restarted, some system-specific information that is always present and can be verified against other information sources, is checked and stored in the log 11. In a preferred embodiment, the activation status, and the time and date of the last change of status, of all optional features are registered.

It is possible to log every time a feature is used, but in many cases this would make the log very big and not add any useful information. In some cases the only point of interest, as will be discussed later, is whether or not the customer is using a particular feature, not how many times it is used. To prevent unauthorized persons from tampering with the file it is suggested to let the log consist of a number of sequential files, and to use a wrap-around principle, so that when it is full, the oldest file will be overwritten.

The system vendor may examine the log 11 at regular or irregular intervals, to verify that only the features paid for have been used. If the log 11 comprises information about every time a feature is used, it may also be used, for example, to determine

which features are used by the customers and which ones are not. This information may in turn be used by the vendor to improve the system software.

Figure 2 shows the events that takes place when someone tries to use an optional feature in the system. In the example of the computer system comprising an office program package, this may be when someone tries to run one of the programs or, assuming that a person is working in the word-processing program, for example at an attempt to use the graphics part of the program. In the example of a telephone exchange, it may be when a subscriber tries to use the call forwarding feature.

Step 100: An attempt is made to access a feature.

Step 102: The system checks if the feature has been activated. If yes, go to step 154; ifno, go to step 158.

Step 104: The system checks if the feature has been activated permanently. If yes, go to step 160; if no, go to step 156.

Step 106: The system checks if the last activation date of the feature has not expired.

If yes, go to step 160; if no, go to step 158.

Step 108: Access to the feature is denied. End of procedure.

Step 110: The system checks if the log indication for the feature is activated. If yes, go to step 166; of no, go to step 162.

Step 112: The system creates a log record comprising the feature identity, activation status and current date in the log indication found in RAM.

Step 114: The log record is stored in the log on disk.

Step 116: Access to the feature is granted. End of procedure.

After or in connection to step 108 of course the failed attempt to access the feature could be logged, although this is not shown in the flow chart.

After the limited period of time has expired, it would of course be possible to deactivate the feature.

Instead of making the feature available for a limited period of time, it would be possible to allow the user to test the feature a limited number of times. This could be solved in different ways; for example, the date tag would be replaced by a field registering the number of times the feature may be used, and a field registering how many times the feature had actually been used. In steps 102, 104, 106, the values of these two fields would be compared. Another possible solution would be to register the number of times the user was allowed to use the feature in a counter field and decrement the value of this counter field each time the feature was accessed.