NZ515938A

Monitoring usage of software by supervising program checking tags associated with the software

Abstract

A system for supervising usage of software where a tag is uniquely associated with a particular instance of software comprises: a software vendor component producing identical instances of software; a tag server producing a plurality of tags, one tag per instance of software, each tag uniquely identifying an instance of software with which it is associated; and a user device receiving and installing an instance of software and securely receiving the separate tag, the tag being unrelated to the user device, the user device including a supervising program which detects attempts to use the instance of software and which searches for and verifies the authenticity of the separate tag associated with the instance of software before allowing use of the instance of software. The tag is a unique collection of information concerning the instance of software with which the tag is associated and including at least one of the name of the software, a unique number of the instance of software and a hash function value on portions of content of the software. Each tag uniquely identifies the particular instance of software that it is associated. The software vendor component comprises a software production mechanism creating instances of software each having at least one of a name and software content; each instance of software being usable only after verifying a authenticity of a tag that is unique to and separate from that instance of software. The tag server accepts a copy of specific vendor software and produces a plurality of tags, one tag per instance of the software. The user device comprises an input port receiving an instance of software, receiving a tag uniquely associated with and separate from the instance software and receiving a request to use the instance of software and a processor executing a supervising program which detects the request to use the instance of software and verifies the authenticity of the tag associated with the instance of software before allowing use of the instance of software by the user device.

NZ515938A, drawing sheet 1
Sheet 1 of 19

Term

Term ended

Projected expiry passed 2 May 2020, 6.4 years ago.

  1. Priority
  2. Filed
  3. Published
  4. Projected expiry
  5. Today

2 claims: 1 independent, 1 dependent

  1. 1
    Other embodiments of the invention include a computer readable medium encoded with instructions for the above processes, as well as a propagated signal transmitted via a carrier over a medium which carries an encoded tag table data 10 structure as described above. Using these mechanisms, the system of the invention allows a rightful vendor/owner of the rights in an instance of software to police those rights. If the vendor discovers that the vendor rights are being infringed, such as by discovering a bootleg, stolen, reverse engineered, modified or disassembled instance of software 15 which essentially identical in operation to the vendor produced software, the system can police the use of these illegal copies of software. The system of the invention at the same time protects a rightful user of software from denial of service by dishonest parties who attempt to create a false impression of illegal use of software by the rightful user/owner. 20 The invention also allows pay-per-use statistics to be tracked at each user device for software which is purchased on a per use basis. During the call-up procedure, the guardian center can determine the use statistics for a pay-per-use instances of software and can provide the use information back to the software vendor for billing purposes. 25 As indicated above, the system includes a guardian center that includes a tagged software database and a verification program. Every user device must periodically communicate with the guardian center via a call-up procedure and securely send, for each instance of vendor software installed on that user device, or used on the device since the last preceding call-up procedure, the tag associated with 30 that instance. Additional data from the tag table, up to and including the complete tag table, may also be securely sent by the supervising program to the guardian WO 00/72119 PCT/USOO/11821 -30center during a call-up procedure. The call-up procedure may be initiated by either the guardian center or the user device. The guardian center's verification program authenticates each tag it received from the user device. Essentially, the verification program examines each tag and its associated 5 data received from the user device against the tagged software database to authenticate it and to ensure that the tag is in compliance with at least one usage supervision policy applying to the software instance with which the tag is associated. For example, the verification program may check whether a tag received during a call-up was, at any time since the previous call-up from the same 10 supervising program, in usable status in the calling device's tag table and, simultaneously, in usable status in some other device's tag table, such an occurrence being a violation of a possible usage supervision policy. The verification program securely returns a continuation message to the user device and updates the tagged software database, using the tags and the associated information it has received 15 during the call-up procedure. When creating an unsigned tag for an instance of software, the tag server securely sends the tag to the guardian center and the guardian center's verification program stores the received tag in the tagged software database. In another implementation, the tag server sends all newly created tags to the 20 guardian center and the guardian center's verification program stores each received tag in the tagged software database. When the guardian center receives a tag from a user device during a call-up procedure, the guardian center's verification program authenticates the tag by searching for it in the guardian center’s tagged software data base and, if not found there, declaring it as not authentic if said tag is an unsigned 25 tag. If said tag is a signed tag then the verification program authenticates the tag by either finding it in the tagged software database or by verifying that said tag has the correct form and further verifying the digital signature included in the tag. The guardian center's continuation message to a user's device is signed by the guardian center and includes identifying data such as a time-stamp, a hash function 30 value of the tag table or of other data it has received from the user device's supervising program during the current call-up. In addition, the continuation WO 00/72119 PCT/US00/11821 -31message contains commands, hereinafter called actions, to the supervising program in the user device. Examples of actions used by the invention include but are not limited to:Instructing the supervising program to (1) allow continued use of a particular 5 instance of software;or (2) to refuse use of a software instance for a specified time period;or (3) to refuse to install or allow use of software having a given name or a given list of fingerprints for a specified period of time;or (4) to disable the user device for a specified period of time. Actions of types 2 - 4 are sometimes called punitive actions. 10 Upon receiving, during the call-up procedure, the continuation message from the guardian center, the user device's supervising program checks the guardian center's digital signature. The supervising program further checks whether the continuation message is for the current call-up of this device by comparing hash function values or other data present in the continuation message, with hash function 15 values of portions of the device's tag table or with the hash function value of the tag table or with other data present in the tag table. If the above signature is verified as being authentic and the above comparisons produce matches, the supervising program accepts the continuation message as being the guardian center's response in the current call-up procedure. In 20 this case the supervising program stores the continuation message in the tag table and proceeds to update the status of tags and execute actions according to the actions and punitive actions present in said continuation message. A usage supervision policy can be associated with an individual tagged instance of software, or with a specific software or type of software, or with the 25 entire user device with which the guardian center communicates, or with an individual user of the user device with which the guardian center communicates. Examples of usage supervision policies defined by a vendor of instances of software include but are not limited to the following and any combination thereof. That an instance of software once used on one user device will not be used on a 30 different user device. That an instance of software not be used or be in usable status simultaneously on two different user devices. That an instance of software be used WO 00/72119 PCT/USOO/11821 -32or be in usable status simultaneously only on user devices within a specified set of devices. That an instance of software be used for no more than a specified number of times. That an instance of software not be used after a specified date. That use of an instance of software be allowed only if pay-per-use fees for that instance were 5 transferred to a specified account. The methods and apparatus of the invention make it possible to enforce any usage supervision policy defined by a vendor or consortium of vendors with respect to use of an instance or a class of instances of software. The guardian center maintains a tag data structure in the tagged software 10 database for each individual tag associated with some instance of software on some user device. The tag data structure for a tag is associated with the tag itself and not with any particular user device from which that tag was transmitted to the guardian center during some call-up procedure. Each tag data structure comprises the tag of an instance of software, the name of the software of which the instance is a copy, the 15 instance number of the instance of software, a hash function value of the instance of software or of portions of that instance, a usage supervision policy associated with the instance of software, and a collection of references to call-up records, or a collection of call-up records, associated with the instance of software. Each call-up record in the said collection of call-up records represents information concerning 20 one call-up procedure and may include a call-up time, a header of a tag table or some other identifying information transferred to the guardian center during the call-up procedure, the last call-up time indicating a time stamp of a former call-up procedure, a hash function value of the tag table transferred to the guardian center during the call-up procedure, and the continuation message sent to the user device's 25 supervising program during the call-up procedure. Using data gathered and stored during call-up procedures, the guardian center can compile usage statistics for each instance of software, for such purposes as billing for paying per-use for a software instance. An untagged instance of software may be installed or used on the user 30 device. The supervising program detects that the instance is untagged and computes ' fingerprints of selected portions of the untagged instance of software and stores WO 00/72119 PCT/USOO/11821 -33these fingerprints in a fingerprint table on the user device. The guardian center, according to this aspect, includes a fingerprint data structure. During the above mentioned call-up procedure with a user device, the guardian center receives all fingerprints from the user device for each untagged instance of software installed on 5 the user device. The verification program compares each fingerprint received from the user device against the fingerprints in its fingerprint data structure to determine if an untagged instance of software used on a user device is an infringing instance of software. In this manner, the invention can detect the use of a software instance that is a pirated copy of vendor software whose tag has been removed, or a pirated 10 derivative of vendor software. If the verification program detects a match between more than a specified number of fingerprints in the guardian center's fingeiprint data structure and the fingerprints received from the user device, the verification program can specify a punitive action or actions in the continuation message returned to the user device. 15 According to one such punitive action, a user device can be disabled for a specified period of time, if detected by the guardian center as using untagged infringing software. In another example, a punitive action may specify that the untagged instance of software associated with a fingerprint that was matched to a fingerprint in the 20 guardian center's fingerprint data structure, should be disabled. The fingerprint data structure at the guardian center is constructed by having software vendors who detect that infringing software is being distributed or used as untagged software, send a copy of such untagged infringing software to the guardian center. The guardian center computes fingerprints of portions of this copy of the 25 infringing software and incorporates and stores these fingerprints in the fingerprint data structure. Protection against infringement of vendor’s rights in software is also provided by fingerprinting selected portions of any instance of software, tagged or untagged, used on a user device and storing these fingerprints in the device's 30 fingerprint table. As before, the fingerprints in the fingerprint table are sent by the device’s supervising program to the guardian center during execution of a call-up WO 00/72119 PCT/USOO/11821 -34procedure and the guardian center's verification program searches for matches between the received fingerprints and fingerprints in the guardian center's fingerprint data structure. This aspect of the invention protects against infringement on a legitimate vendor's rights by a pirating vendor who makes an infringing version of a 5 legitimate vendor's software and distributes tagged instances of the said infringing software. A tag table data structure encoded on a device-readable medium accessible by the user's device. If any tagged software has been installed on the device or used by the device, the tag table data structure includes at least one tag that is uniquely 10 associated with one instance of software and includes at least one field associated with the tag in the tag table. The field indicates a usage supervision status for the one instance of software associated with the tag and may also indicate use statistics for the one instance of software associated with the tag. The tag table data structure may also include a tag table header that uniquely identifies the tag table and that 15 uniquely associates the tag table with one user device or with one user device's supervising program. The tag table header includes information concerning user device use statistics and includes a continuation message. The continuation message indicates possible actions and usage supervision status for an instance of software associated with a tag. 20 A software vendor provides a software development process that creates instances of software having a name and having software content. Each instance of the vendor's software is accessible or usable only in conjunction with a unique tag that is associated with that instance of software. The tag is a unique unforgeable collection of information concerning the instance of software with which the tag is 25 associated and includes the name of the software, a unique identifying number of the instance of software and a hash function value of portions of the content ofthe software. The software vendor also comprises an infringing software detection mechanism that detects an instance of software that is infringing on the vendor's intellectual property or other rights. The software vendor transfers a copy of the 30 infringing instance of software to a guardian center so that the methods of the present invention can be employed by the guardian center to detect attempted uses WO 00/72119 PCT/USOO/11821 -35and access to the infringing instance of software, and when detected, to impose punitive actions on the user device involved. A user device includes an input port that receives an instance of software and securely receives a tag uniquely associated with that instance of software. The 5 device also receives requests to install or to use the instance of software. A processor in the user device executes a supervising program. The supervising program detects the attempt to install or to use the instance of software and verifies the authenticity of the tag associated with the instance of software or the status associated with the tag, before allowing installation of or use of the instance of software. From time to 10 time the supervising program determines that a call-up procedure is required as defined by a call-up policy, and the supervising program performs the call-up procedure to update the status of tags stored in the tag table. During the call-up procedure, the supervising program securely transmits the tag table from the user device via an interconnection mechanism coupled to the user 15 device and awaits reception of a continuation message returned to the user device that indicates actions to be performed for each tag in the tag table. In this manner, the user device does not need to be concerned with setting a usage supervision policy, but rather just enforces a usage supervision policy that is common to all devices or vendor's usage supervision policies associated with software instances 20 distributed by those vendors. Call-up policies implemented by a user device's supervising program may be associated with the device, with a particular instance of software used on the said device, or with a particular user of the device. Examples of call-up policies include, but are not limited to, the following. The latest time for the next call-up for a user 25 device may be determined by a combination of the time elapsed since the last call-up, the number of times that the device was turned on since the last call-up, and the total time that the device was used since the last call-up. Similarly a call-up policy associated with a tag or with the instance of software associated with that tag may determine the latest time for the next call-up as a function of the time elapsed 30 since the last call-up, the number of times that the instance of software was used, and the total time that the instance of software was used on the device. Another WO 00/72119 PCT/USOO/11821 -36call-up policy associated with an instance of software may specify execution of a call-up every time that an attempt to use the instance of software on the user device occurs. The invention enforces the behavior of a user device and its supervising 5 program to conform to a call-up policy applicable to the said user device or to any tag in the said device's tag table, by having the supervising program execute a specified punitive action in case of failure to call-up the guardian center and to receive from the guardian a continuation message before the latest time for call-up specified by the call-up policy. The invention ensures that a user device's 10 supervising program accept a message received during execution of a call-up procedure as the guardian center's continuation message for this call-up, only if the said message is in fact sent by the guardian center as the continuation message for the said call-up. This is achieved by the guardian center signing its continuation message and including in it identifying data uniquely linking it with present call-up 15 by the user device's supervising program, as explained before, and by the supervising program verifying the said signature and the said identifying data. The above provisions of the invention prevent a user or a user's device from circumventing the invention's protections by either not calling-up the guardian center according to a call-up policy or by attempting to create or use an improper 20 continuation message. Examples of the above mentioned punitive action on a user device executed by the said device's supervising program upon failure to conform to a call-up policy include, but are not limited to, the following. The supervising program may disable the device from any activity, except for executing a call-up procedure, for a specified 25 length of time. The device may disable use of an instance of software if a call-up policy associated with that instance of software was violated, for a specified length of time. For untagged instances of software installed or used on the user device, the supervising program detects the untagged instance of software and performs a 30 fingerprinting process on the untagged instance of software and stores fingerprints resulting from the fingerprinting process in a fingerprint table on the user device. WO 00/72119 PCT/USOO/11821 -37For untagged software, during the call-up procedure, the supervising program transmits the fingerprint table from the user device via an interconnection mechanism to the guardian center and awaits reception of a continuation message from the guardian center the to user device, said message indicating an action or 5 actions to be performed for each untagged instance of software stored on the user device. For untagged software, the user device's supervising program periodically executes a call-up procedure to send, via an interconnection mechanism, fingerprints for untagged instances of software. This call-up procedure may be initiated by the 10 user device's supervising program or by the guardian center. The guardian center's verification program examines each fingerprint received against the guardian center's fingerprint data structure to determine if an untagged instance of software is an infringing instance of software, and if so, the verification program prepares punitive action for the user device. For example, if the verification program detects a 15 sufficient number of matches between the fingerprints associated with some specified software in the fingerprint data structure and the fingerprints associated with untagged software in the user device, the verification program specifies punitive action to be performed, and the verification program transmits a continuation message to the user device. The continuation message indicates the 20 punitive action to be performed ontheuser device receiving the continuation message. The aforementioned tag server generally accepts a copy of specific software and produces a plurality of tags, one unique tag per instance of said software. Each tag uniquely identifies the instance of software with which it is associated and each 25 tag comprises information concerning the name of the instance of software associated with the tag, a unique number of the instance of software associated with the tag, and a hash function value combining the said name of software, the said unique number of the instance of software, and a hash function value computed on the contents of the software associated with the tag. 30 In the method for supervising the usage of software, the step of creating an instance of software is performed as noted above. A tag is then created that is WO 00/72119 PCT/USOO/11821 -38uniquely associated with the instance of software. The instance of software and the tag are then distributed to a user device. The method then detects an attempt to use the instance of the software on the user device and determines if the attempt to use the instance of the software is allowed by determining a status of the tag that is 5 associated with the instance of software to be used. To create the tag, the method assigns a unique number to the instance of software and computes a first hash function value on the content of the instance of software. The method then computes a second hash function value combining the name of the software, the unique number of the instance of software, and the first 10 hash function value. Finally, the method forma a tag that is uniquely associated with the instance of software. The tag includes the name of the software, the unique number of the instance of software and the second mentioned hash function value. The step of creating a tag can further produce a digitally signed tag by applying a digital signature function to the second mentioned hash function value 15 included in the tag and including the signed hash function value in the tag. Software may be distributed by having the user device obtain an instance of software at the user device as well as the tag associated with the instance of software. The user device can determine if the tag associated with the instance of software is signed, and if so, can verify hash function values in the tag and the 20 signature in the tag. If the said verifications succeed, the user device can-install or use the instance of software. To detect an attempt to access the instance of the software on the user device the method of the invention includes the steps of invoking a supervising program on the user device to intercept a user request for use of the instance of software. To 25 determine if the attempt to use the instance of the software is valid, the method determines if a call-up procedure is needed based on a call-up policy. The method performs a call-up procedure to verify the authenticity and to determine the usage supervision policy of the tag associated with the instance of software and updates tag information in the user device based upon an outcome of the call-up procedure. 30 Status information associated with the tag is examined at the user device to WO 00/72119 PCT/USOO/11821 -39determine if use of the instance of software associated with the tag is allowable. In this manner, usage supervision of software is provided. During the call-up procedure, a tag table storing the tag associated with the instance of software is securely transmitted from the user device to a guardian center 5 and the user device awaits reception of a continuation message returned to the user device that indicates an action to be performed for each tag in the tag table. The guardian center receives the tag table including the tag associated with the instance of software and examines each tag received in the tag table against a tagged software database to ensure that tags in the tag table are in compliance with 10 at least one usage supervision policy. The guardian center transmits a continuation message indicating an action to follow at the user device upon detecting an attempted use of the instances of software associated with each tag. Other embodiments of the invention include a computer readable medium encoded with instructions for the above processes, as well as a propagated signal 15 transmitted via a carrier over a medium which securely carries a tag table data structure as described above. Using these mechanisms, the system of the invention allows a rightful vendor/owner ofthe -rights in an instance of software to police those rights. If the vendor discovers that the vendor rights are being infringed, such as by discovering a 20 bootleg, stolen, reverse engineered, or modified instance of software which is essentially identical in operation to the vendor produced software, the system can police the use of these illegal copies of software. The system of the invention at the same time protects a rightful user of software from denial of service by dishonest parties who attempt to create a false 25 impression of illegal use of software by the rightful user. The invention also allows pay-per-use statistics to be tracked at each user device for an instance of software which is purchased on a per use basis. During the call-up procedure, the guardian center can determine the use statistics for a pay-per-use instance of software and can provide the use information back to the 3 0 software vendor for billing purposes. WO 00/72119 PCT/USOO/11821 -40BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which 5 like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred 10 embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Figure 1 illustrates an information system configured according to one 15 embodiment of the invention. Figure 2 illustrates a more detailed view of the flow of information within a system configured according to one embodiment of the invention. Figure 3A is a flow chart showing the processing steps performed to create a signed tag for an instance of software aceording-to one embodiment of the invention. 20 Figure 3B is a flow chart showing the processing steps performed to create an unsigned tag for an instance of software according to one embodiment of the invention. Figure 3C is a flow chart showing the processing steps performed to create an unsigned tag with fingerprints for an instance of software according to one 25 embodiment of the invention. Figure 4 illustrates the architecture of a user device configured according to one embodiment of the invention. Figure 5 is a flow chart showing the steps performed to install vendor software on a user device according to one embodiment of the invention. 30 Figure 6 illustrates the contents of a tag table according to one embodiment of the invention. WO 00/72119 PCT/USOO/11821 -41Figure 7 is a flow chart showing the processing steps performed to install untagged software on a user device according to one embodiment of the invention. Figure 8 is a flow chart showing high level processing steps performed by the system of this invention to implement software usage supervision according to 5 one embodiment of the invention. Figure 9 illustrates the architecture of a guardian center configured according to one embodiment of the invention. Figure 10 shows the contents of a guardian center record for an instance of software according to one embodiment of this invention. 10 Figure 11 is a flow chart of the processing performed by a guardian center, according to one embodiment of the invention, when a vendor detects software that infringes on the vendor's rights in some of his software. Figure 12 is a flow chart of the processing steps performed by a user device's supervision program when executing a call-up procedure to the guardian center 15 according to one embodiment of the invention. Figures 13A and 13B show a flow chart of the guardian center call-up processing steps that are performed according to one embodiment of the invention. Figure 14 shows the data structures used in an embodiment of the invention without guardian center call-ups. 20 Figure 15 is a flow chart of processing steps performed by a user device's supervision program in an embodiment of the invention without guardian center call-ups. DETAILED DESCRIPTION OF THE INVENTION Figure 1 illustrates an example information system 109 configured according 25 to the invention. Figure 1 is provided to describe the main component elements of the invention and to generally describe their operational interrelationships within the context of the invention. Information system 109 includes a communication network 100 which interconnects a plurality of user devices 104 through 107 and one or more software vendors 101, tag servers 102, and guardian centers 103 (one of 30 each shown in this example embodiment). The invention is intended to supervise WO 00/72119 PCT/USOO/11821 -42usage of information (not shown) which is used with the assistance of one of the user devices 104 through 107, so as to prevent a user device from installing or using any information in a manner infringing on intellectual property or other rights of an owner or distributor or vendor in that information. 5 Information, the use of which is supervised by the invention for the purpose of protecting intellectual property or other rights, may be any type of electronically, magnetically, optically or otherwise represented information. Examples of information are a computer software application or program, data, a web page or web site, a downloadable application program such as a Java applet, an electronic 10 book, images, video, recorded music or other information on a compact disk, magnetic disk or tape, and so forth. Generally, the usage of any type of information that is used with the assistance of a computer or other device (for example, user devices 104 through 107) can be supervised and the rights in that information can protected by the invention, regardless of what the information is or what the actual 15 physical medium upon which the information is stored or transmitted. Any such information, as well as any other type of information recognized by people skilled in the art to be protectable by the invention will be referred to hereinafter as software. Any individual copy of a specific software, such as for example, a copy of a specific application program or a specific book or video, will 20 be hereinafter referred to as an instance of software or a software instance. An owner or vendor or distributor of software will be hereinafter referred to as a vendor or software vendor. The installation of, use of, execution of, reading of, displaying of, playing of, viewing of, printing of, copying of, transmitting of, or access to an instance of software by use of or on a device will hereinafter be referred to as use of 25 that instance of software. User devices 104 through 107 may be any type of device that is employed to use software, including but not limited to a computer system, book reader, music player (e.g., tape player, compact disc player, mini-disc player), video cassette recorder, Digital Video Disc (DVD) player, special purpose devices and so forth. 30 Any such device will hereinafter be referred to as a user device or just device. WOOO/72119 PCT/USOO/11821 -43In a preferred embodiment of the invention, the user device (i.e., one of 104 through 107) is a computer system and the information is a computer application program or data and the invention provides a mechanism to supervise usage of the software or data by a user of the computer system so as to protect vendors' rights in 5 that software. The communication network 100 may be any type of communications mechanism which enables the component elements of the invention (101 through 107) to exchange information such as messages or signals. Examples of communication network 100 are a computer network such as the Internet, a Public 10 Switched Telephone Network (PSTN), a wireless network (i.e., a cellular network), or other type of computer or information network. According to the general operation of the invention, the software vendor 100, and of whom there may be more than one, produces and distributes instances of software (not shown in Figure 1). The instances of software can be installed or used 15 on each user device 104 through 107 on which the software is intended to be used. By way of example, if the software is in the form of music on tape, the tape can be installed on user device 105, which is illustrated as a tape player in the figure. The software may be physically or manually transported from the software vendor 101 and installed on a user device 104 through 107 (i.e., as in the case of a physical 20 tape), or the software may be electronically disseminated and installed via the communication network 100 using known data transport mechanisms (i.e., as in the case of downloading an instance of software from the software vendor 101 to a user device 107). The tag server 102, which is a computer system coupled to the 25 communication network 100, creates or generates a tag (not shown in Figure 1) for each instance of software. Typically, all instances of a specific software are identical. Preferably, a single tag is uniquely associated with a single instance of software produced by the software vendor 101. The tag server 102 has access to the software created by the software vendor 101 preferably via the private 30 communications path 108 and the tag is preferably created based on the contents of the software, the name, and other information generated by the tag server (such as an WO 00/72119 PCT/USOO/11821 -44instance number) or provided by the vendor. The tag server 102 can also obtain software for tagging by using the communication network 100. Alternatively, there may be a single software vendor 101 selling a variety of instances of different software, and there may be a single tag server 102 and one 5 guardian center 103 for that single software vendor 101. The tag server 102 and guardian center 103 may be part of the software vendor 101 (i.e., contained within the same computer system). Alternatively, there may be a consortium of software vendors 101 which rely on and which are served by one or more commonly shared tag servers 102 and guardian centers 103. 10 Once a tag is created for an instance of software, the tag is securely disseminated to one ofthe user devices 104 through 107 that contains the installed corresponding instance of software for that tag. Secure tag dissemination preferably takes place electronically via the communication network 100, for example, by use of the TETS IPSEC or the NETSCAPE SSL protocols for secure communication. 15 Manual secure tag dissemination may be used by the system of the invention as well. An example of manual secure tag dissemination would be to distribute the tag within a tamper proof package containing the tag and possibly also the associated instance of software. Once an instance of software and the tag associated with that instance of 20 software are installed on a user device 104 through 107, a user (not shown) of that device or the device itself can attempt to use the software. However, before use of the instance of software is allowed, the supervising program (not shown) in the user device 104 through 107 that contains the software verifies that a valid tag exists within the user device for the instance of software requested by the user or by the 25 device. Periodically, each user device communicates with the guardian center 103 via communication network 100 to ensure that all tags associated with the instances of software on that user device are valid and are being used in compliance with a usage supervision policy. In other words, the invention ensures that use by means of a device of the 30 instance(s) of software is linked to the presence of valid associated tags which are periodically validated and checked for usage characteristics by having the user WO 00/72119 PCT/USOO/11821 -45device communicate with the guardian center. An example of an enforced usage supervision policy is that a tag is present on only one device. The determination of whether or not a user device 104 through 107 can use an instance of software is based on a tag processing procedure called a call-up (explained in detail later) that is 5 performed between the user device and the guardian center 103. Before further description of detailed embodiments of the invention are provided and explained, Table 1 below provides a glossary of terms to aid in understanding the various elements associated with the invention: Table 1: Definition of Terms WO 00/72119 PCT/USOO/11821 WO 00/72119 PCT/USOO/11821 WO 00/72119 PCT/USOO/11821 Detailed Definitions for Technical Terms: Certain embodiments of the invention are complex in nature. As such, other supporting definitions are provided below for some of the technical terms used by certain embodiments of the invention: 5 I.A fingerprinting orhash fiinction F: a mathematical function for mapping data X to smaller data F(X) such that if X and Y are unequal, then it is highly likely that F(X) and F(Y) are unequal. As an example of a hash function, X may be a sequence of bytes. In addition, there is a number p which is a preferably randomly chosen, but henceforth kept fixed, 64 bit prime number. The sequence X of bytes is 10 viewed as a number (written to the base 256, where the bytes are the digits of that number) and F(X) = X mod p. Thus the value F(X) is a 64 bit string, no matter how large X is. 2. An unaliasable hash function H: a fingerprinting function having the further property that given X, it is easy to compute H(X), but it is intractable to 15 produce an X’ such that H(X) = H(X') and X and X' are different. The term WO 00/72119 PCT/USOO/11821 -49” intractable means that the computational time required is generally understood to be exponential or practically unfeasible in the size of X, according to the present state of the art. An example of an unaliasable hash function is MD5. 3. Use of an instance of software: installing, using, executing, running, 5 connecting with, reading, otherwise retrieving from a storage medium or modifying a storage medium, displaying, playing, viewing, printing,, copying, transmitting, or accessing to an instance of software by use of or on a device. 4. A portion of an instance of software includes all of the text or data of that instance or a sequence of parts of the text or data of that instance of software. The 10 parts need not be contiguous and may overlap with one another. 5. Fingerprinting process: given a sequence of locations in an array of data, a computation of some function value on the values of those locations. For example, if locations 16, 32, and 64 have values 3,4, and 17 respectively, then a fingerprinting process computes a function of 3,4, and 17. This function may simply be the list of 15 those values (the three numbers in this example) or may be a hash function of the list of those values. In another example, the locations may be i_l to j_l, i_2 to j_2, up to i_k to j_k. A fingerprinting process may compute a hash function value of each of these k subsequences of the array and list the k computed values. 6. Fingerprint checking: a method for comparing two sequences of 20 fingerprints. This invention uses two kinds of fingerprint checking: same-location fingerprint checking and general-location fingerprint checking. In both forms of fingerprint checking, a list of fingerprints is computed based on the values in a list of lists of locations. For example, suppose there are three fingerprints in the list fl, f2, and f3 and fl is computed from the values in locations 10, 20, 30, and 40, f2 is 25 computed from the values in locations 30 and 60, and f3 is computed from the values in locations 100 and 200. Let us call this list the Send List. In both forms of fingerprint checking, the receiver of the Send List computes the fingerprint list based WO 00/72119 PCT/USOO/11821 -50on the values at the same location lists as the sender. This fingerprint list is called the Receive List. In same-location fingerprint checking, a match is declared if each element of Send List is equal to the corresponding element of Receive List. That is the first 5 element of Send List equals the first element of Receive List, the second element of Send List equals the second element of Receive List, and so on. In general-location fingerprint checking, a match is declared if there is a sufficiently large number of common elements in Send List and Receive List regardless of location. How many is sufficient may depend on policy considerations 10 and on the length of the data text from which the fingerprints are taken, defined by a parameter k. If k is 50 bytes, for example, then as few as one or a small number of matches may be sufficient to establish that a Device List is likely to represent the same software as a list in the Guardian Center's Fingerprint Data Structure (Figure 9, 137). Furthermore, certain matches may be given more weight than others, so fewer 15 matches of higher weight may be sufficient. In addition to sending the Send List of fingerprints, the sender may send the list of location lists whose values produced Send List. This permits the fingerprints to be calculated to depend on an unpredictable random process. 7. Unforgeability: a tag is unforgeable if it is computationally infeasible for 20 an adversary to produce a valid tag without knowledge of the secret information used by the Tag Server (Figure 1,102) to produce tags upon a vendor's request. This invention uses digital signatures (Figure 3A) and sparse sets (Figure 3B and 3C) as two preferred ways to achieve unforgeability of tags. 8. Secure transmission: a way of sending a value X such that only the 25 intended recipient can see X, though other agents may observe the network protocol or see the package by which X is transported. A sealed envelope delivered by a reliable courier is one way to securely transmit the contents of an envelope. Sending WO 00/72119 PCT/USOO/11821 -51a message by use of the TETS IPSEC or the NETSCAPE SSL protocols for secure communication, is another way to ensure secure transmission over the communication network (Figure 1,100). 9. Event history: is a timed record of all attempted uses, successful uses, 5 duration of uses, and/or other events such as power-ups associated with a tag table. It is unlikely for two devices to have the same event history, even if they have the same software instances and the same identifiers. An event history may be based upon a record of use of a particular device by one or more users over time. Returning now to a discussion of the figures, Figure 2 provides a more 10 detailed illustration of the architecture of the system 109 configured according to the invention. Figure 2 will be used as an outline for the overall description of the entire operation of the invention. Throughout this description, reference will be made to other figures describing in more detail each aspect of this invention. In operation of the system 109, instances of software (INST_SW) 111 15 through 114 (labeled as SWI, SW2, SW3, SW4) are created by the software vendor 101 and stored in vendor storage 110. There may be more than one software vendor 101. Examples of software vendors 101 are publishing houses (creating reproducible performance recordings or electronically readable books), computer software developers (creating computer software application programs), data 20 collection companies (creating databases of information), individual programmers, and so on. The software (SW) produced by software vendor 101 represents actual software content (SW), which may include information, data or code. The software (SW) may have an associated name (NAME_SW) which is typically assigned by the software vendor 101. Each instance of software (INST_SW) 111-114 can be 25 thought of as a separate physical copy of the named software (SW). That is, each instance of software (INST_SW) for particular software (SW) is merely a copy of that software (SW) having the same name (NAME_SW) and the same code, data or other informational content. WO 00/72119 PCT/USOO/11821 -52By way of example, if a word processing application program is created by the software vendor 101 and is given the name (NAME_SW) Write, the binary or executable code, data or other information that comprises the Write program is termed software (SW). Each individual copy of the Write software (SW) (e.g., each 5 disk containing a copy of the program) is a distinct instance of that software (INST_SW) but has the same software content (SW). Thus in Figure 2, each instance 111-114 may contain the same software content (SW), in which case each instance 111-114 would have the same name (NAME_S W), or, each instance 111-114 may be representative of a copy of different software (SW) (i.e., different 10 data, code or other information) and the name of each instance (NAME_SW) 111-114 that has different software content (SW) would typically be different. The tag server (TS) 102 creates, upon the vendor's 101 request, a unique unforgeable tag (TAG_INST_SW) 120 for each instance of software 111-114. In a preferred embodiment of the invention, a single unique tag is prepared for an 15 instance of software and is associated with that instance. In other embodiments, multiple unique tags may be associated with one instance of software, but preferably, two different instances of software do not share a common associated tag. In order to create the requested tags, the TS 102 (Figure 1) obtains (Figures 20 3A, 3B, & 3C, step 150) one copy of each specific software for instances of which it will create tags. For example, it may have one copy of Write 7.2 where Write 7.2 is a release or version of the program family Write. Generally, a tag 120 is a unique, unforgeable sequence of data bits that is associated with a particular instance of software (INST_SW) (i.e. one of 111-114). As will be explained, according to 25 embodiments of the invention, a user device 104 is unable to use an instance of software 111-114 without first examining a valid tag 120 associated with that instance of software 111-114. Tags 120 for instances of software 111-114 are preferably stored in a tag table 210 on a storage device 200 that is coupled to or that is integrally part of the 30 user device 104. An instance of software 111-114 can be used on a user device 104 only by reference to a tag 120 associated with that instance of software (one of WO 00/72119 PCT/USOO/11821 -53111-114) which is stored in the tag table 210, and only if the associated tag 120 for that instance 111-114 has a usage status (Example Tag Table shown in Figure 6, with Usage Status indicated in column 2) allowing use of the software instance on or by the user device 104. That is, certain specific software includes the indication that 5 it can run only if a tag for an instance of that software is present. (A pirate may remove this indication in which case the protection mechanisms for untagged software, detailed below, will apply.) In this manner, aspects of the invention allow and provide control over the use of software in certain embodiments by requiring a valid tag specifically associated with that instance of software to be present on the 10 user device 104. As will be explained further, the ability of components in a system configured with the invention to track and manage tag creation, validation, and enforcement provides unique advantages over prior art systems for software usage control. Before further discussions of the remaining components ofthe system 109 15 in Figure 2 are provided, details of tag creation will be discussed. Figures 3A, 3B, and 3C are flow charts showing preferred embodiments of the processing steps performed during the tag creation process within the tag server 102 configured according to the invention. Since the figures are similar, many of their step numbers are the same and the two figures will be explained 20 simultaneously. In step 150, the tag server 102 obtains from its local storage a copy 111-114 of named software (NAME_SW, SW) to be tagged. In addition, the tag server 102 obtains a request for a tag (Figure 2) from the vendor 101. In step 151A (Figure 3 A) and 15 IB (Figure 3B) and 151C (Figure 3C), the tag server 102 generates a unique 25 number (NUM_INST_SW). In step 151A in Figure 3A, the number is simply unique. However, in step 15 IB in Figure 3B and 151C in Figure 3C, the unique number (NUM_INST_SW) is selected from sparse sets 118 (Figure 2). Sparse sets 118 (Figure 2) are sets of secret numbers from which instance numbers (NUM_INST_SW) are chosen for instances of named software 30 (NAME_SW, SW). Preferably there are relatively few such numbers compared with the available range of numbers (e.g. if there are 100 million instances of a WO 00/72119 PCT/USOO/11821 -54particular software, and more than 10 billion billion possible numbers in the range defined by 64 bits). As such, the sets 118 are referred to as sparse. Sparseness makes it difficult for an adversary or software pirate to generate a valid instance number. There may be one sparse set for all software, or a different 5 sparse set for each specific software defined by a set of related instances. In the preferred embodiment one sparse set 118 is used as a source of instance numbers for all software. However, having a separate sparse set 118 for each specific software may permit simpler distributed management of instance number generation. For example, there may be a sparse set of numbers 118 (SPARSE_SET_SW) 10 associated with the Write application software noted earlier, from which instance numbers (NUM_INST_SW) are selected for each instance (INST_SW) of the Write software. For security reasons, new members of sparse sets may be materialized or generated on demand, by access to a physical process such as an photoelectric counting device (not shown in the invention) for example. 15 In step 152 (Figures 3 A and 3B), the tag server 102 computes a hash function value on the software (SW) content or on a portion of the SW content. In the preferred embodiment, if more than one instance of software (INSTJSW) 111-114 that contains the same software content SW is to be tagged, then the hash function value HASHJSW is computed only once for the software (SW), since each instance 20 111-114 contains ±e same code, information, and/or data (i.e., has the same SW content). Further, only the value HASH_SW needs to be retrieved or generated by the tag server 102 once, rather than for each copy of the full software. This aspect of the invention saves tag creation time when many instances of the same software (SW) are to be tagged. In such cases, the hash function value HASHJSW needs to 25 be computed only once. In alternative embodiments, computing the hash function value on only a portion of the software content may be a further optimization, since this may reduce the time required for building the hash function value on both the tag server 102 and on the user device(s) 104-107. In step 153 (Figures 3 A, 3B and 3C), a second hash function value 30 HASH_INST_SW is computed, to be incorporated into the tag to be associated with the software instance (INST_SW). Step 153 differs from step 152 in that the hash WO 00/72119 PCT/USOO/11821 -55value HASH_SW computed in step 152 is the same for all instances INST_SW of the same software SW, whereas in step 153, the hash value HASH_INST_SW is unique for each NUM_INST_SW of the same software SW. In one embodiment, the second hash function value HASH_INST_SW combines together the name of 5 the software (NAME_SW), the unique number of the instance of the software (NUM_INST_S W), and the previously computed (Step 152) hash function value HASH_SW. Other hash value combinations such as name and software only, or software and number only, or others, may now be recognized as providing a similar functionality as understood by those skilled in the art. Such combinations of data 10 encoded via a hash function are meant to be within the scope of this invention. After the hash value HASH_INST_SW is computed for each instance of software 111-114, either a signed (Figure 3A) or unsigned (Figure 3B and 3C) tag may be created for those instances 111-114 by steps 154A and 154B. In step 154A in Figure 3A, a signed tag is created for an instance of software 111-114, whereas in 15 step 154B in Figure 3B&3C an unsigned tag is created for instances of software 111-114. A signed tag ensures that the tag will be unforgeable by digitally signing portions of the tag prepared, even if the instance numbers are predictable (e.g., even if they are consecutive numbers). An unsigned tag may not offer this protection, but since die unsigned tag created in step 154B preferably includes an instance 20 number NUM_INST_SW taken from the sparse set 15IB, this alternative still assures unforgeability of the tag. The signed tag TAG_INST_SW is computed in step 154A as follows: TAG_INST_SW = (NAME_SW,NUM_INST_SW, HASH_INST_SW, 25 SIGN_TS(HASH_INST_SW)) where the term SIGN_TS is a digital signature function performed on the HASH_INST_SW hash function value. The digital signature SIGN_TS is produced by the tag server 102 using the private key PRIVATE_KEY_TS 117, which is a digital key that is kept secret from all potential adversaries and all entities in Figure 30 2, except the tag server 102 itself. WO 00/72119 PCT/USOO/11821 -56The unsigned tag TAG_INST_SW is computed in step 154B (Figure 3B) as follows: TAG_INST_SW = (NAME_SW,NUM_INST_SW, HASH_INST_SW). After creation of a tag TAG_INST_SW by the tag server 102, the tag is 5 preferably securely transmitted (as shown by TAGS 120 in Figure 2, and as will be explained in more detail with respect to Figures 13A&13B, in step 156) to the requesting software vendor 101 and to the guardian center 103 where the tag(s) 120 are stored in various tag databases (as will be explained with respect to Figure 9, 129,138). 10 A tag 120 associated with an instance of software (e.g. 111) and the manner in which the tag 120 is prepared by the tag server 102 serve a number of important purposes in the invention: (1) (2) A device (e.g. 104) cannot use an instance lll of a vendor's 101 software 111 unless the device 104 stores or has access to the associated valid tag 120, preferably maintained in the device's 104 tag table 210 (shown in detail inFigure 6) and unless that associated tag 120 has a usage status (column 2 in Figure 6) in the tag table 210 that allows or indicates proper usage for the associated instance lll. Through mandated call-up procedures (Figures 12, 13A&B), to be detailed later, between a device (e.g. 104) and the guardian center 103, the guardian center 103 can supervise, authenticate, track, validate and generally control tag properties and ensure that the instance of software lll associated with a tag 120 is used in accordance with the vendor's 101 usage supervision policy (maintained preferably at guardian center 103) for that instance of software 111. The unforgeability of a tag 120 and the fact that tags 120 are preferably transmitted in a secure manner ensure that only a user or (3) WO 00/72119 PCT/USOO/11821 -57user device 104 who or that has rightfully obtained a tag 120 from a vendor 101 (or tag server 102) and has used the associated instance of software 111-114 in accordance with the vendor's 101 specified usage supervision policy (not shown in this figure) for this instance of 5 software 111, has this tag 120. This aspect of the invention prevents an adversary or pirate from trying to create and/or attempt to use a copy of a valid tag 120 which in turn would result, according to the mechanisms of the invention, in punitive actions against the copying adversary/pirate as well as against the rightful user or user device 10 using the instance of software 111 and the associated tag 120. It is to be understood that there may be several alternative compositions of a tag 120. One alternative is to have a subset of the fields described herein. Specifically, the hash value HASH_INST_SW may not be included in a tag 120, thus leaving NAME_SW and NUM_INST_SW in a tag 120. An advantage of such 15 an embodiment is that less data needs to be sent between system components (e.g. 101,102,103, 104) and computed for each tag 120. A disadvantage may be that the owner of a tag 120 might then attempt to associate the tag 120 with a different specific software instance 111. This is prevented when HASH_INST_SW is available in a tag 120 since the value HASH_INST_SW depends on HASHJSW and 20 HASH_SW can be used to verify that the software SW within an instance 111 is correct or unaltered. An alternative tag composition may be as follows: NAME_SW, NUM_INST_SW, HASH_SW. Using this composition, every tag 120 will be associated with software whose content (i.e. SW) matches with a hash fimction to 25 HASH_SW. A possible disadvantage of this scheme is that it may allow the possibility that a pirate might generate illegitimate tags 120 that appear correct. Depending upon the complexity of the embodiments of the invention selected to protect the use of software, the systems described herein are designed to alleviate the various noted problems. WO 00/72119 PCT/USOO/11821 -58As another example, a third alternative composition of a tag 120 may be as follows: NAME_SW, NUM_INST_SW, HASH_SW, SIGN_TS(NAME_SW, NUM_INST_SW, HASH_SW). In this type of tag 120, the digital signature SIGN_TS prevents tag forgery, since preferably only the tag server 102 possesses 5 the secret key SECRET_KEY_TS required for computation of the signature function SIGN_TS. Another tag field that may be removed is the field NAME_SW. An advantage of this embodiment is to reduce the amount of data sent between system components. The name may be unnecessary if the software instance INST_SW 10 indicates by some means other than the name which tag must be present for INST_SW to run or be used. A nameless tag may work, for example, if there is only one kind of software being distributed from a given software vendor 101, in which case a software vendor 101 identifier can serve as a name for the software produced by that vendor. Alternatively, the NUM_INST_SW may be globally 15 unique across all kinds of software in which case the NAME_SW is unnecessary. Another field that may be removed from a tag 120 is NUM_INST_SW. An advantage to this tag composition is a reduction in the amount of data that must be sent over network 100 and a more simplistic tag generation scheme can be used without a need for a unique number selection process (e.g. step 151 aswillbe 20 explained in Figures 3A, 3B, and 3C). A possible disadvantage is that different tags having the same NAMEjSW (if that field is kept) may become indistinguishable, so duplicate instances 111-114 might be allowed. Another alternative embodiment of tags is to include additional fields. A unique identifier of a user device's (e.g. 104) Supervising Program (discussed later 25 in detail as 209 in Figure 4), denoted ED(SP) (209-A in Figure 4), may be computed, for example, from a combination of a hardware identifier, if available, the time when the device's 104 supervising program 209 was first invoked and, if available, a unique number securely obtained by the device's supervising program 209 from the guardian center 103 and the values of at least one memory location 30 within the device. This will be discussed in more detail later, but is mentioned now to provide the reader with a more comprehensive understanding of various tag WO 00/72119 PCT/USOO/11821 -59creation processes. Including the identifier ID(SP) 209-A of the user device's 104-107 supervising program 209 in a tag 120 associated with an instance of software lll used on that device, may support less expensive Guardian Center 103 call-ups as described in more detail below. 5 An additional field that may be included in an alternative tag and tag creation embodiment of the invention is a list of fingerprints for specified locations of data within an instance of software INST_SW. Fingerprints will be explained in more detail, but as their name suggests, a fingerprint is a unique encoding of one or more portions or data areas selected from an instance of software. The usage of 10 fingerprints is illustrated in steps 151D and 151E of Figure 3 in which locations are selected and then a fingerprint is computed on those locations and the a hash is computed on that result. Including a fingerprint of an instance of software lll within a tag 120 associated with that instance permits a supervising program (Figure 4, 209, used to access the software) in a user device 104-107 to verify that the 15 association between INST_SW and the tag is correct by performing a same location fingerprint check (Detailed Definitions, following Table 1, Figure 6) on INST_SW and comparing with the list of fingerprints in the associated tag. While the use of fingerprints may overlap the functionality of HASH_SW, they permits greater efficiency for the validation of the correctness of the association of a tag with an 20 instance of software. For large instances of software INST_SW, such as for example, an encyclopedia or a video, the computation of HASH_SW, which requires the supervising program to scan the whole of INST_SW, will require considerable time. If the tag associated with INST_SW contains the above fixed location fingerprint 25 values computed by the tag server, the supervising program (209 in Figure 4) only needs to access those locations in INST_SW and compute the corresponding fingerprint values. Using the above fingerprints provides additional protection benefits, since the locations on which the fingerprints are computed by the tag server can be changed over time in response to piracy attacks. 30 Similar efficiency and security benefits are obtained if the hash function value HASH_SW is computed (Figures 3A&B, step 152) by the tag server 102 only WO 00/72119 PCT/USOO/11821 -60on specified portions of SW, instead of the whole of S W. The specified locations in an instance of software INST_SW 111 -14 for which fingerprints are computed by the tag server 102, may explicitly accompany the fingerprints in the tag 120 or may be included in the instance ENST_SW or in the device's 104-107 supervising 5 program (Figure 4, 209). The advantage of incorporating these fingerprint locations in a tag 120 is that the fingerprints can vary for each instance INST_SW being sent, with the fingerprints serving as a kind of unique NUM_INST_SW and permitting random checks of software code alterations. Accordingly, tags 120 consisting of the following field combinations all fall 10 within the scope of this invention: the tags produced as a result of processing in Figures 3A, 3B, and 3C;any of the above combinations of fields plus a form of supervising program identifier 209-A (Figure 4) for a user device (e.g.: 104) such as ID(SP), where the value ID(SP) may be combined in computing the hash function value HASH_INST_SW;any of the above combinations of fields plus a list of 15 fingerprints associated with the contents of SW, where the values of these fingerprints may be combined in the computation of the hash function value HASH_INST_SW;and any superset of any of the above combination of fields. Though the above tag and processing descriptions describe specific implementations of embodiments of the invention, those skilled in the art should understand that tags 20 are generally provided by the invention to uniquely identify and control use of one of more specific instances of software. Once the tags 120 are created for the instances of software 111 through 114, the tags 120 are securely transmitted by the tag server 102, in step 156, to the guardian center's database(s) (to be explained with respect to Figure 9, 129,138) or 25 to the user device 104, or to the software vendor or to any combination of the above entities. Turning attention now back to Figure 2, the tags 120 can be securely, distributed by the tag server 102 to one or more of the software vendor(s) 101, the guardian center(s) 103, and the user device(s) 104. If the tags 120 are securely 30 transmitted by the tag server 102 back to the software vendor 101 but not to user devices 104-107, then the tags 120 will be securely distributed by the software WO 00/72119 PCT/USOO/11821 -61vendor 101, along with the instances of software 111-114, to the user devices 104-107. Alternatively, the instances of software 111-114 are obtained by the user device(s) 104-107 separately from the tags 120, which canbe obtained directly by the user device(s) 104-107 from the tag server 102. Alternatively, the tags 120 can 5 be obtained from one or more guardian center(s) 103. The instances of software 111-114 themselves are not required to be securely distributed, though they may be in alternative embodiments of the system 109 of the invention. Distribution of the instances of software 111-114 can take place in a number of ways. The instances 111-114 may be downloaded from the software 10 vendor(s) 101 via downloading mechanisms supported over the communication network 100 (Figure 1). Examples of downloading mechanisms are the File Transfer Protocol (FTP), PUSH protocols that send information to a receiver, TCP/IP and World Wide Web related protocols, and other protocols used to transfer data over busses between computer processors, or over other types of computer 15 networks such as communication network 100, which may be the Internet, for example. Alternatively, the user device(s) 104 may be pre-equipped with the instances of software 111-114 that are pre-installed by a user device manufacturer (not shown) which may or may not be the same entity as the software vendor(s) 104. An 20 example would be an instance of software 111-114 embedded in firmware within a user device 104. As another alternative, users (not shown in this figure) of the user device(s) 104 may purchase the instances of software 111-114 on a user device readable medium, such as a magnetically encoded hard or floppy disk or an optical medium such as a CD-ROM, DVD disc, video or audio tape, holographic storage 25 device, or another medium that can carry information. In each of the above alternative ways for the user devices 104-107 to obtain an instance of software 111-114, the associated tag 120 which according to the invention is required for using that instance of software can directly accompany the instance of software or can be separately and preferably securely transmitted to the device. 30 The user device 104, as shown in Figure 2, includes a coupling to a user device storage mechanism 200. The user device storage 200 is able to maintain each WO 00/72119 PCT/USOO/11821 -62instance of software 111-114, a tag table 210 and a fingerprint table 126. The purpose and details of fingerprint and tag tables 126, 210 will be explained in more detail shortly. Figure 4 illustrates a preferred architecture of a user device 104 configured 5 according to the invention. The user device 104 includes an internal bus 206 which couples the user device storage 200, a processor 201, a memory 202, an interconnection mechanism 203, and a user input/output mechanism 204. A user 213 interacts with the user device 104. The user 213 is preferably a human being, though the invention can be applied to systems in which usage supervision as 10 explained herein is implemented on electronic components within larger non-human interaction environments. In this illustration, the user 213 is shown to be interacting directly with the instances of software 111-114 to highlight the purposes of the invention. In practice, the user 213 may actually interface with the user input/output mechanisms 204 which indirectly supplies input and output to and from the 15 instances of software 111-114 under the control of the processor 201. The user input/output mechanism 204 may be one or more of a keyboard, mouse, microphone, speaker, monitor, heads-up or virtual reality display, or other input/output device used to communicate information to and/or from the user 213 or other mechanisnr(i.e., non human) that interacts with the user device 104. The 20 input/output mechanism 204 may also serve as a means by which the user device 104 is provided with the instance of software 111-114. In this case, the input/output mechanism 204 may include such mechanisms as a CD-ROM or DVD drive, scanner, floppy disk drive, or another mechanism that can be used to load information onto the user storage device 200 or into the memory 202 or into buffers 25 (not shown in Figure 4) which may be included in or associated with the user device (e.g·: 104). The interconnection mechanism 203 is used to interface to the communication network 100 and may be a device such as a modem, network interface card, wireless transceiver, or other device used for communications. 30 The user storage device 200, which may be a hard, floppy or optical disk drive, RAID array, file server, or other read/write storage mechanism is used to WO 00/72119 PCT/USOO/11821 -63maintain various components and data used by the invention. Specifically, as illustrated in this embodiment, the user storage device 200 maintains the instances of software 111-114, the tag table 210, the fingerprint table 126, a supervising program 209 (Figure 4) and an operating system 207 including a kernel 208. The operating 5 system 207, as understood in the art, is typically loaded into memory 202 upon startup of the user device 104 and executes in conjunction with the processor 201 to control the overall operation of the various components of the user device 104. Alternatively, the operating system and components of this invention may be embedded in the architecture of the processor or system embodying the invention. 10 An example of a user device 104 is a personal computer or workstation. Examples of the processor 201 are an Intel-based processor such as a Celeron, Pentium, Pentium II, Pentium III, or 80x86 family or a SPARC-based processor using RISC technology or a MIPS processor. These processor names may be trademarks of respective microprocessor manufacturing companies. Examples of 15 the operating system 207 are any of the Windows-based operating systems such as Windows NT, Windows98, Windows95, WindowsCE or Windows 3.1 manufactured by the Microsoft Corporation of Redmond, Washington, or the operating system 207 may be, for example, a UNIX-based system such as Solaris from Sun Microsystems, Inc. of Mountain View, California: Other embodiments of 20 the user device 104 may be dedicated devices that use specialized processors 201 which have custom or embedded operating systems 207. Those skilled in the art should understand that the user device 104, as stated previously, can be any type of device that is microprocessor controlled. The invention is not meant to be limited by the architecture of the user device 104 shown in Figure 4. Rather, any device that 25 can access software for a user is meant to be within the scope of this invention. In order to provide the usage supervision aspects of the system of the invention, the supervising program (SP) 209 is provided and executes in conjunction with the operating system 207, the tag table 210, the instances of software 111-114, and optionally, the fingerprint table 126 (Figure 4). The supervising program (SP) 30 209 is preferably a separate entity from the operating system 207, though it may be an extension thereof. The supervising program (SP) 209 is also preferably a WO 00/72119 PCT/USOO/11821 -64software program written in any programming language (e.g., C, C++, Java, Assembler, or any other language) and preferably uses an application programming interface (API) provided by the operating system 207 to interface with and control certain functions of the operating system 207. Alternatively, in an embedded system 5 user device 104, the operating system 207, supervising program (SP) 209, and other data and or components within user device 104 may all be embedded or completely represented via electronic circuitry or stored in a memory. In a preferred embodiment of the invention, upon each startup (i.e., power-up) of the user device 104, the operating system 207, supervising program 10 (SP) 209 and tag table 210 are read into memory 202 from the user storage device 200. On the first startup of the user device 104, preferably, an identifier ED(SP) 209-A for the device's supervising program 209 (Figure 4) is computed and stored in a secure location. This identifier 209-A, as discussed in the glossary above (Table 1, ID(SP)), is computed based on some combination of the following: a hardware 15 identifier, if available;a number provided by a guardian center 103 (Figure 2), if available;and the value of a high precision timer (e.g., microsecond) within the device 104. In the system of this invention, the supervising program (SP) 209 serves as a usage supervision interface between the instances of software 111-114 and the operating-system-207. Before the operational aspects of usage supervision provided 20 by the supervising program (SP) 209 are explained in detail, the installation of instances of software 111-114 and the associated tags 120 onto user device 104 will be discussed. Figure 5 illustrates the steps involved to install an instance of software INST_SW and the associated tag TAG_INST_SW onto a user device 104 according 25 to a preferred embodiment of the invention. Both the tags 120 and the instances of software 111-114 may be installed by being loaded onto the user device 104 through a user input/output mechanism 204, or may be electronically installed via reception from the communication network 100 through the interconnection mechanism 203. The steps in Figure 5 are preferably performed by the processor 201 executing the 30 supervising program (SP) 209 code provided as part of the invention. The supervising program 209 can reside in the operating system 207, as an extension to WO 00/72119 PCT/USOO/11821 -65the kernel 208, for example, or may reside and execute as a separate process above the kernel 208 and operating system 207. In either case, the user device 104 (in this example a personal computer, but the provisions of the invention apply to any other device in the sense of the 5 invention) obtains an instance INSTJSW of a specific named software (NAME_SW, SW) in step 250 in Figure 5. In step 251, the user device 104 securely obtains the tag TAG_INST_SW associated with the instance of the named software obtained in step 250. In step 252, the system of the invention determines if the tag TAG_INST_SW is a signed or unsigned tag. Step 252 may be performed by 10 examining the tag information received to determine if the SIGN_TS function value is present or not within the tag TAG_INST_SW. Next, the supervising program proceeds to validate the tag and its proper association with the instance of software as follows. In a preferred embodiment of the invention the tag is created by the tag 15 server 102 according to the steps in Figures 3 A, 3B or 3C and has the contents produced by step 154A (Figure 3A) for a signed tag and 154B (Figure 3B and 3C) for an unsigned tag. If the tag TAG_INST_SW is a signed tag, step (Figure 5, 253) invokes a part of the supervising program (SP) 209 to compute the hash function value V = HASH(INST_SW) and a hash_fimction-value U = HASH(NAME_SW, 20 NUM_INST_SW, V). The supervising program 209 then compares the value U with the value HASH_INST_SW found in the tag TAG_INST_SW. If the two compared values do not agree then the tag is invalid. If the values U and V agree then the supervising 209 program further verifies, by use of the tag server's 102 public key PUBLIC_KEY_TS (Figure 2, 116), the digital signature on SIGN_TS 25 (HASH_INST_SW) that exists within the tag TAG_INST_SW. If the tag server's signature in SIGN_TS(HASH_INST_SW) is not validated, then the tag TAG_INST_S W is not valid. When the instance of named software (NAME_SW, SW) obtained in step 250 is found in step 253 to be associated with an invalid tag TAG_INST_SW obtained in step 251, the instance of software is rejected in step 30 254. WO 00/72119 PCT/USOO/11821 -66If the tag TAG_INST_SW is an unsigned tag, step 257 invokes a part of the supervising program (SP) 209 to verify the hash values for the hash function value HASH_INST_SW that exists within the tag TAG_INST_SW by the same steps that were used above for the case of a signed tag. If the HASH_INST_SW value does 5 not properly evaluate, then there is an error in the tag TAG_INST_SW and the instance of named software (NAME_SW, SW) obtained in step 250 that is associated with the invalid tag TAG_INST_SW is rejected in step 254. Rejection in step 254 can simply mean that the user device 104 discards or removes or does not allow use of the instance of software INST_SW and its 10 associated tag TAG_INST_SW that were obtained in steps 250 and 251. Step 256 can also be executed which activates a user device (e.g., 104) punitive action. Punitive action for a user device 104 may include shutting down or disabling the device for future use. Punitive actions will be discussed in more detail with respect to usage supervision features of this invention. 15 If the hash function values and the signature SIGN_TS(HASH_INST_SW) are verified in step 253 for a signed tag, or if the hash function value HASH_INST_SW is verified in step 257 for an unsigned tag, then step 255 stores the instance of software INST_SW (111 -114 in Figure 2) associated with the tag onto the user storage device 200, and also stores the associated tag TAG_INST_SW 20 for the instance of software (e.g., Ill) into the tag table 210 with the status INSTALLED attached to the tag (in column one of the table 210 illustrated in detail in Figure 6, as will explained more completely later). In an alternative embodiment in which a tag contains a supervising program identifier ID(SP) 209-A, the supervising program 209 verifies that the supervising 25 program identifier 209-A in the tag 120 is the same as the supervising program identifier 209-A stored on the user device 104. In an alternative embodiment in which a tag 120 contains a fingerprint list based on specified locations on the software content SW, the supervising program 209 verifies that the fingerprint list matches the fingerprints computed at the same specified locations in the software 30 SW, where matching is based on the same-location fingerprinting, as described in the definitions above and as explained in detail herein. WO 00/72119 PCT/USOO/11821 -67Figure 6 illustrates the contents of an example tag table 210. Generally, the tag table 210 includes information required by the supervising program (SP) 209 to make a determination of whether or not a user 213 of the user device 104 or the device 104 itself is allowed usage of an instance of software 111-114. Through a 5 process which will be explained shortly, the supervising program 209 can detect the attempted use of an instance of software 111-114 and can check information maintained in the tag table 210 to determine usage supervision characteristics for a tag TAG_INST_SW associated with the requested instance 111-114. Periodically, the supervising program (SP) 209 will perform a call-up 10 procedure which interfaces the user device 104 with the guardian center 103 (Figure 2). During the call-up procedure, tag information in the tag table 210 for each instance of software 111-114 installed on a user device 104 which is performing the call-up is verified by the guardian center's 103 (Figure 2) verification program (Figure 9, 315) so as to instruct the supervising program 209 on the user device 104 15 to make usage supervision determinations with respect to the instance of software 111 for which the user 213 is requesting use. Figure 6 shows a device's (i.e., 104) tag table 210 in a preferred embodiment of the invention. Each valid tag TAG_INST_SW 120 obtained via Step 251 in Figure 5 for each installed instance of software 111-114 is stored in the first column 20 labeled TAGS in the tag table-210. The tags in the TAGS column in tag table 210 are labeled TAGJNST_SW1, TAG_INST_SW2, TAG_INST_SW3, TAG_INST_SW4 and UNTAGGED_SW. Other information in the tag table 210, which will be described in more detail, includes, for each tag, a USAGE STATUS list (Column 2), an ACTION TIME (Column 3), a RUN COUNT (Column 4), and a 25 USE TIME (Column 5). The supervising program (SP) 209 uses the tag table information for each tag entry (i.e. each tag table row) to determine how to process a request for use of each instance of software 111-114 associated with a respective tag TAG_INST_SW. Briefly, the USAGE STATUS column in tag table 210 generally indicates to 30 the supervising program 209 whether an instance of software 111 -114 is usable or not for a user 213 or a device 104-107. If use of software is to be allowed, the status WO 00/72119 PCT/USOO/11821 -68column will indicate CONTINUED or INSTALLED, while if use is to be denied, this condition is indicated by the term GCJDISABLED. INSTALLED followed by REMOVED status terms indicate that a tag TAG_INST_SWn for an instance of software 111-114 was formerly installed on the user device 104 but is no 5 longer installed and consequently is not usable. The ACTION TIME column indicates a time stamp (e.g., Day and Time) of the last status determination (e.g., the time ofthe last call-up and tag verification procedure - to be explained) performed by the supervising program (SP) 209 (Figure 2). The RUN COUNT column in tag table 210 indicates the number of times an instance of software 111-114 associated 10 with a tag TAG_INST_SWn (where n is a number 1 through 4 in this example) has been used on a user device 104-107. Finally, the USE TIME column in tag table 210 indicates the total elapsed time during which the instance of software 111-114 associated with TAG_INST_SWn has been used since the last call-up procedure between the device and the guardian center or, in another embodiment, since being 15 installed. The various fields (i.e., rows) associated with each tag (Column 1) are used by the system of this invention for various purposes explained herein. Tags serve to identify the row of the tag table 210 that the supervising program (SP) 209 must examine to determine whether a given software instance 111-114 can be properly or 20 validly used, based on the content of that associated row. The current USAGE STATUS field of the chosen row determines whether use of the software instance (i.e., one of 111 -114 in this example) is allowed. As will be explained, when use is allowed, the supervising program (SP) 209 can track use times and run counts for the instance 111-114 being used. This 25 information can be used to construct the event history of a user device 104-107, and can also serve other purposes such as tracking use on pay-per-use or pay-per-view instance of software 111-114. The event history is a timed record of all attempted uses, successful uses, duration of uses, and other events such as power-ups at a device. It is unlikely for two devices to have the same event history, even if they 30 have the same software instances and the same identifiers. WOOO/72119 PCT/USOO/11821 -69In one embodiment, no two devices have the same software instances and the same tag or supervising program or device identifiers However, knowledgeable software pirates may attempt to exactly copy the disk image of one device to another, in which case tag, device, and supervising program identifiers might be 5 exactly duplicated. The invention contemplates avoidance of such piracy in certain embodiments by allowing at least one of the unique identifiers (i.e., one of either a software tag 120 or a supervising program identifier 209-A) to contain information such as a hardware processor identification number (i.e., processor serial number for example) which associates that identifier (e.g., tag 120 (Column 1 in Figure 6), SP 10 ED209-A, of device ID) with a particular processor or hardware chassis. That is, if a pirate attempts to circumvent the usage supervision! protection of the invention by duplicating the entire disk information and transferring the duplicated disk to another device, the invention can allow hardware device identification mechanisms to be incorporated into tag information and during tag validation (i.e. during call-up 15 processing - to be explained), the hardware identification information can be checked accordingly. It should be understood that this embodiment supplements the invention mechanisms which uses device usage statistics maintained at the guardian center 103 (Figure 2) to track two devices trying to use the same tag information. That is, if a 20 pirate copies a disk from a legitimate device 104 into another device (i.e. 107), it is almost impossible, according to the aspects of this invention, for the illegitimate user 213 of the pirated device 107 to use the device 107 in such a manner that exactly duplicates the use of the legitimate device 104. As such, when each device 104, 107 performs a call-up to the guardian center 103 (Figure 2) to perform tag validation, 25 the guardian center 103 (Figure 2) will detect one of either device 104,107 as having inconsistent usage or call-up statistics, with respect to the other device (i.e. the other of 104, 107). Thus, once each device 104,107 has made a call-up, one of the devices 104, 107 will appear as fraudulently attempting software use. At that point, the system of the invention can perform punitive action contained in a 30 continuation message (to be explained shortly) to disable one or both devices, the software on the devices, use of the devices, or any combination thereof. Reporting WO 00/72119 PCT/USOO/11821 -70illegal or illegitimate use to the proper authorities (e.g., law enforcement, software vendors) can also be performed by the invention. As an example of pay-per-use or pay-per-view, each time an instance of pay-per-use software 111-114 is used, the supervising program (SP) 209 can record 5 this in the RUN COUNT field (Column 4) in the tag table 210 for the tag TAG_INST_SW associated with that instance 111-114. RUN COUNT information can later be used for billing purposes. Also included in the tag table 210 is a header field HEADER_TAG_TABLE which uniquely identifies this particular tag table 210 for this particular user device 10 104. The header HEADER_TAG_TABLE may be unique on either a per user 213 or per user device 104 basis. If tag tables 210 are unique on a per user 213 basis, each user account (i.e., login account) on a user device 104 can have its own tag table 210 for that user 213. The per user tag table 210 can maintain the tags TAG_INST_SW for instances of software 111-114 to be used that may, for 15 example, have been purchased by that user 213 only. In other words, while only one tag table 210 is illustrated, the invention may track tag use and usage supervision for many users 213, or each user may have a separate tag table 210. The HEADER_TAG_TABLE preferably includes an ID_TAG_TABLE field which indicates a unique identification for this tag table 210. The ID_TAG_TABLE 20 field preferably includes an identification of the supervising program's 209 ID(SP) 209-A. In addition, it may include the identification of the user 213 ID(USER) with which this tag table 210 is associated, as well as an identification of the user device 104 ID(DEVICE) (e.g., serial number or host-id as noted above), and an identification of the operating system 207 ID(OS). 25 An example of the user identification ID(USER) may be a username and/or password combination. An example of the identification of the user device ID(DEVICE) may include the hostname, host id, IP address, serial number or other hardware or device specific information that can uniquely distinguish this user device 104 from other user devices (e.g., 104-107 in Figure 1). 30 ID(SP) 209-A may be, for example, comprised of information having to do with the time when a device 104-107 is first powered on based on a high precision WO 00/72119 PCT/USOO/11821 -71clock (205 in Figure 4). Two ID(SP)'s 209-A from different devices (i.e., 104, 105) will rarely be equal if the high precision clocks 205 are at microsecond accuracy. To reduce the risk of equal ID(SP)'s the ID(SP) 209-A may also include a hardware serial number if available and a number from a guardian center 103 (Figure 2) if 5 available. It is possible for a would-be pirate to copy the disk image in which case two devices might have the same ID(SP). As briefly noted above and as will be discussed further, this can be caught by the guardian center 103 (Figure 2) during call-up. The operating system 207 may also have unique identification information such as serial numbers or the like which can be used for identification in the 10 ID_TAG_TABLE field. The header field HEADER_TAG_TABLE (top row of tag table 210 in Figure 6) also includes a last guardian center continuation message field LAST_GC_CM, a last call-up time field LAST_CALLUP_TIME, and a number of device power-ups field NUMBER_DEVICE_POWERUPS. In addition, the 15 header includes two fields having to do with the event history: the current event history: HASH (EVENT_HISTORY) and the hash of the event history as of the most recent call -up HASH(EVENT_HISTORY_AS_OF_MOST_RECENT_CALLUP)). The LAST_GC_CM field in the header (row 1 of table 210) contains a 20 continuation message value which is an unforgeable message from the guardian center (GC) 103 (Figure 2) that contains an encoding of tag table 210 update information as well as actions and punitive actions specified by the GC 103 (Figure 2) for the user device's supervising program SP. The LAST_CALLUP_T1ME iii the tag table 210 header is used, in combination with other tag table data, by the 25 supervising program 209 to determine when a next call-up to the GC 103 (Figure 2) may be required according to a CALL-UP_POLICY. The NUM_DEVICE_POWERUPS is used locally as part of the method to determine when a call-up is needed. The event history may include information such as when each software 3 0 instance 111 -114 on a device 104-107 is invoked and possib ly when external inputs to the user device 104-107 (i.e., user 213 interaction) occur. The purpose of the WO 00/72119 PCT/USOO/11821 -7210 event history is to characterize a device 104-107 based on its past behavior or use of the device. This may be useful because static information such as supervising program identifiers 209-A and tags 120 may be copied from one device 104-107 to another, but dynamic information as embodied in the event history is likely to diverge even for devices 104-107 having the same static information. Since the event history can be large, a hash function value of the event history is maintained instead of the event history itself. Preferably, two event history hash function values are retained in order to allow processing to continue during a call-up procedure. As will be explained, a continuation message CM (Figure 2, 212;Figure 13B, 423) is preferably also stored in the LAST_GC_CM field of the tag table header (top row of table 210 in Figure 6). The CM 212 is a message prepared by the guardian center 103 (Figure 2) during a call-up procedure with the user device 104 and is preferably securely transmitted by the guardian center 103 (Figure 2) to the device 104-107 performing the call-up. A continuation message CM 212 includes information so that the supervising program (SP) 209 on the user device 104 can determine which instances of software 111-114 are allowed to continue to be used or should be disabled because of improper use, and can also define other actions or punitive actions to be executed by the device's supervising program 209. The LAST_CALLUP_TIME field contains a time stamp of the last call-up process (to be-explained) that occurred, and the NUM_DEV1CE_POWERUPS field contains the number of times that the user device 104 has been powered up. As will be explained, the supervising program (SP) 209 in each user device 104 is responsible for maintaining (though not necessarily generating) accurate information in the tag table 210, including header information such as NUM_DEVICE_POWERUPS, LAST_CALLUP_TIME, and the LAST_GC_CM continuation message. That is, a continuation message (CM) 212 (Figure 2) is generated by the guardian center 103 (Figure 2) and securely passed to the supervising program (SP) 209 on a user device 104. Upon receipt, the supervising program (SP) 209 is preferably responsible for parsing the continuation message (CM) 212 (Figure 2) and updating the tag table 210 with the most recent usage supervision information (i.e., updating tag table fields). WOOO/72119 PCT/USOO/11821 -73The information in the header field HEADER_TAG_TABLE can uniquely identify the tag table 210 and can be used by the supervising program (SP) 209 to update usage supervision information for each instance of software 111-114 installed on the user device 104. The idea is that the tag table 210 for each user or 5 each user and/or user device 104 combination is uniquely identifiable via HEADER_TAG_TABLE from other tag tables 210 for other users 213 or other user devices 104 or user/user device combinations. When a new instance of software 111-114 and its associated tag 120 are obtained and installed or used via the steps in Figure 5, the tag table 210 entry (i.e., 10 the row in tag table 210) for that tag TAG_INST_SWn has the ACTION column value set to INSTALLED to indicate the instance of software 111-114 associated with that tag is newly added or installed on that user device 104. The ACTION TIME value is either left blank or indicates the time of installation. The RUN COUNT and USE TIME column values are set to zero or 0 or are left blank. 15 According to another aspect of the invention, usage supervision can be provided for software instances 111-114 which do not have an associated tag TAG_INST_SW (Column 1) created for insertion in the tag table 210. Any such instance 111-114 is referred to as an untagged instance of software or simply as untagged software. An example of untagged software would be user 213 created 20 software. User created software may be legitimately created, as in the case of a user 213 writing or creating a software program or a song. User created software may also be illegitimately created, in which case it is referred to as infringing software INF_SW. It is desirable to allow a user device 104-107 to use legitimate untagged software and the invention's usage supervision enables such use. However, at the 25 same time, according to the mechanisms of the invention, the present invention can detect and prevent use, as well as, if so desired, enact punitive actions on a user device 104-107, if that device attempts to use infringing software that is either tagged or untagged. Infringing software INF_SW might, for example, be created as follows. A 30 pirating vendor may create instances of pirated software by taking a legitimate specific software instance 111-114, such as a book or an application program on a WO 00/72119 PCT/USOO/11821 -74CD-ROM and, and removing from the included installation program for that software all references to any required tag 120. The pirating vendor might then sells copies of the changed software (i.e., that no longer requires reference to an associated tag) under a different name as untagged software. Another example of 5 taggless software is infringing software created by a pirate as a modified or derived version of a legitimate vendor's software SW, such as for example, an unauthorized translation of a vendor's book into another language or a recompiled version of an application program. The system of the invention prevents, tracks, and protects against the used of such unauthorized software on user devices 104-107. 10 To do so, the invention introduces a concept called fingerprinting. Essentially, fingerprinting produces values associated with an instance of software which are unique to the content of the software (SW) for that instance. If fingerprints of an illegally made copy of an instance of software can be obtained, the invention provides a way to detect other attempts by other user devices 104-107 to 15 use similar illegally made copies. According to the invention, fingerprints associated with a particular piece of software are preferably when a user 213 attempts to install or use untagged software on the user device 104. Figure 7 illustrates the process of installing untagged software on a user device (in this example, user device 104 will be used in the discussion);- In step 330, 20 the user 213 installs (or creates) an instance of untagged software (i.e., an untagged instance of 111 -114) on the user device 104. The untagged software UNTAGGED_SW may , for example, appear simply as a string of binary data (STRING[0...N]) and initially has no associated tag. Upon an attempt to use the untagged instance 111-114, in step 331, the supervising program (SP) 209 detects 25 that no tag TAG_INST_SW exists in the tag table 210 for this instance of software and thus the supervising program (SP) 209 fingerprints the untagged software instance 111-114 using a fingerprint function FP. The fingerprint function may, for example, be a hash function. In step 331, each fingerprint Xi is equal to the value produced by the 30 fingerprint function FP which preferably operates on a portion of the untagged software STRING[i,i+k-l], where 0<=i<=m-k+l for a fixed standard k. There can WO 00/72119 PCT/USOO/11821 -75be m chosen indexes. In other words, a fingerprint function FP is performed on selected segments of the untagged software data STRING[0...N], where N is the total length of the untagged software in bits. Preferably, the fingerprint function FP produces a number of fingerprints (m), each offset from the next. In step 332, the 5 supervising program (SP) 209 stores the fingerprints Xil through Xim in the fingerprint table 210 of the user device 104. In an alternative embodiment, fingerprints are created based on non-consecutive portions of the untagged software. In another alternative embodiment, fingerprints are computed when software 10 is used, based on the behavior of the software. An example of behavior may be the sequence of system calls the software makes. Game software for example may have specific patterns for writing to the screen. These patterns may be incorporated into the fingerprint of the instance of software. Finally, in step 337, the supervising program (SP) 209 creates an untagged 15 tag entry UNTAGGED_SW in the tag table 210 to indicate the presence of an untagged instance Of software 111-114 on the user device 104. The UNTAGGED_SW tag in tag table 210 can use a hash function or other means to uniquely associate the tag UNTAGGEDJSW with the untagged instance of software which wasfingerprinted. Using the above described process, any attempt to use or 20 install an untagged instance of software 111-114 on a user device 104 results in that untagged instance being fingerprinted and also results in an UNTAGGED_SW tag being created in the tag table 210. As will be explained later, the fingerprint table 126 will be used by the guardian center 103 (Figure 2) to detect uses of infringing software INF_SW of 25 which the guardian center 103 (Figure 2) has been made aware. Details of the use of the fingerprint aspect of this invention will be discussed in more detail later. Figure 8 shows the high level steps performed by the system 109 of this invention when a user 213 attempts to use an instance of software (INST_SW) 111-114 on a user device 104. In step 270, the user 213 interfaces with the user 30 input/output mechanism 204 on the user device 104 to use an instance of the software 111-114. In step 271, the supervising program (SP) 209 intercepts the call WO 00/72119 PCT/USOO/11821 -76to invoke use of the instance of software 111-114. At this point, the supervising program (SP) 209 will ensure that the instance of software 111-114 requested has a tag TAG_INST_SW that indicates a CONTINUED status in the tag table 210. However, before checking the individual tag TAG_INST_SWn, in a preferred 5 embodiment, the supervising program (SP) 209 ensures that the tag table 210 itself is in a valid or updated state. By valid state, what is meant is that the tag table 210 is not outdated and in need of a call-up procedure to update its contents. Accordingly, in step 272, the supervising program (SP) 209 accesses the tag table 210 to determine if a call-up to the guardian center 103 (Figure 2) is required at the current 10 time. In an alternative embodiment, if a fingerprint is included in the tag, the supervising program SP 209 may check that the software instance being used is properly associated with this tag by using a same location fingerprint. Periodically, a call-up process is performed by the system of the invention to 15 effectively re-authenticate the validity and enforce the usage supervision policy of each tag TAG_INST_SWn in the tag table 210. The call-up process takes place between the guardian center 103 (Figure 2) and the user device(s) 104. There may be many triggering events that can cause a call-up to be made to the guardian center 103 (Figure 2). 20 For example, the call-up determinatiomnade in step 272 by the supervising program (SP) 209 can be made by examining the LAST_CALL-UP_TIME field in the tag table header HEADER_TAG__TABLE. If the time stamp in LAST_CALL-UP_TIME has exceeded a certain elapsed time, then a call-up to the guardian center 103 (Figure 2) is needed and is made by proceeding to step 273 25 where call-up processing is performed. Alternatively, there may be a call-up policy (CALL-UP_POLICY) for the tag table 210 itself which defines a set of rules or conditions that must be met in order for a call-up to be required. In other embodiments, there may be call-up policies (CALL-UP_POLICY_SW) associated with individual instances of software 30 111-114. In this case, step 272 can examine the rules or tests of the call-up policy (CALL-UP_POLICY_SW) associated with the software content SW or the instance WO 00/72119 PCT/USOO/11821 -77of software (INST_SW) 111-114 that was requested access by a user 213 in step 270. In another embodiment, if the user 213 of a user device 104 attempts to use an untagged instance of software, step 272 may mandate that a call-up is needed. In another embodiment, if the user 213 of a user device 104 uses tagged software for 5 the first time, then step 272 may mandate that a call-up is needed. In another embodiment, the maximum allowed interval between successive call-up procedures is preferably determined by a combination of elapsed time in a user device 104, the number and duration of uses to instances of software 111-114, the number of times the device 104 is powered on, and/or by any other measure that is related to time or 10 use of the device 104. Call-up processing will be discussed in more detail later. Essentially however, during call-up processing, the supervising program (SP) 209 in a user device 104 securely transfers a copy of the tag table 210 and the fingerprint table 126 to the guardian center 103 (Figure 2). After verification, the guardian center 15 103 (Figure 2) compares each tag TAG_INST_SWn in the tag table 210 against a list of compromised tags. The guardian center 103 (Figure 2) can detect tags that are invalid or compromised in some manner. A usage supervision policy POLICY(TAG_INST_SW) associated with each tag can also be checked at the guardian center Γ03 (Figure 2) to ensure that tags 120 20 ( and therefore instances of software associated with the tags) are being used in compliance with the usage supervision policy POLICY(TAG_INST_SW). The policy may be for an entire user device 104-107 or on a per user 213 or per tag 120 basis. Also, for untagged software, the fingerprint table 126 can be compared against a fingerprint data structure (explained later) in the guardian center 103 25 (Figure 2) to detect uses of infringing software INFJSW. After analysis of the tag table 210 and fingerprint table 126 are complete, the guardian center 103 (Figure 2) prepares and sends a continuation message (CM) 212 (Figure 2) back to the user device 104. In an alternate embodiment, tagged software may also be checked by 30 fingerprinting. This embodiment prevents a pirating vendor from distributing instances of specific software that is infringing on intellectual property or other WO 00/72119 PCT/USOO/11821 -78rights of a legitimate vendor (i.e., 101), as tagged software, i.e. accompanied by legitimate tags obtained from a tag server 102. In this embodiment the user device's 104-107 supervising program 209 performs a fingerprinting process on tagged software instances 111-114 as well, and stores the computed fingerprints in its 5 fingerprint table 126. During a call-up procedure, the fingerprints obtained from tagged software instances 111-114 used on the user device 104-107 will also be sent to the guardian center 103 (Figure 2) to detect use of infringing software. The continuation message (CM) 212 (Figure 2) contains various information that can affect the operation of instances of software 111-114 on a user device (e.g., 10 104), or operation of the user device 104 itself. For example, if the guardian center 103 (Figure 2) detects an invalid tag TAG_INST_SWn in a tag table 210 for a user device 104, the continuation message (CM) 212 returned to that user device 104 may cause the user device 104 to become inactivated or disabled for a specified period of time or indefinitely. Alternatively, the continuation message (CM) 212 15 may cause the user device 104 to inactivate use of the particular instance of software (INST_SW) 111-114 associated with an invalid tag 120. The action(s) taken at a user device 104 are defined in an ACTIONS portion of the continuation message (CM) 212, and will be described in more detail later. The continuation message 212 is also used by the supervising program (SP) 209 in 20 the user device 104 to update-information in the tag table 210. For example, the ACTION TIME column of that tag table 210 may be updated with a time stamp of the most recent continuation message (CM) 212, thus providing an indication of when each tag TAG_INST_SWn was most recently checked by the guardian center 103 (Figure 2). 25 Continuing with the description of the processing in Figure 8, after call-up processing is complete in step 273, the tag table 210 is updated on the user device 104 in step 277 (i.e., via the continuation message 212), and processing returns to step 272. Once the user device 104 determines that a call-up to the guardian center 103 (Figure 2) is not required at this time, processing proceeds to step 274 to 30 determine the usage status of the particular instance of software 111-114 for which use was requested by a user 213 in step 270. WO 00/72119 PCT/USOO/11821 -79In step 274, the supervising program (SP) 209 in the user device 104 essentially examines the USAGE STATUS column in the tag table 210 for the tag TAG_INST_SWn associated with the requested instance of software 111-114. If the USAGE STATUS column indicates CONTINUED, then the supervising program 5 (SP) 209 signals to the kernel 208 of the operating system 207 to allow use of the requested instance of software 111 -114 in step 275. If the USAGE STATUS column in the tag table 210 for the tag (TAG_INST_SWn) associated with the requested instance of software 111-114 indicates GC_DISABLED or REMOVED, then the supervising program 209 denies use of the instance of 10 software 111-114 in step 276. If use is allowed to the requested instance of software 111-114, the supervising program (SP) 209 increments by one the value in the RUN COUNT column for the tag TAG_INST_SWn associated with the requested instance of software 111-114. The supervising program (SP) 209 also tracks the amount of time 15 that the requested instance of software lll-114isinuse and updates the USE TIME column for the tag accordingly. Figure 9 illustrates a preferred embodiment of the architecture of the guardian center 103 (Figure 2). The guardian center 103 (Figure 2) includes a-bus 306 which couples a processor 301, a memory 302, an interconnection mechanism 20 303, a clock 304 and a guardian center authorization database 300. The guardian center 103 (Figure 2) is preferably a high-powered computer system such as a multi-processor server which can perform many transactions for multiple processes at one time. The interconnection mechanism 303 is, for example, a modem bank or one or more high bandwidth network connections allowing the guardian center 103 25 (Figure 2) to communicate with many user devices 104 simultaneously via communication network 100. The guardian center's 103 (Figure 2) authorization database (GCDB) 300 is preferably a large database sub-system or disk or RAID array having the capability to store vast amounts of information. In this embodiment, the GCDB includes a 30 tagged software database 138 (Figure 9) which holds data for instances of tagged software, and a fingerprint data structure 137. The tagged software database 138 WO 00/72119 PCT/USOO/11821 -80(Figure 9) includes call-up records (Figure 10, 320, 321) for each tagged instance of software on each user device 104. The content and use of each of these databases 137 and 138 (Figure 9) will be explained in more detail shortly. During operation of the guardian center 103 (Figure 2), memory 302 is used 5 to store a verification program (VRP) 315 which executes in conjunction with processor 301 to perform the guardian center functions described herein. Memory 302 also stores user device tag tables 210 and fingerprint tables 126 which get transferred to the guardian center 103 (Figure 2) for tag verification and usage supervision determination during the call-up procedure explained briefly above. 10 Figure 10 shows the data structures 320, 321 maintained in the tagged software database 138 (Figure 9) in the guardian center 103 (Figure 2) for each instance of tagged software (e.g., 111-114). The tag data structure 320 is initially provided to the guardian center 103 (Figure 2) from the tag server 102 upon creation of tags 120 for each instance of software 111-114. Preferably, the manner in which 15 the tags 120 are provided to the guardian center 103 (Figure 2) from the tag server 102 is via electronic and secure distribution over the communication network 100. Alternatively, software vendors 101 can be responsible for ensuring that the guardian center 103 (Figure 2) is kept aware of tag information for each instance of software 111-114 that is distributed to user devices 104-107. 20 A tag data structure 320 exists in the tagged software database 138 (Figure d) for each instance of software that is used on a user device 104. As illustrated, each tag data structure 320 includes various fields. These fields include the tag for that instance of software TAG_INST_SW, the usage supervision policy POLICY(TAG_INST_SW) for that software, and a list of references to one or more 25 call-up records CALL-UP_RECORDn 321 for that instance of software. The policy POLICY(TAG_INST_SW) associated with a tag TAG_INST_SWn for an instance of software 111-114 is prescribed by the software vendor 101 or another organization and defines the rules and policies with respect to the protection of usage rights or pay-per-use access limitations for the instance of 30 software associated with that tag. For example, for a tag data structure 320 associated with a specific instance of software 111-114, the WO 00/72119 PCT/USOO/11821 -81POLICY(TAG_INST_SW) data may include a rule stating that for each use to the instance of software, the user device 104 must pay a prescribed fee. During call-up processing (to be explained shortly), when the guardian center 103 (Figure 2) receives the tag table 210 from a user device 104, the number of 5 times a particular instance of software 111-114 has been used by that user device 104 can be determined from the RUN COUNT column ofthe tag TAG_INST_SWn associated with the tag TAG__ENST_SWn for that instance of software in the tag table 210. Tbe guardian center 103 (Figure 2) can then look to the policy POLICY(TAG_INST_SW) for the tag data structure 320 associated with that tag 10 TAGJNST_SWn in the tagged software database 138 (Figure 9). The guardian center 103 (Figure 2) can determine if the number of uses as indicated by the RUN COUNT field in the tag table 210 is greater than a previous number obtained from a former call-up process. If the number is greater, the guardian center 103 (Figure 2) can record this information for billing purposes to be sent to the owner or user 213 15 ofthe user device 104. Other usage supervision policies POLICY(TAG_INST_SW) may be defined to cause the guardian center 103 (Figure 2) to allow only a certain number of uses to a particular instance of software 111-114. When the number of uses is exceeded, the guardian center 103 (Figure 2) can cause the USAGE STATUS field associated in 20 the user device's tag table-210 with the tag associated with the above instance of software, to be set to the value GCJDISABLED. The change is effected at the user device 104 by specifying the appropriate information in the continuation message (CM) 212 sent from the guardian center 103 (Figure 2) to that user device 104 after analysis of tag table 210. When the user device 104 attempts to use the instance of 25 software 111-114 associated with the tag TAG_INST_SWn that is disabled (i.e., TAG_INST_SW3 in Tag Table 210 in Figure 6), use will be denied as explained above in Figure 7. Each tag data structure 320 in the tagged software database 138 (Figure 9) within the guardian center 103 (Figure 2) includes a number of references to call-up 30 records CALL-UP_RECORDn 321 as shown in Figure 10. A call-up record CALL-UP JLECORDn 321 includes a call-up time CALL-UP JTIME, the header WO 00/72119 PCT/USOO/11821 -82field HEADER TAG_TABLE from the tag table 210 of the calling user device 104, an optional hash function value of the tag table 210 HASH(TAG_TABLE), and an ACTIONS field. Thus, there is one CALL-UP RECORD per call-up, regardless of the number of tags sent. 5 The CALL-UP_TIME field indicates the time-stamp of the call-up for the current CALL-UP_R£CORDn. The HEADER_TAG_TABLE contains the tag table header of the tag table 210 that contains the TAG_INST_SWn for this tag data structure 320 as received from the calling user device 104 during the call-up procedure n. The HASH(TAG_TABLE) field contains an unaliasable hash function 10 value computed on all of the data in the tag table 210 which included the tag TAG_INST_SWn associated with the tag data structure 320. Finally, the ACTIONS field lists the actions prescribed by the guardian center during the call-up procedure n, to be performed for the instance of software 111-114 that is associated with a tag TAG_INST_SW for the tag data structure 320. Using the tag data structures 320 15 for each instance of software 111-114, the guardian center 103 (Figure 2) can maintain detailed information related to usage supervision mechanisms for instances of software 111-114 used via user device(s) 104. Figure 11 shows the processing steps which result in the creation of the fingerprint data structure 137 maintained within the guardian center 103 (Figure 2). 20 As previously noted and explained with respect to Figure 7, fingerprints are created and stored in a fingerprint table 126 within each user device 104 when untagged software, and possibly also tagged software, is first used on the user device 104. According to this invention, software pirates may infringe upon legitimate vendor rights by either copying vendor software and removing the part of the software that 25 requests confirmation of a tag or by creating and distributing derivatives of legitimate software. The software thus produced is called infringing software INF_SW. The fingerprint data structure 137 created within the guardian center 103 (Figure 2) will contain fingerprints computed on an infringing instances of software INF_SW. 30 In Figure 11, in step 340, the software vendor 101 detects the existence of an instance of infringing software (INF_SW). In step 341, the software vendor 101 WO 00/72119 PCT/USOO/11821 -83submits a copy of the instance of infringing software INF_SW to the guardian center 103 (Figure 2). The infringing software is merely a string of binary digits (bits) appearing as STRING_INF[0...N], In step 342, the guardian center computes a collection of fingerprints Yi on the instance of infringing software, using the same 5 fingerprint formula FP as the supervising program(s) (SP) 209 on each of the user device(s) 104 use to compute fingerprints. That is, a series of fingerprints Yi are computed as follows: Yi= FP(STRING_INF[i,i+k-l]) where 0<=i<=n-k+l, with n-k being the number of fingerprints to compute. Then, in 10 step 343, the guardian center 103 (Figure 2) incorporates each of the computed fingerprints Yl,...Yn-k+l into the fingerprint data structure 137 in the GCDB 300. In an alternative embodiment, fingerprints are computed on non-consecutive sequences of STRING_INF, those sequences being unique or nearly unique to INT_SW. 15 The fingerprint process is then complete at the guardian center 103 (Figure
  2. 2
    2) and the infringing software INF_SW can be discarded or can be made available to other guardian centers 103 (Figure 2) elsewhere on this or another communication network 100. At this point, when the supervising program (SP) 209 on a user device 104 20 detects a request to use an untagged (and possibly infringing) instance of software UNTAGGED_SW 111-114, the supervising program (SP) 209 records fingerprints of UNTAGGED_SW. Later when the SP 209 performs a call-up procedure to transfer the tag table 210 and the fingerprint table 126 to the guardian center 103 (Figure 2), the recorded fingerprints of UNTAGGED_SW will be sent. In one 25 embodiment, an access request on a user device 104-107 to use the untagged instance may cause the call-up to occur. Using general-location fingerprinting, the fingerprints in the fingerprint table 126 can be compared to the fingerprints in the fingerprint data structure 137 at the guardian center 103 (Figure 2). If the software instance UNTAGGED_SW is a copy of an infringing software instance INF_SW WO 00/72119 PCT/USOO/11821 -84that the guardian center 103 (Figure 2) has been made aware of and has fingerprinted on its own, this will be detected and punitive action can be carried out on the user device 104 via return of a continuation message 212. In another embodiment, the system-call behavior (i.e. the sequence of system calls) of UNTAGGED_SW on 5 user device 104 is compared with the system call behavior expected of INF_SW on the guardian center 103 (Figure 2). In another embodiment, the steps detailed in the last two paragraphs are applied also in the case of a request on a user device for use of tagged software. Aside from the fingerprinting aspects of this invention, during a call-up 10 procedure to be explained next, the verification program 315 in the guardian center 103 (Figure 2) also reads and compares the information in the tag table 210 with information in the tag software database 138 (Figure 9) to make usage supervision decisions. Figure 12 illustrates the steps performed by the supervising program (SP) 15 209 executing on a user device 104 to perform a call-up procedure in a preferred embodiment of the invention. The steps in Figure 12 are performed within step 273 in Figure 8. In step 370 in Figure 12, the supervising program (SP) 209 calls up the guardian center 103 (Figure 2). By call-up, what is meant is that the supervising 20 program (SP) 209 on the user device 104 connects with or exchanges messages with the guardian center 103 (Figure 2) via communication network 100. In the preferred embodiment, the supervising program (SP) 209 sends the HEADER_TAG_TABLE to the Guardian Center 103 (Figure 2). The Guardian Center 103 (Figure 2) causes a call-up failure unless the previous continuation message consisting of the 25 ID_TAG_TABLE of the device, the time as of the last call-up LAST_CALLUP_TIME is equal to CALLUP_TIME of the most recently CALL_UP record having this same HEADER_TAG_TABLE. An advantage of this embodiment is that even if several devices 104-107 have the same ED_TAG_TABLE (Row 1 of tag table 210 in Figure 6) and the same tags 210 (an 30 occurrence that is normally due to piracy), those same devices may have received, but will not properly accept the same continuation message 212 for a reason to be WO 00/72119 PCT/USOO/11821 -85explained below, so only one device (i.e., one of 104-107) will send a particular HEADER_TAG_TABLE. A call-up is made in accordance with the CALL-UP_POLICY or CALL-UP_POLICY(TAG_INST_SW) as explained above in response to a user's 5 attempt to use an instance of software 111-114 on a user device 104-107. That is, when the user 213 attempts to use an instance of software 111-114 for which the time allowed before the next call-up according to the CALL-UP_POLICY of the user device 104 or the CALL-UP_POLICY(TAG_INST_SW) of the software (SW) for that instance has expired, the supervising program 209 on that device 104-107 10 initiates step 370. In another embodiment, the SP 209 executes a call-up procedure at a chosen time before the expiration time, regardless of whether a use of an instance of software 111-114 is requested. The CALL-UP_POLICY can be maintained within the supervising program 209 on the user device 104. In addition, it is possible that a call-up may occur because a portion of the supervising program 15 209, executing regardless of use requests, determines that it is time to perform a call-up. For example, it may take place as the result of a certain number of BOOTUPS (power-ups) of a user device 104-107 having taken place or the first use of untagged software. If the call-up to the guardian center 103 (Figure 2) in step'37 Hails, then 20 processing proceeds to step 376 where punitive action may be performed by the supervising program (SP) 209 on the user device 104. In the preferred embodiment, the supervising program (SP) 209 will perform a new call-up, retrying several times before beginning punitive action. In the case that punitive action is necessary in step 376, the punitive action may merely be to inform the user 213 that the instance of 25 software 111-114 that was requested is temporarily inaccessible due to a communications failure. If the call-up is successful and a connection is established to the guardian center 103 (Figure 2) from the user device 104, then in 372, the supervising program (SP) 209 preferably securely sends or transmits the tag table 210 from the user 30 device 104 to the guardian center 103 (Figure 2). In an alternative embodiment, the supervising program (SP) 209 also sends the fingerprint table 126 to the guardian WO 00/72119 PCT/USOO/11821 -86center 103 (Figure 2) as well. That is, the fingerprinting aspects of this invention may or may not be incorporated into an embodiment in order to detect the use of user created or user modified infringing software. After step 372 is complete, the supervising program (SP) 209 enters a wait 5 state until a continuation message (CM) 212 is sent and received from the guardian center 103 (Figure 2). Alternatively, the supervising program SP 209 may go into a sleep state after step 372 is complete and run again following an interrupt from the Operating System (OS) 207. In an alternative embodiment, the supervising program SP could continue to process requests from the user. Guardian center 103 (Figure 2) 10 call-up processing will be explained shortly with respect to Figures 13A and 13B. When the guardian center 103 (Figure 2) has completed its call-up procedure processing, a continuation message (CM) 212 is sent to the user device 104. In step 373, the supervising program (SP) 209 checks for the return of a continuation message 212 as defined in the call-up policy CALL-UP_POLICY of 15 the user device 104. As an example of checking for a continuation message (CM) 212 within the call-up policy CALL-UP_POLICY, step 373 may ensure that no more than a certain amount of elapsed time goes by before receiving the continuation message (CM) 212. If too much time elapses before receipt of a continuation message 212, the call-up policy may be violated. 20 Other factors can be used to determine if a call-up violation exists as well, such as the inability to validate a digital signature in the continuation message 212. Another factor determining a call-up violation is that the HASH(EVENT_HISTORY) field in the continuation message 212 is not the same as the hash of the event history recorded in the user device 104 as of the time of the 25 last call-up, HASH (EVENT_HISTORY_AS_OF_MOST_RECENT_CALLUP). This might arise if there are two devices 104-107 having the same configuration and ID_TAG_TABLE, due to piracy, but only one performs a call-up. Because of the event history, only one of the devices 104-107 would accept the continuation message 212. The other device would have to do its own call-up and this would lead 30 to a call-up failure because the HEADER_TAG_TABLE (Row one in Table 210 in WO 00/72119 PCT/USOO/11821 -87Figure 6) would match on ID_TAG_TABLE but would fail to match on call-up time, as explained above. If the CALL-UP_POLICY is violated in step 373, processing proceeds to step 376 and punitive action can be performed at the user device 104. In this case, 5 punitive action may include notifying the user 213 that a call-up cannot proceed and that the instance of software 111-114 requested must be temporarily denied access or disabled. Alternatively, the user device 104 can be deactivated for some time. If step 373 determines that a continuation message (CM) 212 is received and is acceptable as being within the limitations defined in CALL-UP_POLICY, in step 10 374, the continuation message (CM) 212 is passed to the supervising program (SP) 209. Then, in step 375 the supervising program (SP) 209 verifies the continuation message (CM) 212 via a digital key signature technique and executes each action in the continuation message 212 for each tag TAG_INST_SWn in the tag table 210 of the user device 104. That is, the supervising program (SP) 209 updates the USAGE 15 STATUS and ACTION TIME columns for each tag TAG_INST_SWn in the tag table 210. In this manner, the system 109 of the invention allows the user device 104 to periodically obtain tag table 210 updates from the guardian center 103 (Figure 2). Since the supervising program (SP) 209 serves as an interface between the 20 user 213 and the instances of installed software 111-114 rafa user device 104, the supervising program 209 implements the usage supervision mechanisms described herein preferably on the user device 104. By requiring the tag TAG_INST_SWn for an instance of software 111-114 to be in a CONTINUED usage status state, which can be changed only during call-up processing, usage supervision is ultimately 25 managed by one or more guardian centers 103 (Figure 2). The guardian center(s) 103 (Figure 2) are responsible for determining whether or not a tag in a tag table 210 for a user device 104 should be in a CONTINUED or GC_DISABLED state as per policies defined for tags and fingerprints. Figures 13A and 13B present one continuous flow chart that show the steps 30 performed by the verification program (λ/RP) 315 in the guardian center 103 (Figure 2) during call-up processing according to a preferred embodiment of the invention. WO 00/72119 PCT/USOO/11821 -88The guardian center 103 (Figure 2) is made aware of a call-up procedure when a user device 104 (i.e., supervising program 209) makes the initial call-up processing connection or contact with the guardian center 103 (Figure 2) in step 370 of Figure 12. In response thereto, in step 410 of Figure 13 A, the verification guardian center 5 103 (Figure 2) receives the tag table 210. The guardian center 103 (Figure 2) also receives the fingerprint table 126 from the user device 104 if there is any software on the user device 104 that is installed but not tagged with a tag TAG_INST_SWn in the tag table 210. Again, the fingerprint aspects of the invention are optional but are provided in a preferred embodiment of the invention, because they permit the 10 detection of infringing software. In an alternative embodiment, the guardian center 103 (Figure 2) may receive a portion ofthe tag table 210 only, such as, for example, the HEADER_TAG_TABLE and a portion of the tags (column 1) in the tab table 210. The tags 120 received can be those that the guardian center 103 (Figure 2) requests 15 or can be chosen at random or may be only the tags 120 that the user device needs for use of instances of software at that moment. Another possibility is that the tags 120 can correspond to those instances of software that are pay-per-use or have a fixed number of uses. The advantage of this alternative is that it reduces both the communication costs and the processing costs. 20 In another alternative embodiment, the guardian center 103 (Figure 2) receives the HEADER_TAG_TABLE (top row of tag table 210 in Figure 6) only. This embodiment makes guardian center call-ups inexpensive and can work well when each TAG_INST_SW includes an ED_TAG_TABLE field, as will be explained below. 25 Returning now to a description of call-up processing with respect to Figure 13 A, in step 411, the guardian center 103 (Figure 2) checks to ensure that the call-up is in accordance with the call-up policy CALL-UP_POLICY associated with the user device 104. Call-up policies CALL-UP_POLICY(s) for user devices 104-107 are preferably maintained at the guardian center 103 (Figure 2), and/or may be provided 30 from the software vendors 101 or user device manufacturers (not shown) from time WO 00/72119 PCT/USOO/11821 -89to time to instruct the guardian center 103 (Figure 2) how to determine how frequently a user device 104 must call up to verify and update its tag table 210. Step 411 can be performed using, for example, HEADER_TAG_TABLE information fields such as the unique identification of the tag table 210 contained in 5 the ID_TAG_TABLE field. If the call-up is not in accordance with the CALL-UP_POLICY, step 416 prepares specified punitive action(s) to be carried out by the supervising program (SP) 209 when the continuation message (CM) 212 is returned from the guardian center 103 (Figure 2) to the user device 104. Processing proceeds to step 412 from both steps 416 and 411, at which point 10 the verification program 315 verifies the signed and/or unsigned tags TAG_INST_SWn in the tag table 210. The verification performed in step 412 may be a digital signature verification for the signed tags TAG_INST_SW in the tag table 210. For the unsigned tags, the HASH_INST_SW value may be used to check that the secret number NUM_INST_SW within the tag TAG_INST_SW is consistent 15 with HASH_INST_SW for that tag. This is possible because HASH_INST_SW is a hash function value that is computed partly from NUM_INST_SW. In addition, NUM_INST_SW must be found in SPARSE_SET and must be associated with NAME_SW of TAGJNSTJSW. For each unverified tag TAG_INST_SWn detected in step 412, step 417 20 prepares a specified punitive action based on the usage supervision policy POLICY(TAGJNSTJSW) associated with the instance of software 111-114 for the unverified tag TAG_INST_SWn. Punitive action in this case may include instructions to disable the user device 104. Note that the punitive action specified in step 417 will be carried out after it is communicated to the user device 104. 25 Usage supervision policies POLICY(TAG_INST_SW) associated with instances of software 111-114 are maintained at the guardian center 103 (Figure 2), and may be provided from the software vendors 101 from time to time to instruct the guardian center 103 (Figure 2) how to handle usage supervision for the various instances of software 111-114 produced by the software vendors 101. That is, the 30 software vendors 101 can provide the instances of software 111-114 to 104-107 (for a fee for example). To enforce use restrictions on those instances 111-114, the WO 00/72119 PCT/USOO/11821 -90software vendors 101 can create the policies POLICY(TAG__INST_SW) for the instances 111-114 and can provide these policies to the guardian centers 103 (Figure 2). During call-up procedures, the guardian centers enforce or police the policies CALL_POLICY(TAG_INST_SW). As an alternative embodiment, the policy for 5 one instance of software (i.e. Ill) may differ from that for another instance (i.e. 112) of that same software, assuming 111 and 112 have the same software content SW. This enables the invention to enforce usage supervision, for example, differently for two users of the same program, since each instance has its own associated tag and call-up policies can be maintained on an instance by instance or 10 user by user basis. In any event, at the guardian center 103 (Figure 2), after each tag TAG_INST_SW in the tag table 210 is verified for authenticity (Step 412), or after punitive action is prepared for each unverified tag (Step 417), processing proceeds to step 413 where each verified tag TAG_INST_SWn in the tag table 210 is checked 15 against the tagged software database 138 (Figure 9). Essentially, step 413 checks that each tag TAG_INST_SWn in the tag table 210 associated with an instance of software 111-114 used on the user device 104 (i.e., the user device performing call-up processing) is being used in accordance with the usage supervision policy of the instance of software POLTCY(TAG_INST_SW). After each tag is tested in step 20 413, processing proceeds to step 414. The checking process performed in step 413 can be performed in a variety of ways. According to one embodiment, the tagged software database 138 (Figure 9) contains a list of associations between tags TAG_INST_SWn and supervising program identifiers (209-As) and the times that these associations were discovered. 25 In this embodiment, the verification program (VRP) 315 can compare the tags in the tag table 210 against the list of TAG_INST_SW-HEADER_TAG_TABLE-CALLUP_TIME associations to determine whether the same tag 120 (Column 1 in table 210) is on two devices 104-107. If a tag 120 is found associated with several HEADER_TAG_TABLEs, 30 punitive action can be prepared in step 418. WO 00/72119 PCT/USOO/11821 -91In a preferred embodiment of the invention, the guardian center's verification program VRP 315 employs the data structure (Figure 10, 320, 321) associated with a tag 120 TAG_INST_SW to check whether the instance of software 111-114 associated with that tag 120 was used on the calling user device 104 in accordance 5 with the usage supervision policy POLICY(TAG_INST_SW) specified for that instance of software 111-114. For example, if the usage supervision policy specifies that the same instance of software, (i.e. the same tag), must not be present on two different user devices, (e.g. 104 and 105), in a usable status (e.g., USAGE STATUS = CONTINUED) at the same time, the detailed data in the call-up records 321 for 10 the tag enables the VRP 315 to check whether the policy was violated. After each tag 120 TAG_INST_SWn in the tag table 210 has been checked by step 413, the tags 120 in tag table 210 may or may not have associated punitive action that has been specified in relation to those tags. If punitive action has been specified due to an improperly copied tag or a tag that is not used in accordance with 15 a usage supervision policy, processing proceeds to step 420 where the verification program VRP 315 in the guardian center 103 (Figure 2) prepares and sends the specified punitive action back to the user device 104 via a continuation message (CM) 212. Such a continuation message (CM) 212 is used to impose punitive action on a user device 104 and contains GCJDISABLED action values for the USAGE 20 STATUS fields of all tags TAG_INST_SWn in the tag table 210 that are in violation of the policy POLICY(TAG_INST_SW). Note that in the preferred embodiment, if at least one tag TAG_INST_SW violates the usage supervision policy POLICY(TAGJNSTJSW) or is found to exist in the compromised tag list in the tagged software database 138 (Figure 9) then 25 punitive action is specified in step 418 and is enacted in step 420 without further continued processing. In an alternative embodiment, punitive action can be specified for each compromised or policy-violating tag TAG_INST_SW in step 418 and processing may be directed to continue to step 414. As an alternative treatment of tagged software, the above tag processing can 30 occur on only a portion of the tag table. For example, processing may be done only on those tags for which the user device 104-107 (i.e. the supervising program 209 on WO 00/72119 PCT/USOO/11821 -92the user device) is requesting access (i.e., the instance(s) of software attempting to be used). In this case, the continuation message 212 would specify continued or punitive action only for instances of software associated with the tags that are processed at the guardian center 103 (Figure 2). 5 As another alternative embodiment, no tag processing at all need take place for software purchased for unlimited use, thus eliminating the activities associated with step 372 (Figure 12). Instead, only the HEADER_TAG_TABLE needs to be verified. In this case the HEADER_TAG_TABLE (top row in Figure 6) includes the ID_TAG_TABLE and event history (Figure 6). In this embodiment, each tag 10 120 includes an ID_TAG_TABLE in addition to HASH_S W, NAME_S W and NL5M_INST_SW. The ED_TAG_TABLE value may be written into the tag 120 (Column 1) at the time of purchase and should be an argument to the hash function in step 153 in Figures 3A, 3B, and 3C resulting in HASH_INST_SW. Since ID_TAG_TABLE includes ID(SP) 209-A and since ID(SP) 209-A is based on a 15 rarely duplicated value including, for example, the microsecond value time when the device 104 is first powered up, each ID_TAG_TABLE value should occur on only one physical device in the absence of piracy. Piracy, in the form of copying the disk image, may cause a single DD_TAG_TABLE value to occur on several physical devices (creating twins), but 20 the LAST_CALLUP_TIME fieldin the HEADER_TAG_TABLE of the device 104 and the CALLUP_T1ME in the CALLUPRECORD in the authentication database 138 (Figure 9) in the guardian center 103 (Figure 2) will fail to match at call-up time, and so the verification of HEADER_TAG_TABLE will fail. This will cause the guardian center 103 to take punitive action if two call-up messages are sent from 25 two identically configured devices 104-107. Further, the two of devices 104-107 cannot try to share the same call-up procedure, because their HE ADER_TAG_T ABLEs will differ due to the HASH (EVENT_HISTORY) field in each of their tag tables 210. Since that hash function value is sent in the continuation message 212, only one of the devices 104-107 will 30 be able to properly process that continuation message 212. In the case where two devices are acting in duplicate, the supervising program 209 is thus able to recognize WO 00/72119 PCT/USOO/11821 -93the attempted duplication and to take punitive action. Therefore, each ID_TAG_TABLE value can be on or associated with only one device 104-107 or a call-up failure will occur. When a tag includes ID_TAG_TABLE, the supervising program 209 on a device 104-107 will allow the instance of software 111-114 5 associated with that tag 120 to be used only if the ID_TAG_TABLE value in the tag 120 matches that on the proper device. As a result, each instance of software 111-114 will be used on only one device 104-107 and that device will have an ID_TAG_TABLE value that matches the ID_TAGITABLE value in the tag 120. In step 414, the verification program (VRP) 315 determines if any entries 10 exist in the tag table 210 for untagged instances of software. An untagged instance of software installed on a user device 104-107 is indicated in the tag table 210 by a special tag UNTAGGED_SW and the USAGE STATUS column for that untagged software is set to UNTAGGED. This UNTAGGED_SW tag entry is preferably created during the installation or first use of the user created software and the 15 fingerprinting process is preferably performed by the user device 104 upon first detection of untagged software as explained with respect to Figure 7. In Figure 13 A, if the verification program (VRP) 315 detects an untagged entry in the tag table 210 in step 414, step 415 is executed. The processing ofstep 415 obtains each fingerprint list from the fingerprint table 126 which was transferred 20 to the guardian center 103 in step 410. The fingerprint table 126 consists of a list of fingeiprints for each untagged instance of software. The verification program (VRP) 315 matches each fingerprint list Xi in the fingerprint table 126 against every fingerprint list Yj in the fingerprint data structure 137 in the GCDB 300 using general-location fingerprint checking, as explained above. If more than a specified 25 number of matches are found between fingerprint lists Xi and Yj, then the guardian center has detected the use of infringing software and processing proceeds to step 420 where punitive action is prepared and sent to the user device 104 that performed the call-up. The software vendor 101 who creates the non-infringing versions of the infringing software may also be notified. 30 It is computationally expensive to compare each list of fingerprints Xi against every fingerprint list in the guardian center and since this is the most WOOO/72119 PCT/USOO/11821 -94expensive operation in the call-up, one embodiment accomplishes this somewhat differently. In this embodiment, a fingerprint list called an Inverted Guardian Fingerprint Table is constructed which contains all of the fingerprints of all the infringing software, but without duplicate fingerprints. Using this Inverted Guardian 5 Fingerprint Table, the guardian center 103 examines each list Xi and determines how many fingerprints in this list match fingerprints in the Inverted Guardian Fingerprint Table (stored as fingerprint data structure 137). If more than a specified number of matches are found, then a detailed check is made of Xi against each Yj, to determine if a close match in the number of fingerprints occurs. If step 415 does 10 not detect any fingeiprint lists that match, step 419 is processed to determine if any punitive action has been defined from either of the earlier steps 411 or 412. If so, processing proceeds to step 420 as previously described. If no punitive action is defined in step 419, step 421 is processed. This step handles all tags TAG_INST_SWn that are known to the guardian center 103 to be 15 pay-per-use tags. That is, the guardian center 103 can maintain within the tagged software database 138 (Figure 9) a list of all instances of software 111-114 that are to be accounted for on a pay-per-use basis. Step 421 examines the tag table 210 for any such tags (Column 1) and upon detection of one or more pay-per-use tags, step 421 causes the guardian center to send accounting information (not shown) to the 20 software vendor 101 concerning the usage characteristics of that pay-per-view or pay-per-use instance 111-114. The RUN COUNT or USE TIME fields of a tag entry in the tag table 210 can be used to determine pay-per-use statistics. If a pay-per-use tag is expired, the USAGE STATUS field for the tag TAG_INST_SWn for that instance of software in the tag table 210 is set to GC_DISABLED”. This 25 can be done by preparing a disable action DISABLE(TAG_INST_SW) for the tag. This disable action can be incorporated into the continuation message 212, as will be explained shortly. After pay-per-use processing in step 421 is complete, step 422 creates a continue action CONTINUE(TAG_INST_SW) for every fully verified and 30 unexpired tag TAG_INST_SW in the tag table 210. This continue action will be incorporated into the continuation message (CM) 212. WO 00/72119 PCT/USOO/11821 -95In step 423, the verification program 315 prepares a continuation message (CM) 212 to be returned to the user device 104. The continuation message (CM) 212 contains several fields. A TIME field indicates the current time from clock 304 and a ID_TAG_TABLE field indicates the unique identification of the tag table 210 5 originally sent to the guardian center 103 in step 410 of the call-up processing, as well as an encoding of the event history at the time of the call-up HASH (EVENT_HISTORY). An ACTIONS field contains a list of actions ACTIONS = (ACTIONS1, ACTIONS2,...ACTIONSN) selected from the a list of available actions for a particular user device's 104 supervising program (SP) 209. A hash 10 function value is also included and is computed on the actions HASH(ACTIONS). Finally, a digitally signed value on the entire contents of the continuation message 212 is included to ensure that the continuation message 212 cannot be forged by a site or host on network 100 posing as a guardian center 103. Preferably, the signed value appears as follows:15 SIGNGC ( TIME, ED_TAG_TABLE,HASH(ACTIONS),HASH(EVENT_HISTORY)) Once all of the fields of the continuation message (CM) 212 are complete, the verification program 315 securely sends or transmits the continuation message (CM) 212 back to the supervising program (SP) 209 within the user device 104 that 20 initiated the call-up in step 410. In one embodiment, this may use a public key provided by the device upon call-up. If a pirate sets up two devices that have the same public key, only the one device having the correct event history will be able to process the continuation message 212 according to this embodiment of the invention. 25 Finally, in step 425, the guardian center 103 creates a call-up record CALL-UP_RECORDn associated with the call-up procedure. The guardian center 103 appends a reference to this call-up record CALL-UP_RECORDn to the tag data structure 320 (Figure 10) associated with this TAG_INST_SW. A reference is either WO 00/72119 PCT/USOO/11821 -96a memory pointer or a unique identifier of the CALL-UP RECORD. The contents of the call-up record are discussed above with respect to Figure 10. An example of the usefulness of this aspect of the invention will highlight some of its features. Suppose, for example, a user 213 purchases a one year license 5 to use an instance of software 111-114, and that after that one year period has expired, the user 213 does not renew the license. Since the user 213 does not renew, the software vendor 101 desires to disable the instance of software 111-114 for which the user 213 is no longer maintaining a license. Using this invention, the vendor 101 can simply set the policy POLICY(TAG_INST_SW) at the guardian 10 center 103 associated with that instance of software Π1-114 to disable the instance upon the next call-up to the guardian center 103 from the user device 104 equipped with the instance 111-114. In this manner, dynamic usage supervision is provided without requiring the user 213 to turn in his copy of the instance of software 111-114. If the user 213 later desires to renew the license, the vendor 101 merely 15 alters the policy POLICY(TAG_INST_SW) at the guardian center 103 and the next call-up will update the tag table 210 in the user device 104 with a CONTINUED” status tag TAG_INST_SW for that instance 111-114. The various components of the continuation message CM 212 prepared by the guardian center GC 103, and the above mentioned digital signature incorporated 20 into the CM 212 serve several important purposes in embodiments ofthe invention. The continuation message 212 instructs the receiving user device's 104 supervising program 209 how to update the USAGE STATUS column in the device's tag table 210 and which punitive actions, if any, to enact. The identifying hash function and other values in the CM 212 (Figure 13B, 423) make it virtually impossible for a 25 dishonest user 213 to use any continuation message 212 other than the one actually produced by the guardian center 103 in response to the current call-up from the user device (i.e., one of 104-107), for successful completion of the required call-up procedure. Also, an adversary agent or host cannot cause damage such as denial of service to a user device (i.e., 104), by sending an illegitimate CM 212 to the device 30 104. WO 00/72119 PCT/USOO/11821 -97As described in the above preferred embodiments, the invention provides a mechanism to detect, control and supervise usage of instances of software 111-114 that are either created and distributed (i.e., sold) from software vendors 101, or instances that are pirated and illegally distributed with attempted access by user 5 device 104. By providing an unforgeable and authentic tag TAG_INST_SW that uniquely identifies each instance of software 111-114, usage supervision is achieved. In the preferred embodiment, same location fingerprinting is used to verify that TAG_INST_SW is properly associated with a software instance INST_SW. Fingerprinting may be used for slightly different purposes as well. One such 10 purpose is to check the textual integrity of the operating system 207. This can be done by having one portion of a program check another portion or another program by the aforementioned fingerprinting process. This prevent tampering with, for example, the supervising program 209 or the operating system 207. In another embodiment, an external hardware device such as an electronically programmable 15 read-only memory can perform this check when the machine or device 104-107 is powered on. In either case, the checking program can compute a hash fingerprint as explained above on some portion of the operating system program 207, for example, and will causethedevice to fail if it finds a mismatch in fingerprints. Fingerprinting may also be used by the operating system 207 to check the supervising program 209 20 text. The supervising program 209 in turn can use the hash of the event history for verification or authenticity checking. This operates, for example, as follows: the supervising program 209 can update the hash of the data tag table 210 after each update using an incremental hash fiinction method such as MD5. Periodically, before updating the tag table 210 with 25 a new event, the supervising program 209 can verify that the hash function value it has is equal to the hash of the tag table. When any of these checks fail, the supervising program 209 or operating system 207 can take punitive action. In this manner, aspects of the invention can be used to detect device or software tampering of software which operates as the invention itself. 30 A further use of fingerprinting is to verify that specific vendor software submitted to the tag server 102 with a request for tags 120 for instances of that WO 00/72119 PCT/USOO/11821 -98software 111-114, is not an illegitimate copy or derivative of another legitimate vendor's software SW. Such an action, were it possible, would permit a pirating vendor to distribute another legitimate vendor's software SW with associated tag-server produced authentic tags 120. This aspect of the invention prevents this 5 form of piracy by fingerprinting the newly created software and using general location fingerprinting to compare the new software against existing software to see whether the newly submitted vendor software is suspiciously similar to legitimate vendor software SW. An instance of software 111-114 may have its tag checked either when it is 10 installed or when it is first used. Tags may also be checked (i.e. verified via either hash functions, signatures, or call-up procedures) later. One reason for waiting until the software is first used is that the software may be large, so that checking may entail less overhead when the software is run than when it is first installed. Because of failures, the state of a device may have to be restored to a 15 previous state. In this case, a user 213 must contact the Guardian Center 103 to warn that an old HEADER_TAG_TABLE may need to be sent. Suspicious uses of this privilege can be tracked easily at the guardian center 103. Figure 14 illustrates data structures used by an alternative-embodiment of this invention which can eliminate the need for Guardian Center call-ups for 20 software that produces shared data files. An example is a word processing program. Acquaintances often exchange word processing files and may exchange the word processing software as well. Typically, the first case is permitted whereas the second case of exchanging software applications is not. To prevent such piracy, an embodiment of the invention can change the software application program to write 25 the TAG_INST_SW 120 associated with that program, as well as, for example, the ED_TAG_TABLE, and the time of last access in an invisible location of each shared file, as shown in data structure 600 in Figure 14. The program also may write the TAG_INST_SW and time of last access into the TAG_TABLE 601, also shown in this figure. 30 The data structure 600 stored in the invisible location (invisible to the user, that is) in a shared software data file (i.e. a document for example, referred to herein WO 00/72119 PCT/USOO/11821 -99as an SSD) may be placed in a comment section of the shared software, data SSD file and can be accompanied by an unaliasable hash function which preferably uses the three arguments: TAG_INST_SW, ID_TAG_TABLE and time of last access 600. Figure 15 illustrates the steps of an embodiment of the invention that 5 provides the above noted software infringement protection mechanisms. In step 700 of Figure 15, when supervising program SP 209 on a first user device (i.e. user device 104) having an ID_TAG_TABLE X detects an access to a shared software data SSD, the supervising program 209 examines shared software data SSD and records within a predetermined location within the shared software data SSD that 10 shared software data SSD was accessed by the software instance (i.e. one of 111-114) having a TAG_INST_SW T at a specific time. Then, in step 701, when an instance of software (potentially on another machine or another user device (e.g., 105) attempts to execute and access the shared software data file SSD, the supervising program 209 on the user device 105 senses the existence of data 15 structure 600 in the shared software data file SSD and obtains the tag T from the SSD and checks the tag table 210 on user device 105 (the device obtaining the shared file, but not necessarily the creating device of the file SSD) to see whether the tag T is in the tag table 210. If the tag T does not exist, then the instance of software being used on the secondary device 105 (the device obtaining the shared data) to 20 access the shared software data SSD has not been copied, and thus access is allowed to proceed to step 703. Alternatively, if in step 701 the tag T does exist in the data structure 600 stored within the shared software data SSD, then processing proceeds to step 702. In step 702, the supervising program 209 on the secondary device 105 tests whether 25 the instance of software (e.g. one of instance 111-114 on the secondary device 105) associated with the tag T wrote the shared software data file at the time indicated in the data structure 600 embedded in the SSD. If not, piracy has occurred and the supervising program 209 performs punitive action on the secondary user device in step 704. If step 702 determines that the current instance of software 111-114 on the 30 secondary device 105 did access the shared software data SSD as indicated by the information in the data structure 600 embedded in the SSD, then processing WO 00/72119 PCT/USOO/11821 -100proceeds to step 703 where access to the shared software data is allowed. Note that this embodiment is advantageous by requiring no Guardian Center call-ups, other than, perhaps, one at the time of the purchase or installation of the software instance 111-114 or for purposes of detecting infringing software. 5- In another embodiment of this invention, different software instances of the same software differ depending on a device identifier. The advantage of such an embodiment is to reduce the needed communication with the guardian center. The disadvantage is that each software instance must be different (as opposed to only the tag's being different) and cannot be moved from device to device. In this 10 embodiment device identifier is constructed from a processor identifier if available (some processors such as a Pentium III built by Intel Corporation have a processor identifier) or preferably from the supervising program identifier, which may incorporate a processor identifier as described above. Each software instance incorporates the identifier of the device that is to use that software instance in a test 15 inside the software instance's code. Such a test may be expressed in the C language for example as an if statement. The test compares the incorporated identifier with the device identifier. The software, upon executing, performs the test. If the comparison succeeds, then the device may use the software instance. If the comparison fails, the device may not use the instance and may inform the 20 supervising program to take punitive action. A would-be pirate may modify the program so that the program doesn't check the device identifier. This is analogous to making tagged software appear as if it is untagged and therefore infringing. Software whose device test has been modified or removed may be detected by the fingerprint-based mechanism described in Figure 13 A, starting with step 414 in 25 Figure 13 A. A variant on this embodiment is that the vendor sends both the device identifier and a signed digital signature of the hash of the software instance incorporating the device identifier. This can be computed as follows: 30 SIGN_VENDOR(HASH_INST_SW), where HASH_INST_SW = HASH(SW, DEVICE__ IDENTIFIER) -101Here, SIGN_VENDOR is the digital signature of the vendor and the HASH_INST_SW is computed from the contents of the software (identical for all instances) plus the incorporated DEVICE_IDENTIFIER. The software instance incorporating the device identifier would preferably place that identifier at the beginning or at the end of the contents of the software in order to make the hashing process inexpensive. A second test verifies that the digital signature SIGN_VENDOR is authentic and a third test verifies that the sent HASH_INST_SW is equal to the value resulting from hashing the software instance. Both tests are performed by the supervising program on the user device. If either the digital signature is not authentic or HASH_INST_SW has a different value from the hash of the received software instance, then punitive action is taken by the supervising program. In the above descriptions, the tag server 102, the guardian center 103 and the vendor 101 have been described separately. Alternative embodiments are possible in which these roles can be unified. For example, a single site or networked host or server may serve as both the guardian center 103 and the tag server 102. Or a software vendor 101 may serve all three roles. Further still, even if each process or role is separated, some of the functions allocated to one component (i.e. tag server, guardian server, vendor) in the embodiments above may be performed by other components. For example, same-location fingerprinting may he performed at the vendor 101 instead of at the tag server 102. While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein. INTELLECTUAL PROPERTY OFFICE OF N.Z. 10 SEP 2003 RECEIVED MAY. 2004 1 5:43 SPRUSON & FERGUSON NO. 8358 P. 4/19 - 102 CLAIMS What is claimed is: 1. A system for supervising usage of software comprising: a software vendor component according to claim 19 producing identical 5 instances of software;a tag server according to claim 33 producing a plurality of tags, one tag per instance of software, each tag separate from the instance of software and uniquely identifying the instance of software with which it is associated;and a user device according to claim 24 receiving and installing an instance of io software and separately and securely receiving the separate tag, the tag uniquely associated with that instance of software and unrelated to the user device, the user device including a supervising program which detects attempts to use ihe instance of software and which searches for and verifies the authenticity ofthe separate tag associated with the instance of software before allowing use of the instance of software. IS 2. The system of claim 1, wherein the supervising program on the user device verifies the authenticity of the tag and maintains the tag in a tag table and maintains the instance of software if the tag is authentic and rejects the instance of software if the tag associated with the software is not authentic, 3. The system of claim 2, wherein the supervising program verifies a hash function value in the tag to determine if the tag is authentic and is properly associated with the instance of software. 25 4. The system of claim 2 wherein the tag is digitally signed and the supervising program verifies the authenticity of the tag hy verifying a digital signature of the tag. 5. 'fhe system of claim I wherein each of the plurality of tags created by the tag server comprises a name of software, a unique number of an instance of software and a jo hash function value on portions of an instance of software. 6. The system of claim 5 wherein the unique number of the instance of software is selected from a sparse set of numbers. Tntellectual property OFFICE OF N.Z - 7 MAY 200¾ received 7. MAY. 2004 1 5:43 SPRUSON & FERGUSON NO. 8358 P. '5/1 '9 -103 7. The system of claim 5 wherein each tag further comprises a unique identifier of the supervising program. 8. The system of claim 7 wherein ihe supervising program verifies that the unique 5 identifier of the supervising program in a tag is the same as an identifier of the supervising program on the user device. 9. The system of claim 1 wherein each lag includes at least one fingerprint computed on portions of the instance of software associated with the tag. 10. The system of claim 9 wherein the supervising program verifies that the software instance associated with a tag satisfies a same-location Fingerprint check against the at least one fingerprint included in the tag associated with the instance of software. ιί ll. The system of claim 10 wherein the same-location fingerprint check is performed by the supervising program at least one lime of before, during, and after use of the instance of software. 12. The system of claim 9 wherein each tag further includes at leasL one list of κι locations containing values from which the at least one fingerprint is computed and the supervising program verifies that the software instance associated with each tag satisfies a same-location fingerprint check against the at least one fingerprint associated with the software at locations specified in the at least one list of locations. 25 13. The system of claim 1 wherein whenever any data file is accessed by the instance of software, information associated with the instance of software performing the access is stored in a location associated with the data file. 14. The system of claim 13 wherein the information associated with the instance of so software is the tag associated with the instance of software. 15. The system of claim 13 wherein the information associated with the instance of software is the time of modification performed by the instance of software. intellectual property OFFICE OF N.z (R'\UaOO]OtfM3 do« φι'ί received 2004 15:44 SPRUSON FERGUSON NO. 8358 P. 6/19 -10416. The system of claim 13 wherein the information associated with the instance of software performing the access is written to a secure location which the supervising program alone can access. 5 17. The system of claim 16 wherein the supervising program verifies that when an instance of the software attempts to access a data file having associated information stored in the location associated with that data file, the supervising program verifies that the associated information stored is information associated with the instance of software currently attempting access, io 18. The system of claim 16, wherein the supervising program uses an unaliasable hash function to verify the associated information stored in the location associated with the data file for which access is currently being attempted: is 19. A software vendor component for a computer system comprising: a software production mechanism creating identical instances of software each having at least one name and one software content;each instance of software being usable only after verifying the authenticity of a tag that is unique to and separate from that instance of software, ihe tag being a unique 20 collection of information concerning the instance of software with which the tag is associated and including the name of the software, a unique number of the instance of software and a hash function value on portions of content of the software. 20. The software vendor component of claim 19 wherein the tag includes an 25 identifier of the supervising program associated with a user device upon which the instance of software is to be used. 21. The software vendor component of claim 19 wherein the tag includes a list of fingerprints of portions of the instance the software with which the tag is associated. 22. The software vendor component of claim 19, further comprising: an infringing software detection mechanism detecting software that is infringing on the vendor's rights and transferring a copy of the infringing software to a guardian center so that usage supervision can be implemented to detect attempted use of an instance of the infringing software on a user device. — INTELLECTUAL PROPERTY OFFICE OF N.Z (R:\UB0OJWH3 doc nuc -7 ΜΑΪ» received NO. 8358 P. 7/19 7. MAY. 2004 15:44 SPRUSON & FERGUSON - 105 23. The software vendor component of claim 22, further comprising: an infringing software detection mechanism detecting software that is infringing on the vendor's rights and transferring a copy of the infringing software to a guardian 5 center, the guardian center invalidating any tag associated with an instance of the infringing software and sending a punitive action to any user device detected by the guardian center to have used the instance of infringing software. 24. A user device comprising: io an input port receiving an instance of software and receiving a tag uniquely associated with and separate from that instance of software, said tag being a unique collection of information concerning the instance of software with which the tag is associated and including the name of the software, a unique number of the instance and a hash function value on portions of content of the software, and receiving a request to use 15 the instance of software;a processor executing a supervising program, the supervising program detecting the request ro use the instance of software and verifying the authenticity of the tag associated with the instance of software before allowing use of the instance of software by the user device. 25. The user device of claim 24, wherein the supervising program verifies the authenticity of the tag and stores the tag in a tag table and maintains the instance of software if the tag is authentic and rejects the instance of software if the tag associated with ihe software is not authentic. 25 + 26. The user device of claim 25, wherein the supervising program computes a hash function value on the instance of software and compares the computed value with a hash function value in the tag to deremtirte whether the tag is authentic and is properly associated with the instance of software. 27. The user device of claim 25 wherein the lag is digitally signed and the supervising program verifies the authenticity of the lag by verifying a digital signature of the tag. BeiLECTUAL HHUHblTh OFFICE OF N.Z -7 MAY 200¾ (R \UDOO)QG043.doc:mic - 106 28. The user device of claim 25, wherein the tag table is a data structure stored in storage on the user device and contains at least one tag that is uniquely associated with an instance of software and includes fields associated with the tag in the tag table, one of the fields indicating a usage status for the instance of software associated with the tag. 29. The user device of claim 24 wherein the supervising program determines that a call-up procedure is required as defined by a call-up policy and the supervising program performs the call-up procedure to update the usage status of tags stored in the tag table. 30. The user device of claim 24 wherein the supervising program verifies that each data file used by tagged software is produced by a legitimate instance of software. 31. The user device of claim 29 wherein during performance of the call-up procedure, the supervising program securely transmits the tag table from the user device via an interconnection mechanism coupled to the user device and awaits reception of a continuation message returned to the user device, the continuation message indicating actions to be performed for each tag in the tag table. 32. The user device of claim 29, wherein during the performance of the call-up procedure, the supervising program securely transmits a tag table header from the user device via an interconnection mechanism coupled to the user device and awaits reception of a continuation message returned to the user device that indicates an action to be performed for each tag in the tag table. 33. A tag server accepting a copy of specific vendor software and producing a plurality of tags, one tag per instance of the software, each tag uniquely identifying an instance of software with which it is associated, and each tag comprising the name of the software associated with the tag, a unique number of the instance of software associated with the tag, and hash function values computed on portions of the instance of software associated with the tag. 34. The tag server of claim 33, further including a digital signature mechanism used to digitally sign the tags and to securely transmit the tags to an intended receiver. 35. A method for supervising usage of software comprising the steps of: INTELLECTUAL hkui OFFICE OF NT 2 7 MAY 200 [R:VLIBOO]06043.doc:mic 2004 15:45 SPRUSON & FERGUSON NO. 8358 Ρ. 9/19 - 107creating an instance of software;creating a tag that is uniquely associated with the instance of software;distributing the instance of software and separately and sequrely distributing the tag to a user device and receiving the instance of software and separately and securely 5 receiving the associated tag at the user device, the tag uniquely associated with that instance of software and unrelated to the user device;detecting an attempt to use the instance of the software on the user device;and determining if the attempt to use the instance of the software is allowable by verifying the authenticity of the tag that is associated with the instance of software to be io used. 36. The method of claim 35, wherein the step of distributing the tag to a user device includes the step of securely distributing the tag to a software vendor and user device using a public key encryption technique. 37. The method of claim 35 wherein the step of receiving the instance of software includes the step of: obtaining the instance of software at the user device;and wherein the step of receiving the tag at a user device includes the steps of: 20 securely obtaining the tag associated with the instance of software at the user device;determining if the tag associated with the instance of software is signed and, if so, verifying a signature on a hash function value in the tag and, if the signature on the hash function value is verified, installing the software on the user device, and, if the tag 25 associated with the instance of software is not signed, installing the instance of software on the user device. 38. The method of claim 35 wherein: the step of detecting an attempt to use the instance of the software on the user device includes the steps of: invoking a supervising program on the user device to intercept a user request for use of the instance of software;and wherein the step of determining if the attempt lo use the instance of the software is allowable includes the steps of: [R:\UB0010604J.doc-.mic. INTELLECTUAL PROPERTY OFFICE OF N.Z - 7 MAY 200¼ RECEIVED 7. MAY. 2004 15:45 SPRUSON & FERGUSON NO. 8358 P. 10/19 -108 determining if a call-up procedure is needed based on a call-up policy and if so performing the next three steps: performing a call-up procedure to verify the authenticity and to determine the usage supervision policy of the tag associated with the instance of software;5 updating tag information on in the user device based upon an outcome of the call-up procedure;and examining status information associated with the tag to determine if use of the instance of software associated with the tag is allowed. io 39. The method of claim 38, wherein the step of performing a call-up procedure includes the steps of: transmitting a lag table storing the tag associated with the instance of software from the user device;awaiting reception of a continuation message returned to the user device that 15 indicates an action to be performed for each tag in the tag table. 40. The method of claim 38, further including the step of verifying that the continuation message is directed towards this device and that the event history corresponds io the event history at this device. 41. The method of claim 3S, wherein the step of performing a call-up procedure includes the steps of: receiving a tag tabic including the tag associated with the instance of software;examining each tag received in the tag tabic against a tagged software database to ensure that tags in the tag table are in compliance with at least one usage supervision policy;and transmitting a continuation message indicating an action to follow at the user device upon detecting an attempted use ofthe instances of software associated with each tag. 42. The method of claim 41, wherein the continuation message includes: a supervising program identifier of the supervising program to which the continuation message is to be sent;the time when the continuation message was prepared;an encoding of the tag table header that accompanied the call-up from the device. (R,\UBOD)06!M3 docmic INTELLECTUAL PROPERTY OFFICE OF N.Z -7 MAY 200¾ RECEIVED 7. MAY. 2004 1 5:46 SPRUSON & FERGUSON NO. 8358 P. 11/19 - 10943. A system for supervising usage of software, substantially as described herein with reference to any one or more of the accompanying drawings. 5 44. A user device substantially as described herein with reference to any one or more of the accompanying drawings. 45. A software vendor apparatus substantially as described herein with reference to any one or more of the accompanying drawings. 46. A tag server substantially as described herein with reference to any one or more ofthe accompanying drawings. 47. A method for supervising usage of software, substantially as described herein 11 with reference to any one or more of the accompanying drawings. DATED this twenty-seventh Day of February, 2004 Michael O. Rabin, Dennis E. Shasha By Patent Attorneys for the Applicant 20 SPRUSON & FERGUSON Pcr: INTELLECTUAL PROPERTY OFFICE OF N.Z -7 MAY 2004 [R.\UBOO]ttiiQ43,il0c:m)< RFHFIVFn WO 00/72119 PCT/USOO/11821 1/18