WO1996018939A2

WO1996018939A2 - Software usage metering system

Info

Publication number: WO1996018939A2
Application number: PCT/IB1995/001158
Authority: WO
Inventors: Tamas Hajas
Original assignee: Graphisoft R & D Software Development Company Limited By Shares
Priority date: 1994-12-16
Filing date: 1995-12-15
Publication date: 1996-06-20
Also published as: WO1996018939A3; AU4398196A

Abstract

A method and apparatus for monitoring the use of software functions. The method includes the steps of activating a software function, initializing a usage meter, updating periodically the usage meter and stopping the usage meter when the function is deactivated. In preferred embodiments the meter is updated in response to messages sent from the operating system. The invention also includes internal software integrity checks. Using the method and apparatus of the invention allows software users to pay for only those software functions used, thereby increasing the availability of software to users who would not otherwise pay for a full software package.

Description

SOFTWARE USAGE METERING SYSTEM

BACKGROUND OF THE INVENTION

1. The Field of the Invention

The present invention relates generally to methods and devices for controlling access to software. More particularly, the present invention relates to methods and devices for monitoring software usage.

2. The Relevant Art

The explosion in new markets for software has created vast opportunities for software publishers. One problem that confronts the software industry, however, is similar to that faced by those in the recording and publishing industries, namely, the use of software by individuals who have not compensated the software publisher for the use of the program. Such unauthorized use is commonly referred to as "piracy." The cost to software publishers from authorized use of their programs is estimated to run into the tens, even hundreds, of millions of dollars each year.

Many software packages, especially highly expensive software packages such as computer-aided design (CAD) software, have resorted to various protection schemes to thwart software pirates. In some cases, the software requires the user to enter a password or some other type of identifier to which only licensed users have access. In other cases, the software is available only for a limited period of time. For example, upon starting the software, the program checks the system clock of the computer and determines whether a preset period of time has elapsed. If the time period has not elapsed, program execution proceeds as normal; however, if the time period has been exceeded, the user is notified and the program then quits. In still other cases, the software is available only until a particular date. For example, upon starting the program, the software will query the system clock to determine the present date and compare that date with a value stored in the program. If the date has passed, the user is notified and program execution ceases. In still other types of protection schemes, the software is enabled to be launched only a pre-set number of times. Thus, each time the program is started, a counter is compared with a set value and memory. If the counter is equal to the value and memory, the program notifies the user and exits. If the counter is less than the pre-set value, the counter is incremented and the incremented value is stored for later comparison. Yet other protection schemes include limiting the availability of software commands and functions to the user until the user has registered the program. The recent growth of "on-line" service providers such as CompuServe and the like has popularized systems in which the user is charged for the amount of time spent using the particular service. Thus, for example, when users log on to a system a clock is started which clock stops when the user logs off. The user is charged a fee based on the amount of time they have accessed the system. Similarly, hardware manufactures such as IBM have monitored central processing unit ("CPU") usage time to charge customers for access to IBM computers. However, none of these systems monitor the use of any particular software application.

While the above usage monitoring schemes have their place in the software industry, they suffer from several drawbacks. One particularly noticeable drawback relates to the zero sum nature of the software protection: The user either has complete access to the software or they are completely locked out. For publishers of very expensive, high-end applications, such as computer-aided design and modeling software {e.g., ArchiCAD^®, sold by Graphisoft of Budapest, Hungary) these protection schemes tend to limit the available market for their product. Typically, only those users who have needs strong enough to justify the cost of such sophisticated software packages are willing to pay for access to all of the program's features. However, there is a largely untapped market for users who want access to specific features of the software, for which limited access they would be willing to pay; but, they have no desire to pay for the entire software package. Thus, there is a need to develop a more flexible pricing scheme based on software usage and, more particularly, the use of particular features within software packages.

SUMMARY OF THE INVENTION

The present invention includes a method and apparatus for metering the usage of functions within a software program. In addition, the present invention further includes a method and apparatus for checking the validity of the software usage metering components of the invention. Thus, it will be seen that the present invention overcomes the difficulties of the prior art by providing a highly flexible method of controlling user access to software which control allows software publishers access to larger markets than heretofore available.

In one embodiment, the present invention includes a method and apparatus for metering the use of a software function in a computer program implemented on a computer including a memory. The method of the invention includes activating a software function and initializing a software function usage meter related to the chosen software function. The software function usage meter is periodically updated while the software function is activated and stopped when the software usage function is deactivated. In a preferred embodiment, the step of initializing the software usage meter includes allocating space for a counter variable in the computer's memory and storing a temporal value in the counter variable. In a more preferred embodiment, the temporal value is the current time. The step of updating the software usage meter preferably includes the steps of determining the elapsed time since a previous update of the software usage meter has been performed; normalizing the elapsed time with respect to a resolution parameter stored in the computer's memory; adding the normalized elapsed time to a current time variable stored in the computer's memory; and storing the updated current time. In a preferred embodiment the steps associated with updating the usage meter are performed in response to messages sent to the software from the event dispatcher of the computer's operating system.

The present invention also includes an apparatus for metering the use of a software function in a computer implemented program stored in a computer memory. The apparatus includes means for activating a software function stored in the computer's memory; means for initializing a software usage meter in response to the activation of the software function; means for updating periodically the software usage meter while the software function is activated; and means for stopping the software usage meter when the software function is deactivated. In a preferred embodiment, the apparatus of the invention further includes means for allocating space in the computer memory for a counter variable and means for storing a temporal value, i.e., a value representative of elapsed time, in the counter variable. In another preferred embodiment, the apparatus includes means for determining the elapsed time since a previous update; means for normalizing the elapsed time with respect to a resolution parameter stored in the memory of the computer to provide a normalized elapsed time; means for adding the normalized lapsed time to a current time variable associated with the software function and stored in the computers memory; and means for storing the updated current time in the computer memory. In still another preferred embodiment, the step of updating is performed in response to messages sent to the computer program from the event dispatcher of the computer's operating system.

