WO2003036530A1 - A method and a system for licensing digital resources and services - Google Patents

A method and a system for licensing digital resources and services Download PDF

Info

Publication number
WO2003036530A1
WO2003036530A1 PCT/FI2002/000827 FI0200827W WO03036530A1 WO 2003036530 A1 WO2003036530 A1 WO 2003036530A1 FI 0200827 W FI0200827 W FI 0200827W WO 03036530 A1 WO03036530 A1 WO 03036530A1
Authority
WO
WIPO (PCT)
Prior art keywords
license
execution
request
unit
control unit
Prior art date
Application number
PCT/FI2002/000827
Other languages
French (fr)
Other versions
WO2003036530B1 (en
Inventor
Pasi TYRVÄINEN
Original Assignee
Pinma Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pinma Oy filed Critical Pinma Oy
Publication of WO2003036530A1 publication Critical patent/WO2003036530A1/en
Publication of WO2003036530B1 publication Critical patent/WO2003036530B1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/105Arrangements for software license management or administration, e.g. for managing licenses at corporate level

Definitions

  • the invention is related to management of the use of digital data. Especially this invention is related to management of the use of various digital products, services and data communication connections by means of licensing.
  • a resource refers to a physical operational unit or a system, that can be such as computer equipment or -software, functionality implemented by software, a set of articles in a database or data communication capacity.
  • the resource implements a certain service, that can be such as operation implemented by hardware equipment or software, functionality of program or certain data communication capacity. Both of these are thus managed by using licenses, which define the rights to use the service implemented by a certain resource.
  • Publication US 5457746 presents a method and equipment, in which data published using various equipment is licensed.
  • the publishing mean can be such as a CD- ROM (Compact Disk Read Only Memory), data contained in which is divided into sections, whose access is controlled.
  • billing options also known as attributes, can be used.
  • Controlling access to information in a data section is based on encryption of information contained in data sections so that its decryption requires a data section specific key.
  • the characteristic features of the method presented in the publication are encryption of the data in the specific way, distribution of the data with certain mechanism and controlling the data usage with the aid of an update method.
  • the presented method is limited to a use of encrypted data sections.
  • the aim of the invention is to produce a licensing system, which is extendable and modifiable.
  • the aim of the invention is to diversify the properties and the use of the licenses so that accesses and functionality are easily and flexibly available and further extendable.
  • the aim is reached by using license templates for controllable and flexible creation of licenses.
  • the license templates can be defined to match the respective requirements.
  • the license templates can be also modified later on, during the usage, and multiple templates with alternative scope can be used for a single re- source concurrently.
  • the execution licenses used according to the present invention are created using li- cense templates.
  • the license templates contain variables, attributes, the aid of which the service or resource to be licensed will be defined on the license template. License templates are transmitted to the license request unit, in which the attributes of the license template are used for defining the target environment of the licensed service or resource and the license template is transformed into a license request.
  • the license request will be handed over to a license creation unit, where, with the aid of attributes of the license request, constraints for the use of the licensable service or resource are defined, and the license request is transformed into an execution license.
  • the execution license is next transmitted to a license control unit of the target environment, which controls the usage of the execution licenses, verifies that the constraints and the identifiers are valid, and is able to interpret execution licenses flexibly.
  • Creation of the licenses can be centralized to a single site around a license creation unit or constituted functions can be distributed into each target environment as integrated packages. Alternative arrangements are scrutinized later on. Already existing licensed systems can be flexibly upgraded with new features, and the life cycle of a license can be managed by its attributes. Multiple parallel licenses can be granted for a single resource.
  • licenses can easily be transmitted from equipment to another and be modified to be applicable into a system, some part of which will be changed. Because there exists a limited number of digital resources, they tolerate only a limited load. For example, a large number of concurrent users can overload an e-commerce site and bring the system down. According to an advantageous embodiment of the invention management of the digital resources is also ensuring the availability of services.
  • the end user will gain benefit from the licenses according to this invention by being able to get with them software and resources for trial use with low cost and later on it is easy to upgrade the licenses to full licenses.
  • the user can also purchase extended continuation or features to the existing licenses.
  • the licensing is comfortable and almost transparent to the user. To the manufacturer the licensing of the add-on products will clear up, because the manufacturer can control the use of the add-on products in addition to his core products. In addition, both manufacturers of the core product and the add-on product can simultaneously control the sales and use of certain licenses.
  • Figure 1 illustrates a licensing system according to an advantageous embodiment of the present invention
  • Figure 2 illustrates as a flow chart the operation of a license control unit according to an advantageous embodiment of the present invention
  • FIG. 3 illustrates an execution license according to an advantageous embodiment of the present invention
  • Figure 4 illustrates as a flow chart the operation of a license request unit according to an advantageous embodiment of the present invention
  • Figure 5 illustrates as a flow chart the operation of a license creation unit accord- ing to an advantageous embodiment of the present invention
  • Figure 6 illustrates an arrangement for an electrical trading center according to an advantageous embodiment of the present invention
  • Figure 7 illustrates as a flow chart the operation of a resource management system according to an advantageous embodiment of the present invention.
  • Figure 1 illustrates a licensing system according to an advantageous embodiment of the present invention, in which licensing system all components can be located for a use of a set of computers using a specific www server or for a use of a LAN server and its clients.
  • the components illustrated in figure 1 can be located in a single computer or in an UMTS phone (Universal Mobile Telecommunications Services).
  • the licensing system illustrated in figure 1 can also, according to an advantageous embodiment, be distributed into the execution environment, i.e. part of components can be connected to the target environment for example, via data communication connection.
  • the target environment includes all the equipment and components, which communicate with the license control unit 104.
  • License control unit 104 thus defines the target environment so that the target environment includes those components and equipment, which use the license control unit in question in order to get a right to use some resource or service controlled by licenses.
  • target environment there are at least an execution license, a license control unit and some software or resource.
  • the license control unit 104 and the unit using the service (using unit) 105 have been integrated into a single uniform component. The integra- tion ensures uniform operation of the using unit 105 and the license control unit 104, and it is not possible, for example, to implement a false license control unit in between the components of the integrated system, which would accept every license to a specific target environment.
  • the using unit 105 is for example a LAN server's terminal, which wishes to open a known text processing program, for example MS Word text processing program registered by Microsoft, the terminal will request a permission to use this program from the license control unit 104.
  • the license control unit 104 searches for the license of the program to be started for example from a database, in which a license registry is maintained. This data structure can be located in the central memory or mass storage 108 of the using unit 105. If the license control unit 104 finds a valid license for the resource in question and recognizes the requesting terminal, the license control unit 104 will grant a permission to start the program in the terminal after checking first that the conditions of the license are fulfilled.
  • the license contains attributes, whose values define, for example, the valid execution environment of the license.
  • the using unit 105 can also according to an advantageous embodiment request a to- tally new license.
  • the license control unit 104 and the license request unit 103 are situated advantageously in the same equipment or in the same server as the using unit 105.
  • the using unit 105 thus wants to use a new resource or service and request a license from the license request unit 103.
  • a license template is handed over to the license request unit 103 with the request.
  • the license template identifies the service or resource requested.
  • the license templates are typically application-specific i.e. for each service or product to be licensed there typically exists a specific license template.
  • license templates are produced in a license tem- plate unit 101.
  • the license templates can be produced also by other methods known as such and those can be brought to the use of a licensing system according to an advantageous embodiment of the invention for example via data communication connection or a physical memory device, such as a floppy disk or a CD-ROM or the license templates can be retrieved from network from a server. I.e/, the resource or service to be licensed is defined in the license template.
  • the manufacturer typically controls and produces these license templates.
  • a license template can define, that the product to be licensed is a text processing program and the production and availability of the license templates can be arranged by the party selling the licensed rights to use.
  • the target environment of the requested license is defined into the license template in the license request unit 103, for example by defining the terminal, in which this license is requested to be used.
  • the license template is transformed into a license request.
  • a license template and a license request are states of the license, phases of its life-cycle, that are defined in the license like other variables: by changing attributes of the license.
  • the license request are transmitted to the license creation unit 102 either via a data communication connection, via shared memory, or using some similar mechanism or memory device, such as a floppy disk or alike.
  • the license creation unit 102 uses the same memory unit 107 as the license template unit 101. This way the license creation unit 102 is able to access the license template defining a resource or a service directly from the memory unit 107, where to for example the license template unit 101 has stored it.
  • the license creation unit 102 can attach license templates to the execution license it produced, so that those are delivered with the execution license to a user or to a using application. For example a short-term trial license can be attached with a license template for a long-term execution license, thus enabling the user after experimenting the product with the trial license easily order an execution license.
  • the license creation unit 102 maintains bookkeeping of licenses and assigns specific constraints to the licenses, typical of which are such as duration of the license and the number of concurrent users. In addition, the license creation unit 102 changes the state of the license from license request to execution license by changing the attribute values of the license request.
  • the target environment of the license can be defined to be for example an individual computer or a network server, where upon the license can be used by a terminal equipment of the network.
  • the license creation unit 102 is located in equipment of a party selling rights to use the product.
  • the execution license produced by the license creation unit 102 and the license templates possibly attached to it are delivered using a data communication connec- tion or a physical portable memory device into the target environment, in which the execution license is requested to be used and which has been defined in the execution license.
  • the execution license will be installed by using a set-up program into a file, registry or some similar data structure located in the mass storage 108.
  • the mass storage 108 stores for example programs and other in- formation needed in licensing.
  • the system has also central memory, in which a run-time version of the license is preferably stored.
  • the central memory is preferably a part of the unit 105 using a resource or a service licensed, and it is not separately described in figure 1.
  • one target environment can consist of the network and terminals defined by the license control unit 104, in such a way, that the license of a word processing program is located on a server, where from a number - defined in the license - of network terminals can execute it concurrently with the permission of the license control unit 104.
  • the license control unit 104 it thus monitoring the permitted use of the licenses.
  • the license control unit 104 interprets execution licenses very flexibly, which means that, in execution licenses managed by a specific license control unit 104 the number of attributes may vary or the right to use a specific resource or service can be granted based on execution licenses, which have different number or dissimilar attributes. In addition, the attributes can have multiple values or a single license control unit 104 can interpret execution licenses of multiple separate resource or service.
  • another additional license control unit can be installed to the same computer for example for a licensed service, to be used only in that computer, which can be such as a bookkeeping and accounting program. Permission from the license control unit 104 is needed for use of a licensed resource 106.
  • the used resources 106 are located typically in the target environment, but they can also be located beyond a communication link.
  • the license request unit 103 is located in the target environment or at least the parts of it necessary for iden- tification of the target environment.
  • the components necessary for the licensing system can be located in a single equipment, for example in an UMTS phone, which thus in this case is the target environment. I.e., in the target environment there are the using unit, the license request unit 103, the license creation unit 102 and the license control unit 104 and the necessary memory units 107,108.
  • the license creation unit 102 can create a connection to a payment system, for example into a charged service number or to a similar charged direct debit system. The user must pay the fee before the execution license he requested can be created. After the payment the license creation unit 102 can, for example, produce an execution license for a translation program so that the right of use is valid for a half an hour. This way the user gains access to a specific product or service for the time requested as a response to the pre-payment.
  • similar services or resources can be used as agreed either as a response to a monthly fee or so that the active time of use is charged.
  • Figure 2 illustrates as a flow chart operation of a license control unit according to an advantageous embodiment of the present invention.
  • the license control unit is ready for action.
  • the licenses located in a specific or even in multiple memory units are read and the licenses are decrypted, if encryption has been used.
  • the check sums 203 of the licenses are calculated with some method known as such. By check sum 203 the integrity of the licenses is ensured.
  • the conditions and constraints of the license such as the validity period and identifiers of the target environment, will be validated at the time being in the target environment of this license control unit.
  • a service request or a new license is received.
  • a new license 205 is re- ceived, when a user, an application, or equipment wants to use some new service and/or resource and the use requires licensing the service and/or resource.
  • the license control unit receives a service request 205, the requesting party wants to use some existing license.
  • the service request will be received when the license control unit is requested a permission for executing a licensed service or resource.
  • the control moves to the block 202, where after the attributes of the new license will be inspected to verify at least, that the licensing period is valid and in the target environment in question.
  • the possible encryption of the license is decrypted.
  • the control moves to the block 206, in which the license control functionality will be acti- vated.
  • the service request will be received and the license control functionality will be activated when a user or a system wants to use a specific resource or service, for example when the user wants to start a word processing program with an license at his device, which is connected to a specific local network.
  • Other similar resource or service can be such as launching some system; I/O functions of a system, such as opening, reading, changing, or otherwise handling files, databases, or parts of them; reservation or use of data communication capacity from a specific data communication resource; initiating a specific function or functionality; establishing a new session or a work-space; or logging in a new concurrent user.
  • Activating a specific service can include parameters describing its usage, such as the location of the target, the volume or intensity of use, that are identified in license's attributes, so that they can be utilized in controlling the licenses.
  • the license control unit can be activated in several separate ways, for example a system can activate the license control unit by sending to it a signaling message either prior to use of a resource, while monitoring its own operation, periodically or randomly; or hardware or software of system platform can activate the license control unit by signaling; or the license control unit can monitor signals of the system platform, such as operating system's messages, interrupt signals or messages of a data communication software, and activate itself when defined conditions are met.
  • Signals of the system platform that can be monitored and whose occurrence will initiate the license validation described above, include for example, common services of the target environment, such as remote procedure call, for example DCOM (Distributed Component Object Model), a service request, for example ORB (Object Request Broker), Microsoft Windows message, paging request of an operating system, service request of the file system, or other similar mechanism that is inde- pendent from the using system.
  • DCOM Distributed Component Object Model
  • ORB Object Request Broker
  • Microsoft Windows message paging request of an operating system
  • service request of the file system or other similar mechanism that is inde- pendent from the using system.
  • the unit defined by the instructions for exception handling which can be, for example, the license control unit or a specific program of the system, executes the operations defined by the instructions for exception handling 211. If instructions for exception handling are not found 209, pre-defined default operations 210 are executed. After executing these default operations 210 or exception handling operations 211 the execution moves to the receive block 204.
  • the instructions for exception handling define policies i.e. alternative actions to be taken in the target environment when the conditions defined by the license's attributes are not fulfilled or the license is not integrity or some other expectable possible exception is observed.
  • Instructions for exception handling define, thus, how to pro- ceed, when the license control unit observes problems.
  • the perceived problem can be such that license's ending condition, for example time, has been reached or the license has too much users or load. Some times no license will be found for a service or the check-sum does not match.
  • the exception handling operations to be carried out can be such that the operation is interrupted, when the requested service will not be started, and no access to the resource will be provided.
  • the exception is simply reported to the user or to the vendor of the resource and the operation is continued, for example in according to an old or a trial license. Reports on exception can also be done periodically or the reports can be directed to a log and the service request in hand can be bypassed.
  • the resource to be used is deleted from the target environment. Often the user is provided a possibility to order a new license or to continue operation in the restricted trial mode.
  • the possible exceptions and the exception handling operations to be taken following them are defined in the so-called license schema, based on which the license templates are produced.
  • Specific exception handling codes which can be used in the licenses controlled by this license control unit, are transmitted to the license control unit. These exceptions handling codes can be for example procedure calls.
  • the license control unit has a set of pre-defined exception handling codes, out of which the ones to be used are chosen product-specific.
  • exception handling codes for those:
  • the period of the execution license is over i.e. the license has outdated, the situation is reported to the user and a temporary license is taken to use or the execution is terminated.
  • the limit of concurrent users is exceeded i.e. the license has too many users, the last service request is by-passed and the situation will be reported to target environment logs and/or to the vendor of the resource. If a defined capacity constraint is exceeded i.e.
  • an execution license which comprises a header 310, a body 320 and a checksum 330.
  • the header 310 of the execution license there is a version number 311 of the license schema used by the licensing system and possibly some additional data 312, such as disposable key data used for encryption and decryption or seed data of a key generator.
  • the data contained in the license can be encrypted for example with some public key, by using changing data of the license to form a key or by encoding the data with numbers or symbols or by replacing the characters with some others.
  • the license schema defines the set of the attributes, which can be used in a license template.
  • the license schema is thus a kind of basic structure of the license template, out of which the license template itself will be modified.
  • a license schema can be, for example, as follows:
  • the version number in the first row of the license schema is the same for all license templates, which have been created based on this version of the license schema.
  • the same license schema version number exists also in such a li- cense template, in which only a part of the definitions of the license schema are in use.
  • the version number of the license schema is also in this kind of license template 1.1. If into the li- cense template there needs to be defined a new variable (i.e. attribute), for example duration of the session, the version number of the license schema will be changed.
  • compulsory variables of a license schema are product code, identifier of a target environment and duration of a license.
  • product code is represented in a textual format and it can be, for example, "MS Word" registered by Microsoft, as a target environment identifier there is a processor identifier (CPUID), which is represented as a 12-digit integer and start and end times of license usage are represented in the preceding license schema in date format. Times can naturally be represented also in time format.
  • the execution license contains always the body 320 with a group of attributes, which each have a single or multiple values, which describe information necessary for licensing. Examples of this information have been listed next with references to numbers in figure 3.
  • the body 320 typically contains identification information, such as an identifier of the product, an identifier of an execution license and instructions for exception handling, which define, what to do in various exception situations.
  • Figure 3 illustrates as an identifier of a target environment an identifier of a processor 321. Similar identifier binding a license to a target environment can be an identifier of a network card, a hard disk, a data communication connection or a similar component. These identifiers define one or more equipment or processor as a target environment, in which the license can be used.
  • product information for example information about which resource, service or function is licensed with this execution license.
  • product information can be, for example, a product number or a name of a product.
  • value list of an attribute such as a list of identifiers of licensed sub- resources, that can be, for example, parts of a data base or specific services, or a list of such license template identifiers, that are typically next offered for the user.
  • information about the constraints of the use of the license 322 such as how long or until when the license is valid or how many service requests are accepted.
  • instructions for exceptional situations i.e. violation policies
  • These instructions determine, what to do for example in cases where there is an attempt to execute the license in a wrong target environment, the validity period of the license runs out, the number of allowed concurrent users is exceeded or the data structure of the license is found to be inconsistent.
  • the license can also contain an attribute controlling the integrity of the license, i.e. a check-sum or some similar figure 330 applicable for integrity checking. Integrity of license's attributes and their values can be controlled with specific integrity instructions. These instructions define interrelationships in between the attributes and their values, which an external party cannot deduce only by inspecting the license. Cryptographic methods for checking the integrity and the origin of a digital message by using various check-sums and digital signatures are known as such and those can be used also as a part of the present invention especially for ensuring the integrity of the data in the body.
  • the license can contain information about the present status of the license, for example, in which stage of the life- cycle the license is. For example a license can be obsolete or removed after the use, which corresponds to a so-called final state of a license. A license can still contain information about the licensing process. Based on this information there can be reasoned for example, which license templates should be offered next to the owner of this license. A license template contains also data about continuation licenses. Along with a license request, information about possible continuation licenses is passed to the license creation unit, which will deliver the necessary continuation license templates along with the execution license into the target environment.
  • transfer licenses which are needed, when the target environment - or a part of it, such as the target computer - needs to be changed.
  • An existing execution license can be transferred from one execution environment to another by using a transfer license for ex- ample, in cases, when equipment of a target environment will be changed so that the identifier of the target environment of the old license 321 is no longer valid in the new equipment. If for example, in the case in figure 3 a processor, which has been defined with the target environment identifier 321, will be replaced with a new one, the license will not be valid in a new environment.
  • a transfer license is produced by a license request unit, whose operation will be scrutinized in greater detail with figure 4 later in this application.
  • a transfer license will be produced roughly as follows: the license request unit converts an existing execution license into a temporary execution license.
  • the temporary execution license will be functional for a limited period of time in its original target environment.
  • the license request unit will produce a transfer license, which is a special license template, into which the attributes of the original execution license have been copied.
  • the license request unit will form a license request, which contains relevant attribute knowledge of both the new, requested license and the old execution license via the transfer license.
  • the license request will be processed in general in the same way as other license re- quests, which are scrutinized later in this application.
  • a trial license (or a demonstration license) is yet another commonly used form of a license.
  • the trial licenses provide a limited functionality or duration. All licenses follow the outline of the structure represented in figure 3. Typically there are differences in the state attributes of different kinds of licenses and different number of at- tribute values may be filled in them. In some cases new attributes can be added to the licenses.
  • New license templates are created for example, in a specific license template unit based on a specific license schema.
  • the license template unit is advantageously using the same mass storage as the license creation unit, in order to keep the informa- tion exchange in between them as flexible as possible.
  • the used license schema defines the attributes used in licenses 321, 322, 323 and possibly also their value domains. Adding a new attribute to a license schema will cause a change to a license schema version number 311.
  • the version number 311 will be changed into a license template only if it is necessary, which is, only if the license template uses attributes missing or changed from an older schema.
  • the license schema version number 311, is in a header 310 of license templates, and thus also in license requests and execu- tion licenses.
  • a license control unit From a version number 311 a license control unit gets the schema version, which it must be able to interpret in order to interpret the data of the execution license correctly (for example, the block 206 in figure 2). If the license control unit is not able to interpret the version number 311, for example, because it is so new, the license control unit acts according to the exception handling instructions addressed to it (figure 2, block 211). In the instructions for exception handling there usually exists specific instructions to such exceptions, in which the version number 311 is not recognized, i.e. a violation policy for unrecognized schema version.
  • the instruction for exception handling can, for example, define, that the li- cense control unit should order a newer version of the license control unit via data communication connection, inform the user and suspend execution or execute the license only in a mode of restricted use and inform the user about this.
  • the operation will follow the instruction for exception handling defined in the license template, which is copied into an execution license.
  • An implementation of the instruc- tion for exception handling is programmed into a license control unit, and if it is missing a default procedure is followed.
  • the license request unit notices situations, in which the license control unit is not able to recognize an execution license following a license request or a license template.
  • the license request unit can react to this for example, by ordering a new ver- sion of a license control unit, by preventing creation of a license request or by informing the license creation unit.
  • the license templates are similar as the execution license represented in figure 3, only some of the attribute values are missing. Typically the attribute values binding the execution license to the target environment and limiting the validity of the li- cense are missing from the license templates.
  • the license templates are typically stored in the mass storage of the system or in central memory. Alternatively temporary license templates can be accessed via a data communication connection.
  • the licensing system accesses license templates typically through Internet services. For example, new license templates and continuation license templates can be loaded from the net.
  • Continuation license templates include for example own template of a temporal execution license for a following period of use, a license template for permanent use and a license template providing an additional feature. Along with a resource or a service it is possible to deliver license templates for a permanent license and for a temporal license.
  • trial licenses which are execution licenses with limited validity period.
  • the attribute defining the last validity date of a trial license is typically set while setting up the resource, whose usage it will control. This means, that after the first installation of a product its license will be valid for a specific, pre-defined time period.
  • the figure 4 scrutinizes operation of a license request unit as a flow chart.
  • First data of licenses already existing in a target environment is read 401. After this integrity of the execution licenses and fulfillment of the license conditions are inspected 402.
  • Next information about the existing licenses is presented to the user and new products are offered 403.
  • the license request unit has some kind of user interface for the user or a corresponding software interface to applications, through which the licenses are presented.
  • a list of all execution, trial, transfer, and ob- solete licenses read in block 401 as well as a list of license templates are presented to the user.
  • the user can order a new license. If the user does not want to order a new license 404, he can choose in the block 405, that he stops the execution 406 or he may resume the execution, where after the control moves to the block 403. If the user orders a new license 404, the information of a chosen license template is represented to him in the block 407.
  • the license template information has been collected from attributes defined by the license schema and/or from separate data.
  • the license template is application-specific and defines the product to be licensed. In addition it is possible, for example, to link descriptive data to the license templates using identifiers, which can be in textual or hypertext format.
  • identifiers which can be in textual or hypertext format.
  • the execution of the program moves into the block 403. If the license order is confirmed, the program verifies, that it has sufficient information for the delivery and invoicing of the order 409. If not all customer or payment data exist, the user is requested to complete the missing data 410.
  • the license request unit fills, in the block 411, the attribute values needed for the license template, such as identifier of the target environment and changes its state from a license template to a license request.
  • a possible check-sum is calculated and when necessary the license request is encrypted.
  • the exis- tence of a data communication connection such as a TCP/IP (Transmission Control Protocol / Internet Protocol), RPC (Remote Procedure Call) or a shared memory location, to the license creation unit is checked 413. If a data communication connection cannot be established, the license request can be delivered for example on a diskette to the license creation unit and the user will be given instructions for deliv- ery 415. If a data communication link can be established, the license request will be sent or handed over through the data communication link to the license creation unit 414.
  • TCP/IP Transmission Control Protocol / Internet Protocol
  • RPC Remote Procedure Call
  • the requested license request will be delivered to the license creation unit, whose operation is described in the flow chart 5.
  • the license creation unit receives the li- cense request, reads it 501 and decrypts a possible encryption.
  • the integrity of the received license request will be checked with the aid of the check sum as well as the applicability of the attributes and payment and order information 502.
  • the invoicing transaction necessary for the requested license is performed for example through a network using some existing payment system or by passing invoicing information forwards for manual invoicing.
  • the block 504 there occurs a check, whether all the actions taken so far have been successful. If some previous action has failed, the problem is reported to the user 505 and execution of the program will be stopped 513.
  • the execution will move to the block 506, in which the system completes and changes values of specific attributes of the license request.
  • the end time of the license will be added as an attribute and the state will be changed from the state license request to the state execution license.
  • Next possible check-sums are produced to the execution license and if needed, the data will be encrypted 507.
  • Bookkeeping data of licenses is recorded to a license database 508, which contains information of all licenses.
  • the execution license is further attached with templates of products of interest from the viewpoint of the execution license user and descriptions of the products, after which they are available for the license request unit (presented in figure 4). If a data communication connection exists or can be established in between the license creation unit and the target environment 510, the license creation unit sends the executions licenses, attached license templates and their descriptive information through the data communication connection to the license control unit located in the target environment. In the target environment the execution licenses are typically stored into the mass storage or in a short- term use into the central memory used by the license control unit (presented in fig- ure 2).
  • the advantageous embodiment described in previous with figure 5 is a typical solution, in which the license creation unit is located in possession of the organization delivering the software, hardware, system or other resource and/or system used, apart from the target environment of the licenses. According to another advantageous embodiment the license creation unit is located in the target environment together with the license control unit. Operation of a license creation unit according to this other advantageous embodiment is similar to the operation of the embodiment presented in previous in figure 5 otherwise, but now it is supposed, that the license creation unit is able to verify the data of the payment system about the license payment transaction without user interaction in the block 503 of figure 5. This further assumes that there exists a data communication connection.
  • licenses and usage monitoring data will be transmitted via a data communication connection, when possible.
  • product descriptions 509 and license templates to be attached to a complete execution license are retrieved through some data communication connection and they are stored to the target environment for a sufficient period of time, for example into the mass storage or for a session to the central memory of the license request unit, from which they can be taken to use in the beginning of each session.
  • This other advantageous embodiment is useful for example, in cases, when the target environment is a portable equipment and charging is taken care of for example, by calling charged service numbers.
  • a license creation unit is located in an entirely separate system, such as in an e-commerce site in the Internet or in another electronic trading center.
  • an electronic payment system is integrated with the license creation unit as well as often a possibility to load license templates and product data of new products to the target environment.
  • this is combined also with downloading of software resources with their trial licenses from the same system.
  • an electronic trading center can distribute free trial licenses, which the users can easily extend by buying more resources, duration or sessions.
  • a customer uses an electronic connection to the trading center and a licensing system, payment system, as well as their data connections are located within the trading center.
  • the customer can order a trial version of the product, which can thus be free or a charged product, such as an inexpensive demonstration version, evaluation version intended for trial use, a version with less functions or a sponsored ver- sion with advertisements.
  • the product which can be a software or some other resource, will typically be delivered using a data communication connection, but it can alternatively be delivered, for example, on a CD-ROM or on a DVD (digital versatile disk).
  • the product delivery comprises advantageously the software or other resource, a trial license providing limited functionality, and a license template for the use of the chargeable product itself.
  • the delivery can comprise a license control unit, a license request unit, and a user interface needed for licensing, unless these are implemented on a trading center.
  • the license request unit will produce a license request, which is delivered via an established data communication connection to the electronic trading center.
  • License creation unit integrated to the trading center creates an execution license from the license request and takes care of the payment transactions with a method known as such.
  • the execution license and license templates attached to it will be delivered back to the customer for the use of the product as well as for ordering other products, their licenses, and continuation licenses.
  • New license templates can be delivered to the customers either directly or the customers can retrieve them along with the product data while using the trading center.
  • the manufacturer of the add-on product makes such a product, which will require acceptance from the producer of the base product.
  • the manufacturer of the add-on prod- uct will order the tools necessary for production, a product code and license templates matching the different licensing conditions of the add-on product from the manufacturer of the base product in the step 602.
  • the manufacturer of the base product allocates the codes in the step 603 and delivers the requested data to the manufacturer of the add-on product in the step 604.
  • the add-on product is not distributed from a trading center of the manufacturer of the base product, rather than the manufacturer of the add-on product acts as a reseller for the base product and for the add-on product.
  • the manufacturers of the base product and add-on product will make an agreement on selling and invoicing of the products in the step 605.
  • the manufacturer of the base product delivers in the step 606 the basic program, its trial licenses, and its license templates as well as trial licenses of the add-on product to the manufacturer of the add-on product.
  • the manufacturer of the add-on product can combine various products and their trial licenses, as practical, and deliver these product packages to the customers in step the 607.
  • a customer decides to buy in the step 608, he sends an order to the product distributor in the step 609, which includes a license request to the product and to the add-on product.
  • the distributor which in this embodiment is the producer of the add-on product, sends the license requests and pre-defined customer information to the producer of the base product in the step 610.
  • the manufacturer of the add-on product delivers in the step 611 the portion of license fees defined in the agreement to the manufacturer of the base product.
  • the manufacturer of the base product delivers customer-specific execution licenses for both the base and the add-on product in the step 612 and the manufacturer of the add-on product delivers the execution licenses further to the customer in the step 613.
  • FIG. 7 represents as a flow chart an embodiment, in which the usage of resources is controlled using two chosen constraints. The constraints taken here as examples are the amount of service requests per time unit and the number of concurrent users.
  • Figure 7 represents constraining capacity according to an advantageous embodiment of the invention.
  • information about constraints is read from the attributes of the license used.
  • the constraints can also be defined to be fixed for example in the memory unit of the system or in connection with an ap- plication, when they are in the step 701 read from their location, rather than from license's attributes.
  • the next phase 704 it is examined are there are limitations for the number of users assigned for the license.
  • a service request which contains user identifiers and possibly a capacity weight factor, which default value is one unit.
  • the tables created in the blocks 703 and 705 are pointed with the aid of an index pointer point- ing to them.
  • the block 708 it is checked, that only the number of actions permitted by the capacity constraints is taken within a specific time period.
  • the table can contain for example time-stamps, which are produced as one for each service request. Originally the user purchases, for example, a license for 12 service requests per minute (or alternatively a more expensive license for 36 service requests per minute).
  • the control moves to the block 710. If the time difference calculated from time stamps is less than the defined time limit i.e. an ex- tra service request is requested within 60 seconds, the control proceeds into the exception handling block 709. According to the instructions for exception handling the system can, for example, wait for a certain time, such as 10 seconds, and then re-process the same service request again or leave a service request unprocessed and to move over to process the next service request and/or to inform the main user about the situation.
  • the table created in the block 705 is inspected. In the block 711 it will be tested, whether new users will fit into the user table.
  • the user table contains for each user identification one row, which contains the time-stamp of the latest service request of that user. Because this time stamp changes along with a new service request of the same user, the order of the rows of the table may change often, because it typically is wanted to be maintained in the order of the time-stamps due to efficiency.
  • the block 711 there can be either changed the time-stamp of an ex- isting user in the table or added an user, if the number of the users in the table is smaller than the maximum number of users allowed, or a new user can be added, if the longest lasting user can be removed from the table, which requires that her time stamp is older than the session end delay defined.
  • information of the user table will be updated in the block 713, after which the system is ready to receive a new service request in the block 707. If a new user cannot be added, the operations defined by the instructions for exception handling are executed in the block 712, which corresponds to the exception handling proceeding executed in the block 709. After this the control is moved to the block 708 to inspect capacity constraints.
  • tables as the data structures to store the data.
  • other, more advanced solutions can be used, such as data structures based on linked records, in which the used amount of resources is recorded cumulatively into the records instead of using rows of a table.

Abstract

The invention relates to management of the use of digital data. Especially the inven-tion relates to management of the use of various digital resources and services as well as data communication connections by means of licensing. In a method accord-ing to the invention, in order to license digital resources and services, as a response to a requested licensing request, in a license request unit (103) handling license templates containing attributes, transforming a license template into a license re-quest by changing and/or adding attribute values (411) of a license template, where after the license request is transmitted to a specific license creation unit (102) han-dling license requests. In the license creation unit (102) transforming the license re-quest to an execution license by changing and/or adding attribute values (506) of the license request, from where the execution license is transmitted to a license control unit (105) controlling the usage of resources and/or services.

Description

A method and a system for licensing digital resources and services
The invention is related to management of the use of digital data. Especially this invention is related to management of the use of various digital products, services and data communication connections by means of licensing.
Management of the use of digital data, service and data connections and resource is an essential part of an operational system. In this application a resource refers to a physical operational unit or a system, that can be such as computer equipment or -software, functionality implemented by software, a set of articles in a database or data communication capacity. Thus, the resource implements a certain service, that can be such as operation implemented by hardware equipment or software, functionality of program or certain data communication capacity. Both of these are thus managed by using licenses, which define the rights to use the service implemented by a certain resource.
Publication US 5457746 presents a method and equipment, in which data published using various equipment is licensed. The publishing mean can be such as a CD- ROM (Compact Disk Read Only Memory), data contained in which is divided into sections, whose access is controlled. For charging these data sections billing options, also known as attributes, can be used. Controlling access to information in a data section is based on encryption of information contained in data sections so that its decryption requires a data section specific key. The characteristic features of the method presented in the publication are encryption of the data in the specific way, distribution of the data with certain mechanism and controlling the data usage with the aid of an update method. The presented method is limited to a use of encrypted data sections.
In publication WO 0054127 there is presented a method and equipment for binding resources to an application. As a basic mechanism there is used a public and a private key between two program modules. The invention is based on embedding the keys into software by means such that, the public key is integrated into the applica- tion and the private key into the resource. Also the method and equipment for licensing reusable program libraries presented in publication US 6188995 is based on keys. The use of these reusable software libraries is controlled from the application program so that a specific string grants the permission to the usage of the software library, if the user has the corresponding license key. It is typical for the known solutions to produce a detailed licensing system for a specific purpose, when new solutions and properties require their own systems. In the prior art publications there is commonly used some kind of encryption method in between the system and the resources, either keys or encryption of data for one section at a time. Controlling the licensing and the licensed services and resource is impractical and irritating for the users, due to which licensing is not used.
The aim of the invention is to produce a licensing system, which is extendable and modifiable. In addition, the aim of the invention is to diversify the properties and the use of the licenses so that accesses and functionality are easily and flexibly available and further extendable.
The aim is reached by using license templates for controllable and flexible creation of licenses. The license templates can be defined to match the respective requirements. In addition the license templates can be also modified later on, during the usage, and multiple templates with alternative scope can be used for a single re- source concurrently.
The invention is characterized in that what is stated in the characterizing part of the independent claims. Advantageous embodiments of the invention are described in dependent claims.
The execution licenses used according to the present invention are created using li- cense templates. The license templates contain variables, attributes, the aid of which the service or resource to be licensed will be defined on the license template. License templates are transmitted to the license request unit, in which the attributes of the license template are used for defining the target environment of the licensed service or resource and the license template is transformed into a license request. The license request will be handed over to a license creation unit, where, with the aid of attributes of the license request, constraints for the use of the licensable service or resource are defined, and the license request is transformed into an execution license. The execution license is next transmitted to a license control unit of the target environment, which controls the usage of the execution licenses, verifies that the constraints and the identifiers are valid, and is able to interpret execution licenses flexibly. Creation of the licenses can be centralized to a single site around a license creation unit or constituted functions can be distributed into each target environment as integrated packages. Alternative arrangements are scrutinized later on. Already existing licensed systems can be flexibly upgraded with new features, and the life cycle of a license can be managed by its attributes. Multiple parallel licenses can be granted for a single resource. In addition, licenses can easily be transmitted from equipment to another and be modified to be applicable into a system, some part of which will be changed. Because there exists a limited number of digital resources, they tolerate only a limited load. For example, a large number of concurrent users can overload an e-commerce site and bring the system down. According to an advantageous embodiment of the invention management of the digital resources is also ensuring the availability of services.
The end user will gain benefit from the licenses according to this invention by being able to get with them software and resources for trial use with low cost and later on it is easy to upgrade the licenses to full licenses. When needed, the user can also purchase extended continuation or features to the existing licenses. The licensing is comfortable and almost transparent to the user. To the manufacturer the licensing of the add-on products will clear up, because the manufacturer can control the use of the add-on products in addition to his core products. In addition, both manufacturers of the core product and the add-on product can simultaneously control the sales and use of certain licenses.
Next the invention will be described in greater detail with the aid of accompanying drawings, in which
Figure 1 illustrates a licensing system according to an advantageous embodiment of the present invention,
Figure 2 illustrates as a flow chart the operation of a license control unit according to an advantageous embodiment of the present invention,
Figure 3 illustrates an execution license according to an advantageous embodiment of the present invention,
Figure 4 illustrates as a flow chart the operation of a license request unit according to an advantageous embodiment of the present invention,
Figure 5 illustrates as a flow chart the operation of a license creation unit accord- ing to an advantageous embodiment of the present invention,
Figure 6 illustrates an arrangement for an electrical trading center according to an advantageous embodiment of the present invention, and Figure 7 illustrates as a flow chart the operation of a resource management system according to an advantageous embodiment of the present invention.
Figure 1 illustrates a licensing system according to an advantageous embodiment of the present invention, in which licensing system all components can be located for a use of a set of computers using a specific www server or for a use of a LAN server and its clients. According to another advantageous embodiment the components illustrated in figure 1 can be located in a single computer or in an UMTS phone (Universal Mobile Telecommunications Services). The licensing system illustrated in figure 1 can also, according to an advantageous embodiment, be distributed into the execution environment, i.e. part of components can be connected to the target environment for example, via data communication connection. The target environment includes all the equipment and components, which communicate with the license control unit 104. License control unit 104 thus defines the target environment so that the target environment includes those components and equipment, which use the license control unit in question in order to get a right to use some resource or service controlled by licenses. In target environment there are at least an execution license, a license control unit and some software or resource. According to an advantageous embodiment the license control unit 104 and the unit using the service (using unit) 105 have been integrated into a single uniform component. The integra- tion ensures uniform operation of the using unit 105 and the license control unit 104, and it is not possible, for example, to implement a false license control unit in between the components of the integrated system, which would accept every license to a specific target environment.
If the using unit 105 is for example a LAN server's terminal, which wishes to open a known text processing program, for example MS Word text processing program registered by Microsoft, the terminal will request a permission to use this program from the license control unit 104. The license control unit 104 searches for the license of the program to be started for example from a database, in which a license registry is maintained. This data structure can be located in the central memory or mass storage 108 of the using unit 105. If the license control unit 104 finds a valid license for the resource in question and recognizes the requesting terminal, the license control unit 104 will grant a permission to start the program in the terminal after checking first that the conditions of the license are fulfilled. The license contains attributes, whose values define, for example, the valid execution environment of the license. The license attributes will be scrutinized more closely with figure 3. The using unit 105 can also according to an advantageous embodiment request a to- tally new license. In this embodiment the license control unit 104 and the license request unit 103 are situated advantageously in the same equipment or in the same server as the using unit 105. The using unit 105 thus wants to use a new resource or service and request a license from the license request unit 103.
A license template is handed over to the license request unit 103 with the request. The license template identifies the service or resource requested. The license templates are typically application-specific i.e. for each service or product to be licensed there typically exists a specific license template. According to an advantageous embodiment of the invention license templates are produced in a license tem- plate unit 101. The license templates can be produced also by other methods known as such and those can be brought to the use of a licensing system according to an advantageous embodiment of the invention for example via data communication connection or a physical memory device, such as a floppy disk or a CD-ROM or the license templates can be retrieved from network from a server. I.e/, the resource or service to be licensed is defined in the license template. The manufacturer typically controls and produces these license templates. Whereas execution licenses are controlled and produced by the manufacturer or (re-) seller of the product or service. For example a license template can define, that the product to be licensed is a text processing program and the production and availability of the license templates can be arranged by the party selling the licensed rights to use.
The target environment of the requested license is defined into the license template in the license request unit 103, for example by defining the terminal, in which this license is requested to be used. In addition, the license template is transformed into a license request. A license template and a license request are states of the license, phases of its life-cycle, that are defined in the license like other variables: by changing attributes of the license.
From the license request unit 103 the license request are transmitted to the license creation unit 102 either via a data communication connection, via shared memory, or using some similar mechanism or memory device, such as a floppy disk or alike. Advantageously the license creation unit 102 uses the same memory unit 107 as the license template unit 101. This way the license creation unit 102 is able to access the license template defining a resource or a service directly from the memory unit 107, where to for example the license template unit 101 has stored it. The license creation unit 102 can attach license templates to the execution license it produced, so that those are delivered with the execution license to a user or to a using application. For example a short-term trial license can be attached with a license template for a long-term execution license, thus enabling the user after experimenting the product with the trial license easily order an execution license.
The license creation unit 102 maintains bookkeeping of licenses and assigns specific constraints to the licenses, typical of which are such as duration of the license and the number of concurrent users. In addition, the license creation unit 102 changes the state of the license from license request to execution license by changing the attribute values of the license request. In the case mentioned as an example, when the product to be licensed is a word processing program, the target environment of the license can be defined to be for example an individual computer or a network server, where upon the license can be used by a terminal equipment of the network. Advantageously the license creation unit 102 is located in equipment of a party selling rights to use the product.
The execution license produced by the license creation unit 102 and the license templates possibly attached to it are delivered using a data communication connec- tion or a physical portable memory device into the target environment, in which the execution license is requested to be used and which has been defined in the execution license. In the target environment the execution license will be installed by using a set-up program into a file, registry or some similar data structure located in the mass storage 108. The mass storage 108 stores for example programs and other in- formation needed in licensing. Typically the system has also central memory, in which a run-time version of the license is preferably stored. The central memory is preferably a part of the unit 105 using a resource or a service licensed, and it is not separately described in figure 1.
In a single physical network there can co-exist multiple license control units 104 and target environments defined by the license control units 104. For example one target environment can consist of the network and terminals defined by the license control unit 104, in such a way, that the license of a word processing program is located on a server, where from a number - defined in the license - of network terminals can execute it concurrently with the permission of the license control unit 104. The license control unit 104 it thus monitoring the permitted use of the licenses. The license control unit 104 interprets execution licenses very flexibly, which means that, in execution licenses managed by a specific license control unit 104 the number of attributes may vary or the right to use a specific resource or service can be granted based on execution licenses, which have different number or dissimilar attributes. In addition, the attributes can have multiple values or a single license control unit 104 can interpret execution licenses of multiple separate resource or service.
In a network another additional license control unit can be installed to the same computer for example for a licensed service, to be used only in that computer, which can be such as a bookkeeping and accounting program. Permission from the license control unit 104 is needed for use of a licensed resource 106. The used resources 106 are located typically in the target environment, but they can also be located beyond a communication link. Advantageously also the license request unit 103 is located in the target environment or at least the parts of it necessary for iden- tification of the target environment.
According to another advantageous embodiment the components necessary for the licensing system can be located in a single equipment, for example in an UMTS phone, which thus in this case is the target environment. I.e., in the target environment there are the using unit, the license request unit 103, the license creation unit 102 and the license control unit 104 and the necessary memory units 107,108. In this case the license creation unit 102 can create a connection to a payment system, for example into a charged service number or to a similar charged direct debit system. The user must pay the fee before the execution license he requested can be created. After the payment the license creation unit 102 can, for example, produce an execution license for a translation program so that the right of use is valid for a half an hour. This way the user gains access to a specific product or service for the time requested as a response to the pre-payment. According to another advantageous embodiment similar services or resources can be used as agreed either as a response to a monthly fee or so that the active time of use is charged.
Figure 2 illustrates as a flow chart operation of a license control unit according to an advantageous embodiment of the present invention. In the initial state 201 the license control unit is ready for action. In block 202 the licenses located in a specific or even in multiple memory units are read and the licenses are decrypted, if encryption has been used. After this the check sums 203 of the licenses are calculated with some method known as such. By check sum 203 the integrity of the licenses is ensured. In addition, in this block 203 the conditions and constraints of the license, such as the validity period and identifiers of the target environment, will be validated at the time being in the target environment of this license control unit.
In block 204 a service request or a new license is received. A new license 205 is re- ceived, when a user, an application, or equipment wants to use some new service and/or resource and the use requires licensing the service and/or resource. When the license control unit receives a service request 205, the requesting party wants to use some existing license. The service request will be received when the license control unit is requested a permission for executing a licensed service or resource. In case of a new license 205, the control moves to the block 202, where after the attributes of the new license will be inspected to verify at least, that the licensing period is valid and in the target environment in question. In addition, the possible encryption of the license is decrypted. If the received message is a service request 205, the control moves to the block 206, in which the license control functionality will be acti- vated. The service request will be received and the license control functionality will be activated when a user or a system wants to use a specific resource or service, for example when the user wants to start a word processing program with an license at his device, which is connected to a specific local network. Other similar resource or service can be such as launching some system; I/O functions of a system, such as opening, reading, changing, or otherwise handling files, databases, or parts of them; reservation or use of data communication capacity from a specific data communication resource; initiating a specific function or functionality; establishing a new session or a work-space; or logging in a new concurrent user. Activating a specific service can include parameters describing its usage, such as the location of the target, the volume or intensity of use, that are identified in license's attributes, so that they can be utilized in controlling the licenses. The license control unit can be activated in several separate ways, for example a system can activate the license control unit by sending to it a signaling message either prior to use of a resource, while monitoring its own operation, periodically or randomly; or hardware or software of system platform can activate the license control unit by signaling; or the license control unit can monitor signals of the system platform, such as operating system's messages, interrupt signals or messages of a data communication software, and activate itself when defined conditions are met.
Signals of the system platform, that can be monitored and whose occurrence will initiate the license validation described above, include for example, common services of the target environment, such as remote procedure call, for example DCOM (Distributed Component Object Model), a service request, for example ORB (Object Request Broker), Microsoft Windows message, paging request of an operating system, service request of the file system, or other similar mechanism that is inde- pendent from the using system. When the license control unit has been activated for the use of a specific resource or a service, it will also check in block 206, which licenses are valid for the resource or service in question. Conditions of the valid licenses are presented in license's attributes. Different licenses and their contents will be scrutinized later in this applica- tion with the figure 3. If the license was found and the conditions and possible constraints defined in license's attributes are fulfilled 207, necessary bookkeeping tasks will be performed and the service request will be executed in block 208, i.e. access to the requested resource or service is provided. With the bookkeeping tasks we mean for example that information about the current status of the license, number of its users and duration of the usage are stored into the registry maintaining license information. What kind of information is stored at each times, depends on properties of the license and the license control unit. After this the execution moves to the block 204. If no valid license is found in the block 207, instructions for exception handling will be searched 209 for a resource or a service in question. If instructions for the exception 209 were found, the unit defined by the instructions for exception handling, which can be, for example, the license control unit or a specific program of the system, executes the operations defined by the instructions for exception handling 211. If instructions for exception handling are not found 209, pre-defined default operations 210 are executed. After executing these default operations 210 or exception handling operations 211 the execution moves to the receive block 204.
The instructions for exception handling define policies i.e. alternative actions to be taken in the target environment when the conditions defined by the license's attributes are not fulfilled or the license is not integrity or some other expectable possible exception is observed. Instructions for exception handling define, thus, how to pro- ceed, when the license control unit observes problems. The perceived problem can be such that license's ending condition, for example time, has been reached or the license has too much users or load. Some times no license will be found for a service or the check-sum does not match. In the perceived exception the exception handling operations to be carried out can be such that the operation is interrupted, when the requested service will not be started, and no access to the resource will be provided. In some cases the exception is simply reported to the user or to the vendor of the resource and the operation is continued, for example in according to an old or a trial license. Reports on exception can also be done periodically or the reports can be directed to a log and the service request in hand can be bypassed. In some cases the resource to be used is deleted from the target environment. Often the user is provided a possibility to order a new license or to continue operation in the restricted trial mode. The possible exceptions and the exception handling operations to be taken following them are defined in the so-called license schema, based on which the license templates are produced. Specific exception handling codes, which can be used in the licenses controlled by this license control unit, are transmitted to the license control unit. These exceptions handling codes can be for example procedure calls. Then for possible exceptions there are defined exception handling codes to each license, and the exception handling codes to be applied when the exceptions appear. Thus, the license control unit has a set of pre-defined exception handling codes, out of which the ones to be used are chosen product-specific. As examples there can be mentioned some typical exceptions and possible exception handling instructions for those: When the period of the execution license is over i.e. the license has outdated, the situation is reported to the user and a temporary license is taken to use or the execution is terminated. When the limit of concurrent users is exceeded i.e. the license has too many users, the last service request is by-passed and the situation will be reported to target environment logs and/or to the vendor of the resource. If a defined capacity constraint is exceeded i.e. there is an overload situation, the situation is reported to the user and the service request will be by-passed. If there is an attempt to start a service, to which there is no license, the execution will be stopped and the user can, for example, be offered a trial license to that service. Unauthorized use, when the check-sum is invalid or a decryption fails, is typically reported to the vendor of a resource or a service.
In figure 3 there is an execution license according to an advantageous embodiment of the present invention, which comprises a header 310, a body 320 and a checksum 330. In the header 310 of the execution license there is a version number 311 of the license schema used by the licensing system and possibly some additional data 312, such as disposable key data used for encryption and decryption or seed data of a key generator. The data contained in the license can be encrypted for example with some public key, by using changing data of the license to form a key or by encoding the data with numbers or symbols or by replacing the characters with some others. The license schema defines the set of the attributes, which can be used in a license template. The license schema is thus a kind of basic structure of the license template, out of which the license template itself will be modified. A license schema can be, for example, as follows:
Figure imgf000011_0001
Figure imgf000012_0001
There is a version number in the first row of the license schema. This number is the same for all license templates, which have been created based on this version of the license schema. The same license schema version number exists also in such a li- cense template, in which only a part of the definitions of the license schema are in use. For example using the license schema presented above we can create a license template of the specific word processing program for a single user, in which case the number of concurrent users in the bottom is not needed at all. The version number of the license schema is also in this kind of license template 1.1. If into the li- cense template there needs to be defined a new variable (i.e. attribute), for example duration of the session, the version number of the license schema will be changed. Even in this case not all of the data in the license schema has to be defined. It is defined in the heuristics of the license control unit, which data of the license schema at least has to be defined. Typically compulsory variables of a license schema are product code, identifier of a target environment and duration of a license. In the preceding presented license schema the product code is represented in a textual format and it can be, for example, "MS Word" registered by Microsoft, as a target environment identifier there is a processor identifier (CPUID), which is represented as a 12-digit integer and start and end times of license usage are represented in the preceding license schema in date format. Times can naturally be represented also in time format.
The execution license contains always the body 320 with a group of attributes, which each have a single or multiple values, which describe information necessary for licensing. Examples of this information have been listed next with references to numbers in figure 3. The body 320 typically contains identification information, such as an identifier of the product, an identifier of an execution license and instructions for exception handling, which define, what to do in various exception situations. Figure 3 illustrates as an identifier of a target environment an identifier of a processor 321. Similar identifier binding a license to a target environment can be an identifier of a network card, a hard disk, a data communication connection or a similar component. These identifiers define one or more equipment or processor as a target environment, in which the license can be used. In addition, in the body 320 there is product information, for example information about which resource, service or function is licensed with this execution license. Such product information can be, for example, a product number or a name of a product. There can also be more than one value in a value list of an attribute, such as a list of identifiers of licensed sub- resources, that can be, for example, parts of a data base or specific services, or a list of such license template identifiers, that are typically next offered for the user. In body 320 there is, in addition, information about the constraints of the use of the license 322, such as how long or until when the license is valid or how many service requests are accepted. Further, in the body 320 there are instructions for exceptional situations (i.e. violation policies) 323. These instructions determine, what to do for example in cases where there is an attempt to execute the license in a wrong target environment, the validity period of the license runs out, the number of allowed concurrent users is exceeded or the data structure of the license is found to be inconsistent.
The license can also contain an attribute controlling the integrity of the license, i.e. a check-sum or some similar figure 330 applicable for integrity checking. Integrity of license's attributes and their values can be controlled with specific integrity instructions. These instructions define interrelationships in between the attributes and their values, which an external party cannot deduce only by inspecting the license. Cryptographic methods for checking the integrity and the origin of a digital message by using various check-sums and digital signatures are known as such and those can be used also as a part of the present invention especially for ensuring the integrity of the data in the body.
In addition to the elements represented in figure 3 the license can contain information about the present status of the license, for example, in which stage of the life- cycle the license is. For example a license can be obsolete or removed after the use, which corresponds to a so-called final state of a license. A license can still contain information about the licensing process. Based on this information there can be reasoned for example, which license templates should be offered next to the owner of this license. A license template contains also data about continuation licenses. Along with a license request, information about possible continuation licenses is passed to the license creation unit, which will deliver the necessary continuation license templates along with the execution license into the target environment. In addition to the execution license represented in figure 3 there exists transfer licenses, which are needed, when the target environment - or a part of it, such as the target computer - needs to be changed. An existing execution license can be transferred from one execution environment to another by using a transfer license for ex- ample, in cases, when equipment of a target environment will be changed so that the identifier of the target environment of the old license 321 is no longer valid in the new equipment. If for example, in the case in figure 3 a processor, which has been defined with the target environment identifier 321, will be replaced with a new one, the license will not be valid in a new environment. A transfer license is produced by a license request unit, whose operation will be scrutinized in greater detail with figure 4 later in this application. A transfer license will be produced roughly as follows: the license request unit converts an existing execution license into a temporary execution license. The temporary execution license will be functional for a limited period of time in its original target environment. In addition, the license request unit will produce a transfer license, which is a special license template, into which the attributes of the original execution license have been copied. The license request unit will form a license request, which contains relevant attribute knowledge of both the new, requested license and the old execution license via the transfer license. The license request will be processed in general in the same way as other license re- quests, which are scrutinized later in this application.
A trial license (or a demonstration license) is yet another commonly used form of a license. The trial licenses provide a limited functionality or duration. All licenses follow the outline of the structure represented in figure 3. Typically there are differences in the state attributes of different kinds of licenses and different number of at- tribute values may be filled in them. In some cases new attributes can be added to the licenses.
New license templates are created for example, in a specific license template unit based on a specific license schema. The license template unit is advantageously using the same mass storage as the license creation unit, in order to keep the informa- tion exchange in between them as flexible as possible. The used license schema defines the attributes used in licenses 321, 322, 323 and possibly also their value domains. Adding a new attribute to a license schema will cause a change to a license schema version number 311. The version number 311 will be changed into a license template only if it is necessary, which is, only if the license template uses attributes missing or changed from an older schema. The license schema version number 311, is in a header 310 of license templates, and thus also in license requests and execu- tion licenses. From a version number 311 a license control unit gets the schema version, which it must be able to interpret in order to interpret the data of the execution license correctly (for example, the block 206 in figure 2). If the license control unit is not able to interpret the version number 311, for example, because it is so new, the license control unit acts according to the exception handling instructions addressed to it (figure 2, block 211). In the instructions for exception handling there usually exists specific instructions to such exceptions, in which the version number 311 is not recognized, i.e. a violation policy for unrecognized schema version. In this case the instruction for exception handling can, for example, define, that the li- cense control unit should order a newer version of the license control unit via data communication connection, inform the user and suspend execution or execute the license only in a mode of restricted use and inform the user about this. The operation will follow the instruction for exception handling defined in the license template, which is copied into an execution license. An implementation of the instruc- tion for exception handling is programmed into a license control unit, and if it is missing a default procedure is followed. According to an advantageous embodiment the license request unit notices situations, in which the license control unit is not able to recognize an execution license following a license request or a license template. The license request unit can react to this for example, by ordering a new ver- sion of a license control unit, by preventing creation of a license request or by informing the license creation unit.
The license templates are similar as the execution license represented in figure 3, only some of the attribute values are missing. Typically the attribute values binding the execution license to the target environment and limiting the validity of the li- cense are missing from the license templates. The license templates are typically stored in the mass storage of the system or in central memory. Alternatively temporary license templates can be accessed via a data communication connection. The licensing system accesses license templates typically through Internet services. For example, new license templates and continuation license templates can be loaded from the net. Continuation license templates include for example own template of a temporal execution license for a following period of use, a license template for permanent use and a license template providing an additional feature. Along with a resource or a service it is possible to deliver license templates for a permanent license and for a temporal license. In addition for trial use it is possible to deliver also trial licenses, which are execution licenses with limited validity period. The attribute defining the last validity date of a trial license is typically set while setting up the resource, whose usage it will control. This means, that after the first installation of a product its license will be valid for a specific, pre-defined time period.
The figure 4 scrutinizes operation of a license request unit as a flow chart. First data of licenses already existing in a target environment is read 401. After this integrity of the execution licenses and fulfillment of the license conditions are inspected 402. Next information about the existing licenses is presented to the user and new products are offered 403. The license request unit has some kind of user interface for the user or a corresponding software interface to applications, through which the licenses are presented. In this block 403 a list of all execution, trial, transfer, and ob- solete licenses read in block 401 as well as a list of license templates are presented to the user.
In the block 404 the user can order a new license. If the user does not want to order a new license 404, he can choose in the block 405, that he stops the execution 406 or he may resume the execution, where after the control moves to the block 403. If the user orders a new license 404, the information of a chosen license template is represented to him in the block 407. The license template information has been collected from attributes defined by the license schema and/or from separate data. The license template is application-specific and defines the product to be licensed. In addition it is possible, for example, to link descriptive data to the license templates using identifiers, which can be in textual or hypertext format. In the block 408 it is confirmed from the user, whether the chosen license is ordered. If the user cancels the order, the execution of the program moves into the block 403. If the license order is confirmed, the program verifies, that it has sufficient information for the delivery and invoicing of the order 409. If not all customer or payment data exist, the user is requested to complete the missing data 410.
The license request unit fills, in the block 411, the attribute values needed for the license template, such as identifier of the target environment and changes its state from a license template to a license request. In the block 412 a possible check-sum is calculated and when necessary the license request is encrypted. Next, the exis- tence of a data communication connection, such as a TCP/IP (Transmission Control Protocol / Internet Protocol), RPC (Remote Procedure Call) or a shared memory location, to the license creation unit is checked 413. If a data communication connection cannot be established, the license request can be delivered for example on a diskette to the license creation unit and the user will be given instructions for deliv- ery 415. If a data communication link can be established, the license request will be sent or handed over through the data communication link to the license creation unit 414.
The requested license request will be delivered to the license creation unit, whose operation is described in the flow chart 5. The license creation unit receives the li- cense request, reads it 501 and decrypts a possible encryption. Next the integrity of the received license request will be checked with the aid of the check sum as well as the applicability of the attributes and payment and order information 502. In the block 503 the invoicing transaction necessary for the requested license is performed for example through a network using some existing payment system or by passing invoicing information forwards for manual invoicing. In the block 504 there occurs a check, whether all the actions taken so far have been successful. If some previous action has failed, the problem is reported to the user 505 and execution of the program will be stopped 513. If the handling has worked out without problems, the execution will move to the block 506, in which the system completes and changes values of specific attributes of the license request. In this phase for example the end time of the license will be added as an attribute and the state will be changed from the state license request to the state execution license. Next possible check-sums are produced to the execution license and if needed, the data will be encrypted 507.
Bookkeeping data of licenses is recorded to a license database 508, which contains information of all licenses. In the block 509 the execution license is further attached with templates of products of interest from the viewpoint of the execution license user and descriptions of the products, after which they are available for the license request unit (presented in figure 4). If a data communication connection exists or can be established in between the license creation unit and the target environment 510, the license creation unit sends the executions licenses, attached license templates and their descriptive information through the data communication connection to the license control unit located in the target environment. In the target environment the execution licenses are typically stored into the mass storage or in a short- term use into the central memory used by the license control unit (presented in fig- ure 2). If a data communication connection cannot be established 510, instructions will be given 511 for delivering the license information manually, for example using a diskette or a CD-ROM disk. When the execution license has been delivered 512 or instructions for delivering it have been given 511, the execution of the program is stopped 513.
It is possible to locate a license creation unit even to multiple locations. The advantageous embodiment described in previous with figure 5 is a typical solution, in which the license creation unit is located in possession of the organization delivering the software, hardware, system or other resource and/or system used, apart from the target environment of the licenses. According to another advantageous embodiment the license creation unit is located in the target environment together with the license control unit. Operation of a license creation unit according to this other advantageous embodiment is similar to the operation of the embodiment presented in previous in figure 5 otherwise, but now it is supposed, that the license creation unit is able to verify the data of the payment system about the license payment transaction without user interaction in the block 503 of figure 5. This further assumes that there exists a data communication connection. Neither a license creation unit located according to this other advantageous embodiment does have the opportunity, in case of the absence of an applicable data communication connection, to update information to the license database 508. Thus according to this other advantageous embodiment, licenses and usage monitoring data will be transmitted via a data communication connection, when possible. In the same way the product descriptions 509 and license templates to be attached to a complete execution license are retrieved through some data communication connection and they are stored to the target environment for a sufficient period of time, for example into the mass storage or for a session to the central memory of the license request unit, from which they can be taken to use in the beginning of each session. This other advantageous embodiment is useful for example, in cases, when the target environment is a portable equipment and charging is taken care of for example, by calling charged service numbers.
According to a third advantageous embodiment of the invention a license creation unit is located in an entirely separate system, such as in an e-commerce site in the Internet or in another electronic trading center. In this case an electronic payment system is integrated with the license creation unit as well as often a possibility to load license templates and product data of new products to the target environment. Advantageously this is combined also with downloading of software resources with their trial licenses from the same system. According to this embodiment an electronic trading center can distribute free trial licenses, which the users can easily extend by buying more resources, duration or sessions. A customer uses an electronic connection to the trading center and a licensing system, payment system, as well as their data connections are located within the trading center. After finding an appli- cable product the customer can order a trial version of the product, which can thus be free or a charged product, such as an inexpensive demonstration version, evaluation version intended for trial use, a version with less functions or a sponsored ver- sion with advertisements. The product, which can be a software or some other resource, will typically be delivered using a data communication connection, but it can alternatively be delivered, for example, on a CD-ROM or on a DVD (digital versatile disk). The product delivery comprises advantageously the software or other resource, a trial license providing limited functionality, and a license template for the use of the chargeable product itself. In addition the delivery can comprise a license control unit, a license request unit, and a user interface needed for licensing, unless these are implemented on a trading center.
When the customer decides to order a product, the order will be made using the li- cense request unit. The license request unit will produce a license request, which is delivered via an established data communication connection to the electronic trading center. License creation unit integrated to the trading center creates an execution license from the license request and takes care of the payment transactions with a method known as such. The execution license and license templates attached to it will be delivered back to the customer for the use of the product as well as for ordering other products, their licenses, and continuation licenses. New license templates can be delivered to the customers either directly or the customers can retrieve them along with the product data while using the trading center.
Let us now scrutinize the arrangement of figure 6, in which there is licensed an add- on product, whose manufacturer is different from the manufacturer of the base product. With licensing systems according to prior art commercial utilization of add-on products build on top of a base product, such as macro packages, is difficult from the viewpoint of both the manufacturer of the base product and the manufacturer of the add-on product. In this embodiment the manufacturer of the add-on product can act as a dealer for both the base product and the add-on product. Thus it must be ensured, that the manufacturer of the base product will get the agreed shares of the license fees. Respectively this arrangement according to this embodiment can be used when an add-on product is offered for sale in a trading center, when there is applied to the add-on-product similar licensing arrangements as to the base product. With this arrangement according to this embodiment both parties are able to control their own fees and product sales figures.
In the embodiment represented in the figure 6 in the step 601 the manufacturer of the add-on product makes such a product, which will require acceptance from the producer of the base product. For this purpose the manufacturer of the add-on prod- uct will order the tools necessary for production, a product code and license templates matching the different licensing conditions of the add-on product from the manufacturer of the base product in the step 602. The manufacturer of the base product allocates the codes in the step 603 and delivers the requested data to the manufacturer of the add-on product in the step 604. In the embodiment represented in the figure 6, the add-on product is not distributed from a trading center of the manufacturer of the base product, rather than the manufacturer of the add-on product acts as a reseller for the base product and for the add-on product. The manufacturers of the base product and add-on product will make an agreement on selling and invoicing of the products in the step 605.
The manufacturer of the base product delivers in the step 606 the basic program, its trial licenses, and its license templates as well as trial licenses of the add-on product to the manufacturer of the add-on product. The manufacturer of the add-on product can combine various products and their trial licenses, as practical, and deliver these product packages to the customers in step the 607. When a customer decides to buy in the step 608, he sends an order to the product distributor in the step 609, which includes a license request to the product and to the add-on product. The distributor, which in this embodiment is the producer of the add-on product, sends the license requests and pre-defined customer information to the producer of the base product in the step 610. In addition the manufacturer of the add-on product delivers in the step 611 the portion of license fees defined in the agreement to the manufacturer of the base product. For his part the manufacturer of the base product delivers customer-specific execution licenses for both the base and the add-on product in the step 612 and the manufacturer of the add-on product delivers the execution licenses further to the customer in the step 613.
Another advantageous embodiment of the invention relates to capacity constraints of a system. With the aid of capacity constraints it can be ensured, that a customer does not, without permission, take to use more services or resources to use than he is entitled to. For example the number of users has to stay within the limits of the license conditions, and no extra concurrent users are allowed. In addition, with the aid of capacity constraints a fixed amount of resources can be ensured to multiple users without a single user consuming all the capacity. In addition, with the aid of capacity constraints we can prohibit the situation where a large number of service requests will overload server resources causing system failure. Figure 7 represents as a flow chart an embodiment, in which the usage of resources is controlled using two chosen constraints. The constraints taken here as examples are the amount of service requests per time unit and the number of concurrent users. In addition or instead of these for example following data can be used in various constraints: user identifier, product code, capacity of a service request, or classification of the resource used. In addition, for example when inspecting service request per time unit there can be assigned to the service requests weighing coefficients defined using the service request an/or its variables. For example LAN and Internet users can have a different weighing coefficients.
Figure 7 represents constraining capacity according to an advantageous embodiment of the invention. With the startup, in the block 701, information about constraints is read from the attributes of the license used. The constraints can also be defined to be fixed for example in the memory unit of the system or in connection with an ap- plication, when they are in the step 701 read from their location, rather than from license's attributes. First it will be examined, are there set any capacity or time constraints 702. If constraints are found, in the step 703 there is created a table with an index column and a value column. The table can be located in the central memory of a server or a computer using the resource, from which the license control unit can use it. In the next phase 704 it is examined, are there are limitations for the number of users assigned for the license. If constraints were observed, another table will be created into the central memory in phase 705, which in this case has in addition to the index column and the value column, an identifier column for user identification. Created tables are referred using index pointers referring to the index column. In the block 706 the tables are initialized with the indexes and limits read from the license's attributes.
In the block 707 there is received a service request, which contains user identifiers and possibly a capacity weight factor, which default value is one unit. The tables created in the blocks 703 and 705 are pointed with the aid of an index pointer point- ing to them. In the block 708 it is checked, that only the number of actions permitted by the capacity constraints is taken within a specific time period. The table can contain for example time-stamps, which are produced as one for each service request. Originally the user purchases, for example, a license for 12 service requests per minute (or alternatively a more expensive license for 36 service requests per minute). From the time stamp of a new service request is subtracted the timestamp in 12 (or 36) index locations prior to this one - producing the time during which last 12 (or 36) service requests have been executed. If the resulting time is according to this example, more than 60 seconds, the control moves to the block 710. If the time difference calculated from time stamps is less than the defined time limit i.e. an ex- tra service request is requested within 60 seconds, the control proceeds into the exception handling block 709. According to the instructions for exception handling the system can, for example, wait for a certain time, such as 10 seconds, and then re-process the same service request again or leave a service request unprocessed and to move over to process the next service request and/or to inform the main user about the situation.
If the number of service requests per unit of time according to the capacity constraints was not exceeded, control moves to the block 710, where to the position of the table pointed by the index pointer is set the current time produced by the clock circuit. If the capacity load of the service request is greater than one, also the next table position is filled with the same time-stamp. The capacity load of the service request defines the number of positions to be filled. The index pointer is moved to point the table position next to previously filled. If the table is full, the operation will proceed normally from the beginning of the table.
In the block 711 the table created in the block 705 is inspected. In the block 711 it will be tested, whether new users will fit into the user table. The user table contains for each user identification one row, which contains the time-stamp of the latest service request of that user. Because this time stamp changes along with a new service request of the same user, the order of the rows of the table may change often, because it typically is wanted to be maintained in the order of the time-stamps due to efficiency. In the block 711 there can be either changed the time-stamp of an ex- isting user in the table or added an user, if the number of the users in the table is smaller than the maximum number of users allowed, or a new user can be added, if the longest lasting user can be removed from the table, which requires that her time stamp is older than the session end delay defined. After this, information of the user table will be updated in the block 713, after which the system is ready to receive a new service request in the block 707. If a new user cannot be added, the operations defined by the instructions for exception handling are executed in the block 712, which corresponds to the exception handling proceeding executed in the block 709. After this the control is moved to the block 708 to inspect capacity constraints. In the embodiment presented here there are used tables as the data structures to store the data. Instead of tables, other, more advanced solutions can be used, such as data structures based on linked records, in which the used amount of resources is recorded cumulatively into the records instead of using rows of a table.

Claims

Claims
1. A method for licensing digital resources and services, characterized in that the method comprises the steps of:
- as a response to a licensing request, transforming a license template into a license request by changing and/or adding (411) attribute values in a license request unit
(103) handling license templates containing attributes, and transmitting (414) the formed license request to a license creation unit (102) processing license requests,
- in the license creation unit (102) transforming the license request into an execution license by changing and/or adding attribute values of the license request (506) and transmitting (512) the execution license to a license control unit (104) controlling the use of resources and/or services.
2. A method according to claim 1, characterized in that it comprises steps of:
- activating a certain license control unit (104) as a response to receiving an activating service request directed to a resource or a service (205),
- interpreting execution licenses of multiple services and/or resources in the certain license control unit (104), and
- controlling in the certain license control unit (104) on the basis of the attribute values of the execution licenses the operation of licensed services and/or resources and activating service requests (206) directed to them.
3. A method according to claim 1, characterized in that concurrent execution licenses controlled by a certain license control unit (104) directed to a certain service and/or resource contain different number of attributes and/or different attribute values and/or multiple values for certain attributes.
4. A method according to claim 1, characterized in that it comprises a step of defining by the attribute values of an execution license at least a version number of a license schema (311), a target environment of the execution license (321), an identifier of the licensed resource or service, and constraints of the execution license
(322).
5. A method according to claim 1, characterized in that it comprises steps of recognizing a set of pre-defined exceptional situations in the license control unit (104) and activating the instructions for exception handling (211) defined by the attribute values of the execution license in each of the exceptional situations.
6. A method as according to claim 5, characterized in that it comprises steps of observing, based on the version number of a license schema of a license template, in the license request unit (103), situations, where there is no capability in the license control unit (104) to interpret attributes of an execution license, and as a response to the observation, in the license request unit (103), executing a pre-defined instruction for exception handling.
7. A method according to claim 1, characterized in that it comprises a step of defining in addition integrity constraints limiting interrelationships between attributes for attribute values of an execution license or a check-sum (330) describing the integrity of attributes and/or a step of encrypting (312) part of a content of an execution license.
8. A method according to claim 1, characterized in that it comprises a step of combining, in the license request unit (103),
- data of a license template containing attribute values defining the product and being interpretable by an license control unit (104), and
- certain values built-up from the target environment
into a license request (411), which is transmitted to the license creation unit (414).
9. A method according to claim 1, characterized in that it comprises steps of transforming, in the license creation unit (102), a state-attribute from a license request state to an execution license state by changing attribute values (506), attaching (509) to the defined execution license certain license templates and product descriptions, which are usable by the license request unit (103), and transmitting the execu- tion license with the attachments to the license control unit (104) of the target environment.
10. A method according to claim 1, characterized in that with the attributes of the execution licenses there is defined constraints for limiting the use of a resource or a service.
11. A method according to claim 1, characterized in that it comprises steps of transmitting the license request through a data communication link to the license creation unit (102), which is integrated to a certain electronic trading center, and transmitting the execution license created in the license creation unit (102) through an electronic trading center to a customer.
12. A method according to claim 1, characterized in that it comprises a step of transmitting customer-specific execution licenses (612, 613) as a response to a transmitted license request and customer data.
13. A method according to claim 12, characterized in that the licensed services and/or resources, and their customer-specific execution licenses (612, 613) are controlled by two or more manufacturers and/or distributors.
14. A method according to claim 1, characterized in that the steps as a response to a presented licensing request are executed automatically, mechanically and the handled attributes and attribute values of each of the steps are at a range interpret- able by a license control unit (104).
15. A system for licensing digital resources and services, characterized in that the system comprises
- a license request unit (103) for transforming license templates into license requests by changing and/or adding attribute values contained in those,
- a license creation unit (102) for transforming license requests into execution licenses by changing and/or adding attribute values contained in those, and
- a license control unit (104) for controlling the execution licenses based on attribute values contained in those.
16. A system according to claim 15, characterized in that an execution license is a full license for making use of the whole resource or service; a limited license, a trial license, an evaluation license, or a temporal license for limiting the usage; a transfer license for transferring an execution license to another execution environ- ment; a continuation license or an add-on product license for extending the functionality.
17. A system according to claim 15, characterized in that the system comprises in addition, a license template unit (101) for creating license templates based on a license schema defining an attribute.
18. A system according to claim 15, characterized in that the execution license comprises a version number (311) of a license schema and data about a product or a service to be licensed, a license type, a target environment (321), constraints of the execution license (322), and instructions for exception handling (323).
19. A system according to claim 15, characterized in that the license request unit
(103) comprises means for establishing a data communication connection to the li- cense creation unit (102) for transmitting license requests.
20. A system according to claim 15, characterized in that the license creation unit (102) comprises means for recording a produced execution license into a data structure and/or for storing it in a mass memory.
21. A system according to claim 15, characterized in that the license creation unit (102) comprises means for establishing a data communication connection for transmitting an execution license to the license control unit (104).
22. A system according to claim 15, characterized in that the license creation unit (102) comprises means for establishing a data communication connection to a payment system for paying the license fees.
23. A system according to claim 15 or 22, characterized in that the license request unit (103), the license creation unit (102) and the license control unit (104) are located in the same equipment.
24. A system according to claim 15, characterized in that the license creation unit (102) is integrated to a payment system for paying the license fees.
25. A system according to claim 23 or 24, known from that the used payment system is a chargeable service number.
26. A system according to claim 15, characterized in that the license control unit
(104) and the unit using the execution license (105) are integrated into a uniform, single unit.
27. A system according to claim 15, characterized in that the license creation unit (102) is located in equipment of the party granting and managing the licenses.
28. A system according to claim 15, characterized in that a using unit (105) is a base product and used resources (106) are add-on products utilized by a base product.
PCT/FI2002/000827 2001-10-24 2002-10-24 A method and a system for licensing digital resources and services WO2003036530A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20012057A FI20012057A (en) 2001-10-24 2001-10-24 Method and apparatus for licensing digital resources and services
FI20012057 2001-10-24

Publications (2)

Publication Number Publication Date
WO2003036530A1 true WO2003036530A1 (en) 2003-05-01
WO2003036530B1 WO2003036530B1 (en) 2003-08-21

Family

ID=8562111

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2002/000827 WO2003036530A1 (en) 2001-10-24 2002-10-24 A method and a system for licensing digital resources and services

Country Status (2)

Country Link
FI (1) FI20012057A (en)
WO (1) WO2003036530A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003935A1 (en) * 2003-07-03 2005-01-13 Siemens Aktiengesellschaft System and/or method for releasing release license software programs
US8401973B1 (en) * 2009-11-19 2013-03-19 Adobe Systems Incorporated Method and system for managing a license for an add-on software component

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742757A (en) * 1996-05-30 1998-04-21 Mitsubishi Semiconductor America, Inc. Automatic software license manager
US5905860A (en) * 1996-03-15 1999-05-18 Novell, Inc. Fault tolerant electronic licensing system
US6189146B1 (en) * 1998-03-18 2001-02-13 Microsoft Corporation System and method for software licensing
US6219652B1 (en) * 1998-06-01 2001-04-17 Novell, Inc. Network license authentication
WO2001074138A2 (en) * 2000-04-03 2001-10-11 Wireless Knowledge Software licensing system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5905860A (en) * 1996-03-15 1999-05-18 Novell, Inc. Fault tolerant electronic licensing system
US5742757A (en) * 1996-05-30 1998-04-21 Mitsubishi Semiconductor America, Inc. Automatic software license manager
US6189146B1 (en) * 1998-03-18 2001-02-13 Microsoft Corporation System and method for software licensing
US6219652B1 (en) * 1998-06-01 2001-04-17 Novell, Inc. Network license authentication
WO2001074138A2 (en) * 2000-04-03 2001-10-11 Wireless Knowledge Software licensing system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MILOSEVIC Z.: "Electronic Commerce on the Internet: What is still missing?", PROCEEDINGS OF THE 5TH ANNUAL CONF. OF THE INTERNET SOCIETY, INET'95, 1995, HAWAII *
MILOSEVIC Z.: "Inter-Enterprise Contract Architecture for Open Distributed Systems: Security Requirements.", WET ICE'96 WORKSHOP ON ENTERPRISE SECURITY, June 1996 (1996-06-01), STANFORD, USA *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003935A1 (en) * 2003-07-03 2005-01-13 Siemens Aktiengesellschaft System and/or method for releasing release license software programs
US8401973B1 (en) * 2009-11-19 2013-03-19 Adobe Systems Incorporated Method and system for managing a license for an add-on software component

Also Published As

Publication number Publication date
WO2003036530B1 (en) 2003-08-21
FI20012057A0 (en) 2001-10-24
FI20012057A (en) 2003-04-25

Similar Documents

Publication Publication Date Title
JP3766197B2 (en) Software distribution method, server device, and client device
US5925127A (en) Method and system for monitoring the use of rented software
US6920567B1 (en) System and embedded license control mechanism for the creation and distribution of digital content files and enforcement of licensed use of the digital content files
US7171662B1 (en) System and method for software licensing
AU2004260419B2 (en) Application rights management in a mobile environment
KR100796583B1 (en) System, method and storage medium for license management
US7096491B2 (en) Mobile code security architecture in an application service provider environment
US8626842B2 (en) Content transaction management server device, content-providing server device, and terminal device and control program
EP1287416B1 (en) System and embedded license control mechanism for the creation and distribution of digital content files and enforcement of licensed use of the digital content files
US7016878B2 (en) Content sales period verifying system and content decryption key effective period verifying system
US20080114695A1 (en) Process for implementing a method for the on-line sale of software product use licenses through a data network, and software component which allows carrying out said process
EP1688855A2 (en) Flexible licensing architecture for licensing digital application
EP1388055A1 (en) Method and system for conditional installation and execution of services in a secure computing environment
JPH10222579A (en) Virtual sales system, electronic data distribution, license and rental managing method
US20020055910A1 (en) Program component distribution
US10534896B2 (en) Authorising use of a computer program
JP2003202988A (en) Method and system for software management service and program
JP2003256670A (en) Distributed management type net sales method for software and protect program
JP2003029861A (en) Method for supplying application program, application program to be used for the method and recording medium with the program recorded thereon
EP1174786A2 (en) Method, system, and program for reusing software licenses with new computer hardware
WO2003036530A1 (en) A method and a system for licensing digital resources and services
JP2004030617A (en) Transaction service system using internet and its method
JP2004152283A (en) Method and system for time lease of software
KR20030012294A (en) A system for software rent and a method thereof
JP2005309536A (en) System for prevention of unauthorized use of application software, distributable recording medium creation apparatus for use in system, electronic apparatus for use in system, and installer actuating software, and decoding program executing software for use in system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
B Later publication of amended claims

Free format text: 20030403

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP