[go: up one dir, main page]

WO2003036530A1 - Procede et systeme de concession de licences pour utilisation de services et de ressources numeriques - Google Patents

Procede et systeme de concession de licences pour utilisation de services et de ressources numeriques 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
English (en)
Other versions
WO2003036530B1 (fr
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/fr
Publication of WO2003036530B1 publication Critical patent/WO2003036530B1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/105—Arrangements 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention se rapporte à la gestion de l'utilisation de données numériques. En particulier, l'invention se rapporte à la gestion de l'utilisation de plusieurs ressources et services numériques ainsi qu'à des connexions de communication de données par concession de licences. Dans un procédé selon l'invention, pour l'octroi d'une licence relative à des services et des ressources numériques, en réponse à une demande de licence, dans une unité de demande de licence (103), des modèles de licence contenant des attributs sont traités puis transformés en une demande de licence par changement et/ou addition de valeurs d'attributs (411) d'un modèle de licence. La demande de licence est alors émise à une unité de création de licence spécifique (102) traitant les demandes de licence. Dans l'unité de création de licence (102), la demande de licence est transformée en une licence d'exécution par changement et/ou addition de valeurs d'attributs (506) de la demande de licence, puis la licence d'exécution est émise à une unité de contrôle de licence (105) contrôlant l'utilisation de ressources et/ou de services.
PCT/FI2002/000827 2001-10-24 2002-10-24 Procede et systeme de concession de licences pour utilisation de services et de ressources numeriques WO2003036530A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20012057A FI20012057A7 (fi) 2001-10-24 2001-10-24 Menetelmä ja laitteisto digitaalisten resurssien ja palveluiden lisensoimiseksi
FI20012057 2001-10-24

Publications (2)

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

Family

ID=8562111

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2002/000827 WO2003036530A1 (fr) 2001-10-24 2002-10-24 Procede et systeme de concession de licences pour utilisation de services et de ressources numeriques

Country Status (2)

Country Link
FI (1) FI20012057A7 (fr)
WO (1) WO2003036530A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003935A1 (fr) * 2003-07-03 2005-01-13 Siemens Aktiengesellschaft Systeme et procede d'octroi de permis d'exploitation pour des programmes logiciels necessitant un permis d'exploitation
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 (fr) * 2000-04-03 2001-10-11 Wireless Knowledge Systeme de licence de logiciels

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 (fr) * 2000-04-03 2001-10-11 Wireless Knowledge Systeme de licence de logiciels

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 (fr) * 2003-07-03 2005-01-13 Siemens Aktiengesellschaft Systeme et procede d'octroi de permis d'exploitation pour des programmes logiciels necessitant un permis d'exploitation
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
FI20012057L (fi) 2003-04-25
WO2003036530B1 (fr) 2003-08-21
FI20012057A0 (fi) 2001-10-24
FI20012057A7 (fi) 2003-04-25

Similar Documents

Publication Publication Date Title
JP3766197B2 (ja) ソフトウエア流通方法およびサーバ装置およびクライアント装置
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
KR100796583B1 (ko) 라이센스 관리를 위한 시스템, 방법 및 기록 매체
AU2004260419B2 (en) Application rights management in a mobile environment
US7096491B2 (en) Mobile code security architecture in an application service provider environment
EP1287416B1 (fr) Systeme et mecanisme integre de controle des licences pour la creation et la distribution de fichiers numeriques et de l'application de l'utilisation autorisee des fichiers numeriques
US7016878B2 (en) Content sales period verifying system and content decryption key effective period verifying system
US20040015958A1 (en) Method and system for conditional installation and execution of services in a secure computing environment
US20110004555A1 (en) Content transaction management server device, content-providing server device, and terminal device and control program
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 (fr) Architecture flexible d'octroi de licence pour un octroi de licence d'une application numérique
US10534896B2 (en) Authorising use of a computer program
US20020055910A1 (en) Program component distribution
JP2003202988A (ja) ソフトウェア管理サービス方法、ソフトウェア管理サービスシステム及びプログラム
JP2003256670A (ja) ソフトウェアの分散管理型ネット販売方法及びプロテクトプログラム
JP2003029861A (ja) アプリケーションプログラムの供給方法およびこの供給方法に用いられるアプリケーションプログラムおよびこれを記録した記録媒体
EP1174786A2 (fr) Procédé, système et programme de réutilisation des licences d'utilisation de logiciels dans un nouveau dispositif d'ordinateur
WO2003036530A1 (fr) Procede et systeme de concession de licences pour utilisation de services et de ressources numeriques
JP2004030617A (ja) インターネットを利用したトランザクションサービスシステムおよびその方法
JP2002091598A (ja) 情報処理システム及びその方法、並びにコンピュータ上で動作する情報処理プログラムを記録した記録媒体
JP2004152283A (ja) ソフトウェア時間貸しシステム及び方法
KR20030012294A (ko) 소프트웨어 임대 시스템 및 그 방법
JP2005309536A (ja) アプリケーションソフトの不正使用防止システム、同システムに用いられる流通用記録媒体作成装置、同システムに用いられる電子機器及び同システムに用いられるインストーラ作動用ソフトウエア並びに復号化プログラム実行用ソフトウエア

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