In another embodiment the present invention includes a method and apparatus for determining the usage of a group of software functions in the computer program including at least one group of functions. The method includes the steps of determining the function group associated with a activated software function implemented in the computer program using an identifier stored in the computer memory and determining a cumulative usage value for the function group. The cumulative usage value is then compared with a usage limit stored in the computer's memory to determine whether the cumulative usage value exceeds the usage limit. If the cumulative value is greater than the usage limit the activated function is disabled. In a preferred embodiment, the method further includes the step of comparing the cumulative usage value with the threshold value stored in the computers memory to determine whether the cumulative usage value is greater than the threshold value and setting a flag in the computer memory in response to a determination that the cumulative usage value exceeds the threshold value. The present invention also includes an apparatus for metering the use of a group of software functions in the computer program including at least one group of function. The apparatus includes means for determining the function group associated with a activated software function and means for determining a cumulative usage value for the function group. The apparatus further includes means for comparing the cumulative usage value with a stored usage hmit and means for disabling the activated function in response to a determination that the cumulative value exceeds the usage limit. In a preferred embodiment, the apparatus further includes means for comparing the cumulative usage value with a threshold value stored in the computers memory and setting a flag in the computer memory if the cumulative usage value exceeds the threshold value.

In still another aspect, the present invention includes a method for determining the integrity of software for metering the usage of software functions in the computer program implemented on a computer system. The method includes the steps of validating a storage unit residing in the computer memory and determining the integrity of metered associated software components. In a preferred embodiment the step of validating includes the step of determining the status of an absolute header register in a data structure including parameters associated with the software functions and residing in the computer's memory. In addition, the method includes determining the activity status of conditional signatures in the computer program to identify active conditional signatures and determining the validity of the active conditional signatures. In another preferred embodiment, the method of the invention includes performing a checksum analysis of metered software function and validating the length of code resources within the computer program.

In still another aspect, the present invention includes an apparatus for determining the integrity of software for metering the usage of software functions in a computer program implemented on a computer system. The apparatus includes means for validating a storage unit residing in the computer memory and means for determining the integrity of metered associated components. In a preferred embodiment, the apparatus further includes means for determining the status of an absolute header register and a data structure which data structure includes usage parameters associated with the software functions in the computer program. In addition, the apparatus includes means for determining the activity status of conditional signatures in the program to identify active conditional signatures and means for determining the validity of the active conditional signatures. In still another preferred embodiment, the apparatus further includes means for performing a check sum analysis of metered software functions and means for validating the length of code resources in the computer program.

Additional advantages and aspects of the present invention will become apparent when the following description of the preferred embodiment is read in conjunction with the accompanying figures. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates a computer system in accordance with the present invention.

Figure 2 is a computer flow diagram illustrating a method of the invention.

Figure 3 is a computer flow diagram illustrating step 204 of Figure 2.

Figures 4A, 4B and 4C illustrate a data structure in accordance with the present invention. Figure 4A is a global view of the data structure. Figure 4B illustrates one type of record stored in the data structure. Figure 4C illustrates a second type of data record of the data structure.

Figures 5 A and 5B illustrate in greater detail step 304 of the flow diagram illustrated in Figure 3.

Figure 6 is a flow diagram illustrating in greater detail step 306 of Figure 3.

Figure 7 is a flow diagram illustrating step 204 of Figure 2.

Figure 8 is a flow diagram illustrating step 208 of Figure 2 in greater detail.

Figures 9A and 9B illustrate a data structure in accordance with the present invention. Figure 9 A illustrates the data structure in a global view. Figure 9B illustrates a record of the data structure shown in Figure 9A.

Figure 10 is a flow diagram illustrating in greater detail step 210 of Figure 2.

Figure 11 is a computer flow diagram illustrating step 212 of Figure 2 in greater detail.

Figure 12 is a computer flow diagram illustrating step 214 of Figure 2.

Figure 13 is another illustration of the relationship between event dispatcher messages and the steps of the procedure illustrated in Figure 12.

Figure 14 is a computer flow diagram illustrating step 218 of Figure 2.

DESCRIPTION OF SPECIFIC EMBODIMENTS Figure 1 illustrates a typical hardware system configuration in accordance with the present invention at 100. Such a hardware system configuration includes a central processing unit ("CPU") 102 which is coupled unidirectionally with read only memory ("ROM") 104 and bidirectionally with volatile random access memory ("RAM") 106. CPU 102 is further coupled to non-volatile mass storage 108, which mass storage can comprise a magnetic or optical medium such as a hardware disk, floppy disk, or a CD ROM. The CPU is further coupled to an input output device 110 which device typically includes a monitor and/or keyboard and may further include a pointer device such as a mouse. In operation, ROM 104 typically supplies basic operating instructions to the CPU which are necessary for proper CPU function and the operation of software stored in RAM 106 and mass storage 108. RAM 106 holds information which is generally transient in nature, such as programs being run by the CPU and data associated with those programs. Each of these elements is well known to those skilled in the art, as is the combination of the elements to form a computer system.

In preferred embodiments, system 100 further includes a hardware key 112.

Hardware key 112 is a device used to limit access to software running on CPU 102 by providing facilities independent of the software running on the CPU which are used to verify that the software is running under the terms of the software license. Such devices are available commercially as, for example, the Sentinel security system from Rainbow Technologies, Inc. (Irvine Road, CA, USA). Typically, these devices include various memory registers and data which can be accessed by the software to ensure that the software is running under appropriate conditions. The key limits piracy as each user must have a key coupled to the CPU in order to run the software. Such keys are well known in the art and will be familiar to those skilled in the art.

The method of the present invention will now be described with respect to Figure

2 at 200. Beginning at start 202, an initialization session 204 is performed to check the status of various storage units and components, and, optionally, to initialize certain variables before entering into the program's main event loop 206 from which the user may activate various program functions such as tools {e.g., a line tool or a circle tool) and commands {e.g., to perform operations on stored data, such as rendering operations) using such standard operations as keyboard commands and/or slections made from a menu with a mouse or other pointer device. The use of a main event loop in software design is well known to those skilled in the art and is described in, for example, PκGX3RAMMER'sLsrreoDUCTiθNTθ'raEMAcr OSH^® FAMILY (Addison Wesley 1988), TECHNICAL INTRODUCTION TO THE MACINTOSH^® FAMILY, SECOND EDITION (Addison Wesley 1992), and MACINTOSH^® C PROGRAMMING PRIMER VOLS. I AND Π (Addison Wesley 1991), each of which is incorporated herein by reference.

Inside the main event loop 206, the software checks the usage meters at 208 (described below) and then determines if a activated function is a metered function at 210. If the function being used is not a metered function, then flow control returns to main event loop 206 which loop continues until either the user exits from the program or chooses a metered function. If the user activates a metered function, then, at step 212, the meter is initialized and, at step 214, the function is executed. Function execution is allowed to proceed until the user exits the function at which point the meter is stopped at 216. At 218, a determination is made as to whether the user has decided to quit the program. If the user has chosen to quit, then the program control ends at step 220. If the user has not chosen to quit, program flow returns back to main event loop 206 at which point the user can activate another program option.

Initialization step 204 is described in greater detail in a preferred embodiment illustrated in Figure 3 at 300. Beginning at step 302, a storage unit, such as hardware key 112 in Figure 1, is validated. A check of the integrity of metered associated components is next performed at step 306. At step 308, the metered functions of the program are identified. In addition, at step 310, the status flags for these functions are set to "green," i.e., the functions are indicated as being fully available to the user. At step 312, the initialization session ends. In preferred embodiments, initialization session 204 is repeated at a variety of points during the program operation. It will be appreciated by those skilled in the art that such a strategy increases the difficulty for those seeking to avoid the software protection by "hacking" the program code to neutralize the software's anti-piracy protection schemes.

As noted above, the storage unit can be an external hardware key device such as hardware key 112. However, the storage unit may be any type of data storage medium, including, but not limited to, mass storage such as a hard disk, floppy disk, digital audio tape ("DAT'), magneto-optical ("floptical") drives, flash RAM and the like. Preferably, the storage unit will be memory associated with a hardware key when such key is used in conjunction with the present invention. When used in conjunction with a hardware key, the storage unit will preferably include storage unit driver software which manages the interaction of CPU 102 with key 112, and, more specifically, the ingress and egress of data from the storage unit for use by the function usage metering software. Such driver software is well familiar to those of skill in the art.

Figure 4 A at 400 illustrates a preferred data structure of the invention, which data structure preferably resides in the storage unit and holds data relating to the identity of the software, the identity of the metered functions and parameters related to metering those metered functions including registers for metering data. The data structure includes a header 402, which header includes such information as the application identifier and the application licensed category information, a feature look up table 404 and time data record 406. It will be appreciated by those skilled in the art that the header may contain additional or different information relating to the software's identity and/or validity.

The structure of data record 404 is illustrated in greater detail in Figure 4B. Function data record 404 contains four elements including Function ID 408, a pointer to an associated time data record 410, data resolution parameter 412, and, optionally, a threshold value (not shown). Function ID 408 is a an identifier for each of the functions available in the software, and preferably is a numerical identifier. The function ID is an index used throughout the various data structures accessed by the program relating to information for each of the program functions. Importantly, those functions which are to be metered are identified through their respective Function IDs. However, it will be appreciated that any function property can be related to its Function's ID. Pointer 410 identifies which of the time record 406 is assigned to the function identified by Function ID 408. Resolution value 412 is a parameter indicating the time scale at which the particular function operates. For example, use of the function identified by the Function ID may be charged in term of seconds, minutes, hours, or even days. Preferably, the resolution is provided in terms of seconds or minutes. However, those skilled in the art will appreciate that the time scale may vary between functions and may include such arbitrary measures as fractions of seconds where such a time scale would be appropriate for the function being used {e.g., 1/16 of a second for Macintosh^® systems). Preferably, resolution value 412 will reflect the platform in which the software is operating. The optional a threshold value can be used to identify the amount of time available for a particular software feature after which time the feature becomes disabled.

Time records 406 are illustrated in greater detail at Figure 4C. The time records preferably include of two values: an Original Count 414 and a Current Value 416. Original Count 414 holds a value indicating the total amount of time available to the user, in units that are appropriate for the resolution value associated with the Function ID. Again, this amount may vary between functions and can be set in the software by the software publisher. Current Value 416 will hold different quantities depending on the method used to measure function use. For example, Current Value 416 will hold the amount of time that has elapsed in those embodiments in which an "up counter" is being applied by the software. Conversely, Current Value 416 will hold the amount of time remaining to the user if the software is employing a "down counter." Records 406 may optionally include additional validation data such as validation codes and version identifiers (not shown).

Referring now to Figure 5A, the sequence of operations associated with validate storage unit step 304 of Figure 3 will be described. Starting at step 502, the absolute signatures in the header registers are checked at step 504. As used herein, the term "absolute signature" refers to signatures (i.e., system or software values) that are always checked by the software. These values can be stored data or they can be values calculated using various methods of determining system and or software integrity as is known in the art (e.g., checksums). Step 504 is used to determine the authenticity of the internal values in the storage unit. For example, a random or quasi-random check is made on the identifiers within various registers of the storage unit to check for inconsistencies. The checks may also be made with respect to header 402 to ensure that the values therein are consistent. These checks may be made over one, some, or all of the records available in header 400. Preferably, the records are checked in a random or quasi-random fashion, again, to frustrate potential tampering with the software code. The implementation of random and/or quasi-random checking methods will be familiar to those of skill in the art. It will be appreciated by those skilled in the art that these methods may be implemented using standard techniques, the details of which will vary depending on the implementation being used, i.e., whether the implementation is being made through software, hardware, or a combination of software and hardware

At step 506, a determination is made as to whether the values in the registers checked in step 504 are consistent, or sufficiently consistent, to allow program execution to continue. If the registers are not determined to be sufficiently consistent with expected parameters, then program operation ceases at step 508. At this point, the user may or may not be warned that a problem has occurred. If, however, the registers are determined to be in proper condition, then, at step 510, a determination is made as to which conditional signatures are active. Conditional signatures are understood herein to include signatures as defined above with respect to active signatures, but which signatures are not always checked by software. Rather, conditional signatures are checked only upon the occurrence of some event or at certain time intervals. For example, a signature may be checked only in response to the first activation of a software function, e.g., a zoom operation, or after a certain time interval, e.g., every two weeks. At step 512, those conditional signatures determined to be active in step 510 are checked. At step 514, shown in Figure 5B, a determination is made as to whether the signatures are in proper condition. If the signatures are in proper condition, then a step 516, the records are checked for consistency, i.e., records are checked in a random or quasi-random fashion to determine whether their contents fall within expected limits. For example, the original and current values stored in record 406 may be checked to determine whether the current value is greater than the original value. If the records are sufficiently consistent, then program control is returned to step 306 at 522. If either the records or the signatures are determined not to be in proper condition, then an error is returned to the user in step 520, such as a warning message that data in the program may have been corrupted and the routine concludes at step 522.

Step 306 of sequence 300 is described in greater detail at 600 in Figure 6. There, following start 306, a checksum of the metered software components is performed at step 604. It will be appreciated that checksum routines are well known to those skilled in the art and will not be discussed in greater detail here {see, e.g., ENCYCLOPEDIA OF COMPUTER SCIENCE, 3^RD ED., (Van Norstrand Rheinhold 1993)). Briefly, the checksum performed at step 604 includes performing various calculations on the actual number of program steps within specified segments of the program code to determine whether changes have been made to the program, such as patches which have been inserted into the computer code by those seeking to override limitations imposed on software usage. Generally, one or more calculations are performed on the numbers of steps within designated segments to derive values which can be correlated with changes that have been made to the code. If the change is noticed, then it can be assumed that the program has been modified. In addition, the checks may include the step of simply checking the length of one or more code segments to determine whether or not additional code has been inserted, such as code inserted by a computer virus. Preferably, the metered software components to be checked include (1) the storage unit, (2) the storage unit driver software, (3) the program code associated with the initialization session, and (4) the code associated with various metering functions.

If the checksum is consistent, then the lengths of various code resources is checked in step 608. These code resources preferably include the storage unit driver, the code associated with the initialization session and the code associated with the software usage meters. At step 610, a determination is made as to whether the lengths of the code resources are within acceptable values. If they are, then the program sequence terminates at step 612. If either step 606 or step 610 determines that the check sum or the resources are outside of program specifications, then sequence 600 immediately terminates at step 612. Such length checking will be familiar to those of skill in the art.

Having performed the preferred initialization checks on the system, the main event loop of the program is begun as described previously with respect to step 206 of Figure 2. Main event loops are well known to those of skill in the art, especially with respect to menu driven program such as those found on Macintosh^® and Windows computers. Briefly, the main event loop cycles until a request is made of the operating system. That request may include background activities, i.e., operations performed by software other than the software being metered, or it may include a choice of a function from the metered software itself.

When a function is activated, a determination is made as to whether the function is a metered function. If a metered function is activated, as described at step 212 in Figure 2, the sequence shown at 700 in Figure 7 is initiated. Following start step 702, data records 404 are preferably copied into the RAM, such as shown at 106 in Figure 1, with preferably some additional memory space reserved to be used as a scratch space by the program. This provides quick access to the pointers for each function so that the current value available for each metered feature can be incremented or decremented depending on the particular embodiment implemented. However, it will be appreciated that the records can be accessed without being copied into RAM.

It will be further appreciated that the activation of a function can be generalized to include the activation of a program whose usage is monitored by the software of the present invention. However, as used herein, the phrase "software function in a computer program" will be used to indicate that the activated function is a component of a computer program {e.g., a line tool, a box tool, a view, a process or the like). Thus, the metering of a software function in a computer program will therefore be understood to describe the metering of the use of a function resident within a program {i.e., the use of the line tool, box tool, view, process or the like) and not the program itself.

The check meter step of 206 of Figure 1 is now described in greater detail at 800 in Figure 8. Starting at step 802, a loop is entered at 804 for each metered Function Group (i). The function groups comprise related function, e.g., all three-dimensional drawing tools, and are identified by reference to a look-up table ("LUT") that preferably includes the Function ID, Function Name, Group ID and a Threshold value (as described above with respect to data record 404). Other referencing schemes will be apparent to those of skill in the art. For each Function Group (i), at step 806 a cumulative usage value is calculated. At step 808, a determination is made as to whether the usage of the i* group is greater than a preset upper limit.

If the usage is greater than the limit, then, at step 810, the function is disabled and a flag, referred to herein as a red flag, is set in the feature status table (described below with respect to Figure 9) indicating that the function is no longer available. If the i* group usage value is equal to or less than the upper limit, then a determination is made at step 812 as to whether the i* group usage value is greater than the threshold value. If the usage value is greater than the threshold, a warning is flagged in the status table and control returns back to the loop 804. If the i* group usage value is less than the threshold, control returns to loop step 804. Typically, the threshold is defined as a fraction of the upper limit, e.g., 10% of the upper limit. Thus, when the usage of the i* group is within 10% of the upper limit, an internal flag is set and a warning is sent to the user. Upon completion of loop 804 for all groups, the available values are displayed for all groups at step 816 and the sequence terminates at step 818.

The feature status table referred to in step 810 is described in greater detail in Figures 9 A and 9B. Starting with Figure 9 A at 900, the overall structure of the table is presented. The table includes header 902 which denotes the number of entries in table 900. Following header 902 are records 904 which are described in greater detail with respect to Figure 9B. Turning now to Figure 9B, a typical data record 904 is shown. The record includes the Function ID 906, the pointer to the data in the storage unit at 908, an internal counter 910, a meter running flag 912, a feature disabled flag 914, and a feature low flag 916. With reference back to Figure 8, it will be appreciated that if the deteπnination made at step 808 is true, then at step 810, the red flag is set in the feature disabled register 914. Similarly, if at step 812, the usage value was determined to be greater than the threshold value, the warning flag is set in feature low register 916.

Once the meters have been checked as just described, control moves to step 210 of Figure 2, which is illustrated in greater detail at 1000 in Figure 10. Beginning at start 1002, the Feature ID is determined from the stored look up table at 1004 and a determination is made as to whether the metering flag on the function has been set in step 206. If the function is not a metered function, then, at step 1008, the function is executed, and, upon completion of the function, the sequence is terminated at step 1010. If the function is metered, then, at step 1012, the enable flag is retrieved, and, at step 1014, a determination is made as to whether the enable flag has been set. If the enable flag has not been set, then, at step 1016, the user is presented with a warning and the routine terminates at step 1010. If the function is enabled, the sequence terminates at step 1010.

When a function is determined to be no longer enabled, requests made to the software to activate that function are rejected, and appropriate steps are taken to indicate the deactivated status of the function in the user interface. For example, text associated with any menu option(s) for the disabled function may be "grayed-out", or buttons or other screen controls associated with the function may be crossed-out or grayed out. Other methods for indicating the deactivated status of a disable function will be apparent to those of skill in the art. Prior to the deactivation, the user will preferably have been warned, e.g., at step 814, that the use of the function will soon expire.

It will be appreciated that the determination of which features are metered and which feature are not metered will depend on a variety of factors, including, but not limited to, the type of software being metered and the marketing considerations associated with that software. Preferably, metered features are easily communicable to the user and are representative of the added value of the software. Thus, for example, for 3D modeling software, such as ArchiCAD^®, preferred metered functions include: 3D viewing and modeling, bill of materials, printing plotting and modification tools. It will be further appreciated that these, and other, metered features can be "grouped" into packages to take advantage of different marketing strategies, so that different combinations of features are metered depending on the market being addressed.

Step 212, in which the meter is initialized, is described in greater detail in Figure 11 at 1100. Beginning at 1102, memory allocation for the counter is made in RAM at step 1104 followed by step 1106 in which the flag is set indicating that the function activated is operating. At step 1108, the value for the creation date and time is retrieved and stored in the counter. The sequence then concludes at step 1110. With respect to step 1104, the memory allocation performed is simply a reservation of space in RAM 106 which holds a value representing either the date and the time as retrieved from the system, or the time only. For example, in a Macintosh^® operating system, the number of seconds from the date January 1, 1904, can be stored to represent the creation time. It will be appreciated that other units of counting may be employed. These are stored in the internal feature counter register 910 shown in Figure 9B. Figure 12 illustrates the sequence of operations used to increment the usage time for metered function at sequence 1200. In preferred embodiments, sequence 1200 is performed in response to messages received from the system during through an event dispatcher during "user breaks" which are performed during the execution of the metered function at step 214 in Figure 2. User breaks are well known to those of skilled in the art in the programming of co¬ operative multitasking systems such as the Macintosh^® operating system and Windows. Briefly, user breaks are break points set into the code by the programmer during which break points messages from the system are received by the software, and acted upon if necessary, and various system housekeeping functions are performed. For example, during user breaks messages may be received from programs operating in the background {e.g., electronic mail warnings), the status of various system parameters are updated, and the like. Those of skill in the art will appreciate that the present invention can be adapted to "true" (i.e., pre-emptive) multitasking systems using the principles described herein. However, in pre-emptive multitasking systems, the time will be determined by making appropriate calls to the system's process manager.

Beginning at step 1202, the current time is retrieved from the system clock at 1204 and, at 1206, a determination is made as to whether an unconditional update storage is to be performed. The storage is unconditionally updated in response to "suspend event" messages received from the system, i.e., messages from the event dispatcher of the system that another process is being allowed to run in preference to the metered function. By "unconditionally updated" or "unconditional update" it is meant herein that the storage is updated regardless of whether a storage update would be performed in the absence of a "suspend event" message as described below. Following completion of the higher priority operations, a "resume event" is sent by the event dispatcher to signal that the function now has regained control of the processor. If an unconditional storage update is determined to occur, then the process moves to step 1214 which step is described below.

If the unconditional update storage is not to be performed {i.e., if a message other than a "suspend event" or a "resume event" is received from the event dispatcher) then a determination is made as to whether a conditional storage update is required, as shown in the dashed box 1207. To determine whether a conditional storage update is to be performed, at step 1208 the elapsed time is compared with the storage unit update frequency parameter, which parameter indicates how frequently the elapsed time is to be recorded in the storage unit. At step 1210, if the elapse time is less than the storage unit update frequency parameter, then the sequence ends at step 1212, i.e., a conditional storage update does not occur. On the other hand, if the elapsed time greater than or equal to the storage unit update frequency parameter, i.e., a conditional storage update is determined to occur, then, a storage update ensues beginning with step 1214. At step 1214, the elapsed time since the previous update is determined, followed at step 1216 by the addition of the elapsed time to the current time which current time is then written to the storage unit. At step 1218, the internal feature counter is updated to reflect the current time and an optional step 1220 may be performed in which the current values are updated or checked and the status flag is updated. In addition, step 1218 is also preferably performed in response to a "resume event" message in which control is returned to the metered function after processing of the metered function has been halted in response to a "suspend event" message.

The relationship between the different messages sent from the event handler and the operations in sequence 1200 are illustrated in more detail at 1300 in Figure 13. As described above, "suspend events" trigger an unconditional storage update (step 1202); resume events trigger the update of the internal feature counter (step 1218) and further execution of sequence 1200. Any other event triggers a conditional update (1207).

It will be appreciated that the above-described unconditional storage update allows the suspension of the metering function of the present invention during the operation of higher priority processes. Thus, when the system receives a "suspend event" message, the current amount of usage is determined and recorded as described above with respect to steps 1214 and 1216. Upon receipt of a "resume event" message, the internal feature counter is updated to the current time so that metering of the actual usage of the software or software function can continue. During the hiatus, however, no metering is performed. By allowing for such suspensions of the metering operation in response to changes in processing priority, the user is not charged while processes other than metered processes are operating.

It will be further appreciated that in other embodiments the parameters of the metering system of the invention may be modified in response to messages received from the operating system in lieu of, or in addition to, the above-described conditional and unconditional storage updates. For example, usage metering may not be suspended in response to a suspend event message, but can be performed at a different rate, which rate can also be a function of the function being metered. Also, the metering rate may change for conditional storage updates in response to the specific message received from the operating system.

Following the execution of the metered function as described in Figure 2 at step

214 and the cessation of metering in step 216, a determination is made as to whether the user has quit the program. If the user does activate to exit the program, then as shown in Figure 14 in sequence 1400, several housekeeping chores are performed. Beginning at step 1402, a unconditional updating of the storage is performed at step 1404, which unconditional update storage step follows the sequence described above in Figure 12 with respect to steps 1214 through optional steps 1220. Following the update of the storage at step 1406. the internal counter space is freed for later use and in step 1408, the sequence 1400 terminates, and control is returned to the main event loop at step 206 in Figure 2.

Thus, it will be appreciated from the foregoing that when a user initiates a session using software constructed in accordance with the present invention a series of initialization steps arc first performed to ensure that the user is indeed a valid user and that the integrity of the software remains intact. Following the initialization, the user is present with the interface associated with the main event loop, during which time the system periodically checks the software usage meters for updating. If the user activates a function which is metered, then the software initializes the meter and periodically updates the meter until the function is deactivated, at which time the meter stops. If the user activates another function, the above- described steps are repeated; if the user quits the program, program execution is terminated as usual.

In another preferred embodiment, the information hardware key 112 of Figure 1 is periodically returned to the software publisher for calculation of the usage fees and, optionally, determination of usage patterns of the software. Thus, the data stored in hardware key 112 is retrieved and analyzed, preferably by software means, during which time the usage of the functions is determined and a fee calculated. The various memory registers of the key are then cleared to indicate that no time has elapsed on the metered functions and various housekeeping operations may be performed, e.g., re-initialization of various identifiers and usage values and thresholds for use by the same of another user at a later time. Following calculation of the fees, the user is presented with a bill for the usage to be charged.

Thus, it will be seen that the present invention provides a flexible method for charging users for access to software. Using the method and apparatus of the invention, software may be distributed more widely to users who wish to take advantage of certain features and thereby avoid the high cost of buying expensive software packages while availing themselves of the advantages of those packages. It will be further appreciated that such a marketing technique may further include the advantage of encouraging users to buy full packages by allowing them to perform tasks using the software without the limitations commonly imposed by demonstration of versions of the software and yet providing appropriate compensation to the software publisher for the efforts in providing the software.

Although certain embodiments in the examples have been used to describe the present invention, it will be apparent to those of skilled in the art that changes may be made to those embodiments and/or examples without departing from the scope or spirit of the invention.

Claims

WHAT IS CLAIMED:

1. A method for metering the use of a software function in a computer program implemented on a computer including a memory, comprising the steps of:

a) activating said software function;

b) initializing a software function usage meter in response to said activation of said software function;

c) updating periodically said software function usage meter while said software function is activated; and

d) stopping said software function usage meter when said software function is deactivated.

2. The method of claim 1 , wherein said step of initializing said software usage meter comprises the steps of:

a) allocating space for a counter variable in said computer memory; and

b) storing a temporal value in said counter variable in said computer memory.

3. The method of claim 2, wherein said temporal value is the current time.

4. The method of claim 1 , wherein said step of updating comprises the steps of:

a) deterπύning the elapsed time since a previous update of said software function usage;

b) normalizing said elapsed time to a resolution parameter associated with said software function to provide thereby a normalized elapsed time;

c) adding said normalized elapsed time to a current time variable associated with said software function to provide an updated current time; and

d) storing said updated current time in said computer memory.

5. The method of claim 4, further including the step of updating an internal feature counter associated with said software function, said internal feature counter being located in said computer memory.

6. The method of claim 4, wherein said previous update is the immediately preceding update.

7. The method of claim 4, further including the steps of:

a) determining whether to perform a conditional storage update prior to said step of determining the elapsed time; and

b) executing said step of determining the elapsed time in response to a determination that a conditional update is required.

8. The method of claim 7, wherein said conditional update is performed in response to a message from the event dispatcher of the operating system of said computer other than a suspend event message or a receive event message.

9. The method of claim 7, wherein said step of determining whether to perform a conditional update comprises the step of comparing said elapsed time with a storage unit update frequency parameter stored in said computer memory.

10. The method of claim 9, further including the step of determining whether said elapsed time is greater than said storage unit update frequency parameter.

11. The method of claim 4, further including the steps of:

a) deteιτnining whether to perform an unconditional storage update prior to said step of determining the elapsed time; and

b) executing said step of deteirnining said elapsed time in response to a determination that an unconditional update is required.

12. The method of claim 11, wherein said unconditional update is performed in response to a suspend event message from the event dispatcher of said operating system.

13. The method of claim 12, further including the step of updating an internal feature counter associated with said software function in response to a resume event message from said event dispatcher.

14. The method of claim 1 , further including the step of determining whether said software function is a metered software function prior to said step of initializing said software usage meter.

15. The method of claim 14, wherein said step of determining whether said software function is a metered software function includes the steps of:

a) retrieving a function identifier from said computer memory; b) determining whether said function identifier indicates that said software function is to be metered;

c) executing said software function in response to a determination that said software function is not to be metered; and

d) examining the status of an enable flag stored in said computer memory to thereby determine if said software function is enabled.

16. The method of claim 15, further including the step of providing a warning in response to a determination that said software function is not enabled.

17. An apparatus for metering the use of a software function in a computer implemented program stored in a computer memory, comprising:

a) means for activating a software function stored in said computer memory coupled to

b) means for initializing a software function usage meter in said computer memory in response to said activation of said software function coupled to

c) means for updating periodically said software function usage meter while said software function is activated coupled to

d) means for stopping said software function usage meter when said software function is deactivated.

18. The apparatus of claim 16, wherein said step of initializing said software usage meter comprises:

a) means for allocating space in said computer memory for a counter variable coupled to

b) means for storing a temporal value in said counter variable in said computer memory.

19. The apparatus of claim 17, wherein said means for updating comprises:

a) means for determining the elapsed time since a previous update coupled to

b) means for normalizing said elapsed time to a resolution parameter associated with said software function, said resolution parameter being stored in said memory, to provide a normalized elapsed time coupled to c) means for adding said normalized elapsed time to a current time variable associated with said software function, said current time variable being stored in said memory, to provide an updated current time; and

d) means for storing said updated current time in said computer memory.

20. The apparatus of claim 19, further including means for updating an internal feature counter associated with said software function, said internal feature counter being located in said computer memory.

21. The apparatus of claim 20, further including means for performing an unconditional storage update in response to a suspend event message from the event dispatcher of the operating system of said computer.

22. The apparatus of claim 21 , further including means for performing said updating in response to a resume event message from said event dispatcher.

23. The apparatus of claim 21 , further including means for performing a conditional storage update in response to a message from said event dispatcher other than a suspend event or resume event message.

24. The apparatus of claim 19, further including means for determining whether said software function is a metered software function prior to said step of initializing said software usage meter.

25. The apparatus of claim 24, wherein said means for determining whether said software function is a metered software function includes:

a) means for retrieving a function identifier stored in said computer memory coupled to

b) means for determining whether said function identifier indicates that said software function is to be metered coupled to

c) means for executing said software function in response to a determination that said software function is not to be metered coupled to

d) means for determining the status of an enable flag if said software function is to be metered.

26. The apparatus of claim 25, further including means for providing a warning in response to a determination that said enable flag is false.

27. A method for determining the usage of a group of software functions in a computer program including at least one group of functions, said computer program being implemented on a computer system including a computer memory, said method comprising the steps of:

a) determining the function group associated with a activated software function implemented in said computer program from a function group identifier stored in said computer memory;

b) determining the cumulative usage value for said function group;

c) comparing said cumulative usage value with a usage limit associated with said function group, said usage limit being stored in said memory, to determine whether said cumulative usage value is greater than said usage limit; and

d) disabling said activated function in response to a determination that said cumulative usage value exceeds said usage limit.

28. The method of claim 27, further comprising the steps of:

a) comparing said cumulative usage value with a threshold associated with said function group, said threshold being stored in said memory, to determine whether said cumulative usage value is greater than said threshold; and

b) setting a flag in said computer memory in response to determination that said cumulative usage value exceeds said threshold.

29. The method of claim 28, further comprising the step of indicating the availability of the groups of functions in said computer program.

30. An apparatus for metering the usage of a group of software functions in a computer program including at least one group of functions, said computer program being implemented on a computer system including a computer memory, comprising:

a) means for determining the function group associated with a activated software function implemented in said computer program from a function group identifier stored in said computer memory coupled to

b) means for determining the cumulative usage value for said function group coupled to

c) means for comparing said cumulative usage value with a usage limit associated with said function group, said usage limit being stored in said memory, to determine whether said cumulative usage value is greater than said usage limit coupled to

d) means for disabling said activated function in response to a determination that said cumulative usage value exceeds said usage limit.

31. The apparatus of claim 30, further comprising:

a) means for comparing said cumulative usage value with a threshold associated with said function group, said threshold being stored in said memory, to determine whether said cumulative usage value is greater than said threshold coupled to

b) means for setting a flag in said computer memory in response to determination that said cumulative usage value exceeds said threshold.

32. The apparatus of claim 31 , further comprising means for indicating the availability of the groups of functions in said computer program.

33. A method for determining the integrity of software for metering the usage of software functions in a computer program implemented on a computer system in a computer memory, comprising the steps of:

a) validating a storage unit; and

b) determining the integrity of metered associated components.

34. The method of claim 33, further comprising the steps of identifying metered functions and initializing indicators stored in said computer memory.

35. The method of claim 33, wherein said step of validating comprises the steps of:

a) determining the status of absolute header registers in a data structure including usage parameters associated with said software functions, said data structure being stored in said memory;

b) determining the activity status of conditional signatures in said computer program to identify active conditional signatures; and

c) determining the validity of said active conditional signatures.

36. The method of claim 35, further comprising the step of determining the validity of data records associated with said computer program, said data records being stored in said computer memory.

37. The method of claim 33, wherein said step of determining the integrity of metered associated components comprises the steps of:

b) performing a checksum analysis of metered software functions; and

c) validating the length of code resources in said computer program.

38. An apparatus for determining the integrity of software for metering the usage of software functions in a computer program implemented on a computer system in a computer memory, comprising:

a) means for validating a storage unit coupled to

b) means for determining the integrity of metered associated components.

39. The apparatus of claim 38, further comprising means for identifying metered functions and initializing indicators stored in said computer memory.

40. The apparatus of claim 38, wherein said step of validating comprises the steps of:

a) means for determining the status of absolute header registers in a data structure including usage parameters associated with said software functions, said data structure being stored in said memory coupled to

b) means for determining the activity status of conditional signatures in said computer program to identify active conditional signatures coupled to

c) means for determining the validity of said active conditional signatures.

41. The apparatus of claim 40, further comprising means for determining the validity of data records associated with said computer program, said data records being stored in said computer memory.

42. The apparatus of claim 38, wherein said means for determining the integrity of metered associated components comprises:

a) means for determining the status of absolute header registers in a data structure including usage parameters associated with said software functions, said data structure being stored in said memory coupled to b) means for performing a checksum analysis of metered software functions coupled to

c) means for validating the length of code resources in said computer program.

43. A method for metering the use of software implemented on a computer including an operating system, comprising the steps of:

a) initializing a software usage meter; and

b) updating of said software usage meter in response to one or more messages received from said operating system.

44. The method of claim 43, wherein said step of updating comprises the steps of:

a) determining the elapsed time since a previous update of said software function usage;

d) storing said updated current time in said computer memory.

45. The method of claim 43 further including the steps of suspending and resuming said updating of said software usage meter in response to one or more messages received from said operating system.

46. The method of claim 45, further including the step of updating an internal feature counter associated with said software function, said internal feature counter being located in said computer memory.

47. The method of claim 46, wherein said previous update is the immediately preceding update.

48. The method of claim 45, wherein said messages are sent from the event dispatcher of said operating system.

49. The method of claim 48, wherein said step of suspending said updating comprises an unconditional update performed in response to a suspend event message from the event dispatcher of said operating system.

50. The method of claim 49, wherein said step of resuming comprises updating an internal feature counter associated with said software function in response to a resume event message from said event dispatcher.

51. The method of claim 43, wherein said step of updating comprises the step of determining whether to perform a conditional update in response to a message sent from the event manager of said operating system other than a suspend event or resume event.

52. The method of claim 48, wherein said step of updating comprises determining whether to perform a conditional update by comparing said elapsed time with a storage unit update frequency parameter.

53. An apparatus for metering the use of software implemented on a computer including an operating system, comprising:

a) means for initializing a software usage meter coupled to

b) means for updating of said software usage meter in response to one or more messages received from said operating system.

54. The apparatus of claim 53, wherein said means for updating comprises:

a) means for determining the elapsed time since a previous update of said software function usage coupled to

b) means for normalizing said elapsed time to a resolution parameter associated with said software function to provide thereby a normalized elapsed time coupled to

c) means for adding said normalized elapsed time to a current time variable associated with said software function to provide an updated current time coupled to

d) means for storing said updated current time in said computer memory.

55. The apparatus of claim 53 further including means for suspending and resuming said updating of said software usage meter in response to one or more messages received from the event dispatcher of said operating system.

56. The apparatus of claim 55, wherein said step of updating comprises the step of determining whether to perform a conditional update in response to a message sent from the event manager of said operating system other than a suspend event or resume event.