EP1226484A2 - Appareil electronique - Google Patents

Appareil electronique

Info

Publication number
EP1226484A2
EP1226484A2 EP00983028A EP00983028A EP1226484A2 EP 1226484 A2 EP1226484 A2 EP 1226484A2 EP 00983028 A EP00983028 A EP 00983028A EP 00983028 A EP00983028 A EP 00983028A EP 1226484 A2 EP1226484 A2 EP 1226484A2
Authority
EP
European Patent Office
Prior art keywords
value
software
electronic device
runtime
maximum permissible
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP00983028A
Other languages
German (de)
English (en)
Inventor
Herbert Grieb
Peter Müller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
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 Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP1226484A2 publication Critical patent/EP1226484A2/fr
Withdrawn legal-status Critical Current

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/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/123—Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices

Definitions

  • the invention relates to an electronic device with software protection.
  • the electronic device has a computing unit for processing a program and a memory in which an operating system software and runtime software for the computing unit are loaded.
  • a prerequisite for profitable marketing of software is appropriate protection that prevents the software from being used several times by users, even though no corresponding right of use has been acquired.
  • a technical means of protecting the software against unauthorized use is therefore required.
  • protection is necessary which prevents the function blocks from being used unauthorizedly. This should not be a copy protection as is common in many software products for personal computers. Protection against unauthorized multiple use means that software only runs on an automation device if the user has acquired the right to do so. that is, if a license has been granted by the manufacturer.
  • Protection against unauthorized multiple use of software could be linked to a unique identifier of the electronic device, for example a serial number.
  • the software could be run in such a way that it would only run on the target system for which it was released.
  • this had the disadvantage that the protection could not be used everywhere, since serial numbers are not currently available in all target systems, and that a change to a different, same target system would be difficult if the original target system failed.
  • Another way to protect against unauthorized multiple use would be to load protected software into a target system in the engineering system using a unique identifier of the target system, e.g. B. a serial number to monitor. This option is also rejected, since target systems usually do not have a serial number and it would be difficult to switch to another, identical target system if one target system fails. In this case, the effectiveness of the protective mechanism would only be limited to one engineering system. Therefore, additional measures for software copy protection were required in the engineering system.
  • the protected software could use name declarations, e.g. B. a pro ect name can be linked.
  • the engineering system then had to check whether the protected software was to be used in different projects and, if necessary, prevent this. However, this measure would not be sufficient without further additions, since software can in principle also be duplicated outside of the engineering system. A safe protective function was therefore not fulfilled.
  • the invention has for its object to provide an electronic device which is equipped with effective protection against unauthorized multiple use of software and which is distinguished by good manageability of the software by manufacturers and users.
  • the new electronic device of the type mentioned has the features specified in claim 1.
  • claims 6 and 7 a device or a function block are described which are suitable for use in the new electronic device.
  • Advantageous developments of the invention are specified in the subclaims.
  • the invention enables protection of runtime software that is loaded onto a target system and runs on the target system.
  • function blocks of the runtime software describes system function blocks, standard function blocks, user function blocks, with the help of a graphical configuration tool, which is also referred to as a continuous function on chart, function blocks generated, loadable drivers, operating system add -Ons or other optional software modules that can be loaded on a computing unit.
  • a right of use allows the user to use the software on a target system, for example an automation device.
  • the software can be used as often as desired within the target system.
  • the right of use therefore relates to the use of the block type and not to the block instance implemented with this block within the runtime software.
  • the software is protected according to the value set for it. It is checked whether the protected software used on a target system is covered in total by the maximum value stored in a device.
  • the runtime software can only be used within the permitted usage rights on the target system. It can only be used if a corresponding equivalent value is stored in the facility for protected software.
  • the system manufacturer's additional effort for handling protected software is minimal compared to handling unprotected software in terms of sales and support.
  • Protected software can be used in various ways, e.g.
  • the handling of protected software may result in minor changes compared to the handling of unprotected software.
  • handling and joint operation of protected and non-protected software is possible. It has a favorable effect on the support for the software manufacturer that no interactions via a hotline between user and manufacturer are required in the trouble-free operation.
  • Z. B. no registration or authorization numbers for operating the software are requested. If the stored value in the electronic device for operating the runtime software is not sufficient, then the system provides the user with clear information. Different versions of the operating system of the electronic device, e.g. B. with updates or upgrades, do not affect the use of protected software. No new protective mechanisms are added when handling new versions.
  • software protection does not require a fixed assignment between a hardware component, which is often referred to as a dongle, and a specific protected software. This considerably simplifies handling for the user, since no different dongles have to be used for different software components and the protected software cannot only run on a single target system.
  • the protection mechanism only works during the runtime of the protected software. It can therefore be handled like unprotected software before being used on a target system and, for example, copied as often as required. Problems associated with copy protection programs are thus avoided.
  • the value can be assigned directly and flexibly to the price.
  • the device in which the maximum permissible value for the runtime software can be read out as a hardware module that can be inserted into the electronic device or connected to the electronic device, has the advantage that the value can be easily adapted Software changes is achieved.
  • the protection of the software can be implemented without extensive intervention in the hardware of the electronic device. If the user uses protected software, apart from the easily replaceable hardware module, he does not need any additional software
  • a memory card as a hardware module has the advantage, in particular in the case of automation devices, that no additional hardware component is required since eme
  • Memory card is mostly used anyway. Complicated hardware intervention is unnecessary because the memory card can be easily inserted into the slot provided. The security of a memory card is sufficient for the protective function. It is not easy to create a copy with a valid value.
  • the device in which the maximum permissible value for the runtime software is stored can advantageously have a unique identification, in particular a serial number, and the stored value can be designed as a loadable value module that is only used for the device with the respective identification Is valid. This makes it easy to increase the value of rights of use by loading the device into another value module with the required value n.
  • the marketing of value modules can be automated via the Internet, for example. It is not necessary to handle hardware components. So-called value corpses are avoided.
  • the term "equivalent value" denotes a facility in which a maximum permissible Value is firmly stored, which is no longer sufficient for the specific application, e.g. B. because the application has since been supplemented by additional protected software components.
  • Value-building systems integrate seamlessly into the existing software landscape of automation devices, since they are basically function blocks.
  • FIG. 1 shows a block diagram of an electronic device with software protection
  • FIG. 2 shows a block diagram of a device in which values are stored
  • FIG. 3 shows a device for storing values and functional modules to illustrate the principle of action
  • FIG. 4 shows an input mask for creating value modules
  • an electronic device is equipped with an arithmetic unit 1, which uses an operating system software in a memory 2 to process runtime software in a memory 3, which is application-specific and, for example, is adapted to the respective control task in the case of automation devices.
  • the runtime software contains a total of eight function blocks 4 ... 11.
  • the function blocks 4, 5 and 6 are unprotected and therefore have no significance.
  • the function blocks 7 ... 11 are each assigned a value which in principle represents the value of the right of use.
  • Each protected function block is thus assigned a value.
  • a user who wants to use the protected function blocks acquires a right of use with a certain value.
  • This right of use is represented by a maximum permissible value for the runtime software, which is stored in a device 12 and can be read out.
  • the user can use protected software as long as the total value of the protected software is covered by the value of the right of use.
  • the maximum permissible value is stored on a memory card 13 together with the runtime software.
  • the memory for the operating system software can also be arranged on the same storage medium.
  • the computing unit 1 uses the operating system software in the memory 2 to check whether the total value of all protected function blocks, ie the function building blocks 7 ... 11, which exceeds the maximum permissible value stored in the device 12. If this is the case, then there is a protection violation and an indication signal 14 is output, which can result in a predetermined reaction.
  • FIG. 2 shows a memory card 13 for realizing the device 12 with reloadable value modules.
  • a serial number 21 is stored in a memory cell 13 of a memory card 13, which can only be written by the manufacturer of the memory card 13 and not by the user. This serial number 21 enables the memory card 13 to be uniquely identified.
  • Value modules 22, 23 and 24 are manufacturer-specific and are stored in a free memory area 25 of the memory card 13.
  • the value module 22 is for the manufacturer of the electronic device, the value modules 23 and 24 are provided for a first OEM or a second OEM. The manufacturer and the OEM can thus create their own value modules and assign their own usage rights to the user.
  • the runtime software which is not shown in FIG. 2 for clarity, is also stored in the free area 25 of the memory card 13. In terms of the software structure, value modules are identical to function modules and can therefore be handled like function modules. However, you have no executable program code.
  • Validity modules 22, 23 and 24 are only valid in conjunction with a specific serial number 21.
  • a protected function block 30 contains a manufacturer identifier 31, which consists of a readable manufacturer name and a password hidden to the user. The same manufacturer identifier must also be present as manufacturer identifier 38 in a weighting module 32. so that this can be clearly assigned to the manufacturer of the function block 30.
  • a serial number 33 and a maximum permissible value 34 are in turn inaccessible to the user in the value module 32. The uniqueness of the value module 32 is ensured via the serial number 33 and it is ensured that it is only valid for the device whose serial number 37 stored in a code bit memory 35 matches the serial number 33 of the value module 32.
  • a value 36 ie a value of the function block 30, is stored in the function block 30 so that it cannot be written to by the user.
  • the total value of all protected functional modules of a manufacturer must be covered by the value 34 on the value module 32 of the corresponding manufacturer, so that there are sufficient usage rights.
  • FIG. 4 shows the user interface of a tool for creating value modules.
  • the OEM can freely choose the manufacturer identifier, which is referred to in FIG. 4 as the OEM identifier. It consists of two parts.
  • the visible part is the OEM name, here from Softy, which can be read by users at any time in order to identify which manufacturer the value module or the protected software comes from.
  • the second part is an OEM password, which is only known to the respective OEM and remains hidden from users. This prevents misuse because only the OEM who has the password knows, m is able to generate value building blocks e.
  • a serial number of the memory card referred to here as an MC serial number, and a value of the value module can be entered.
  • the sufficient presence of usage rights can always be checked when starting up an electronic device, when reloading software or at suitable intervals during operation.
  • Function blocks FB and value 51 are stored on a memory card 50.
  • the control unit searches the control program for function building blocks FB in a step 52 with the aid of suitable operating system software, the individual values are read out and the total value is calculated.
  • the maximum permissible value 51 for the runtime software is read out.
  • a comparison 54 then takes place between the total value determined in step 52 and the maximum permissible value 51. If the total valency exceeds the maximum permissible valency 51, a display signal is output in step 55 and further error reactions may occur.
  • step 56 normal operation is carried out in a step 56. All protected function blocks located on the memory card 50 can be recorded. The check is then carried out regardless of whether an instance of a function block type is installed in a sequence cycle or not. The respective interconnection of the function blocks is shown in FIG. 5 by a program block 57. The check described is carried out separately for each manufacturer.
  • the function module FB When the function module FB is called up for the first time, the function blocks FB write their value and manufacturer identification in one Operating system list. This process corresponds to a step 60 of the process. Once the entire application program has been run through, it can be assumed that the list contains the weights and manufacturer IDs of all the function blocks involved. In a step 61, the list is evaluated in that the weights are added up to a total weight according to the respective manufacturer identifications. In a step 62, the values 63 are read from the value modules and again compared in a comparison 64 with the calculated total values.
  • the check must preferably be carried out when the computing unit of the electronic device starts up.
  • the check should additionally be carried out at appropriate intervals.
  • the computing unit can continue to work with reduced performance.
  • a more serious consequence could be that the computing unit switches to a stop state when there are no rights of use and the electronic device is therefore not functional.
  • Simplifying testing, commissioning or hardware failure can help the user of the electronic device Tobe offered.
  • One is that the user is provided with a generally valid memory card, the value modules of which contain the value ⁇ . With this memory card, all protected modules can be run without any restrictions.
  • the other help is to set the arithmetic unit of the electronic device in a "trial run" operating mode via parameterization on an engineering system. In this operating mode, the value is not checked. Again, all the protected function modules are fully functional Time, e.g. after 200 hours, the trial run expires and the protection mechanisms described become effective again.
  • the marketing of value building schemes can be done, for example, by shipping.
  • the user orders a value module with a specific value from the manufacturer whose function block library he uses, by calling the serial number of the memory card.
  • the manufacturer can be, for example, the manufacturer of the electronic device or an OEM.
  • the value module is generated, played on a floppy disk and sent to the customer against invoice.
  • Another completely automatic marketing option is the Internet.
  • the user selects himself on the service homepage of the manufacturer em and finds there a menu item "Order value modules". Here he gives his name, his e-mail address, the serial number of the memory card, the desired value and the preferred one
  • Em Server can automatically use the information provided by the manufacturer to create a weighting module and send the module to the customer by e-mail.
  • a dongle which is designed here as a memory card, can be implemented as a hardware key, which is accommodated in the plug of an MPI connection cable or, if no MPI connection is used, as a dummy plug on the MPI interface is plugged on.
  • this implementation variant has the disadvantage that a new dongle had to be developed which represents a new, additional hardware component. The dongle also had to be adapted to future developments of the MPI interface.
  • a total value can be stored in the memory card's bit memory, which cannot be changed by software.
  • This total value covers the value of all protected software from system manufacturers and from OEM.
  • the memory cards are produced with different values and receive different order numbers as different products. This means that if there are n different values, n different types of memory cards must be kept and kept in stock as products. With this variant, it is not possible to differentiate between the system manufacturer and the OEM, since only a total value for both is stored together. Since the value cannot be changed after the fact, the "valence corpses" described above are created.
  • a memory card can be created, the identification bit memory of which has an area in which user data can be written. However, this area should only be accessible if the associated programming mechanism is known. The value and the OEM identifier are stored there. In this case, an OEM needs a special programming tool with the programming mechanism in order to be able to access this area of the identification bit memory.
  • This programming tool can be implemented as an extension of an engineering system provided by the manufacturer of the memory card. In this variant, OEMs can value and their
  • valence systems can be loaded into the memory 2 or 3 of the electronic device, so that the memory area of the device 12, with which the maximum permissible valence for the runtime software can be read out, is stored by part of the memory 2 or 3 is replaced.
  • the device 12 bears a unique identification, for example a serial number, and is preferably designed as a replaceable hardware module.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Remote Sensing (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un appareil électronique comprenant une protection pour un exécuteur. Au moins un module fonctionnel (4 ... 11) de l'exécuteur est pourvu d'un poids. Un poids maximal admissible pour l'exécuteur est stocké dans une unité (12) de manière à pouvoir être extrait de cette dernière. Le poids total des modules fonctionnels de l'exécuteur est déterminé par une unité de calcul (1) et un signal d'affichage (14) est sorti lorsque le poids total dépasse le poids maximal admissible. Les modules fonctionnels et les modules de poids peuvent être pourvus d'une marque OEM de sorte que le producteur du système et l'OEM puissent concevoir une protection de logiciel indépendamment l'un de l'autre.
EP00983028A 1999-10-18 2000-10-17 Appareil electronique Withdrawn EP1226484A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19950249A DE19950249C1 (de) 1999-10-18 1999-10-18 Elektronisches Gerät mit Softwareschutz
DE19950249 1999-10-18
PCT/DE2000/003649 WO2001029638A2 (fr) 1999-10-18 2000-10-17 Appareil electronique

Publications (1)

Publication Number Publication Date
EP1226484A2 true EP1226484A2 (fr) 2002-07-31

Family

ID=7926110

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00983028A Withdrawn EP1226484A2 (fr) 1999-10-18 2000-10-17 Appareil electronique

Country Status (6)

Country Link
US (1) US20020129270A1 (fr)
EP (1) EP1226484A2 (fr)
JP (1) JP2003512667A (fr)
CN (1) CN1409834A (fr)
DE (1) DE19950249C1 (fr)
WO (1) WO2001029638A2 (fr)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001216357A (ja) * 2000-02-01 2001-08-10 Toshiba Corp ソフトウェアのライセンス管理方法および電子機器並びに記録媒体
DE10023820B4 (de) * 2000-05-15 2006-10-19 Siemens Ag Software-Schutzmechanismus
DE10105363B4 (de) * 2001-02-06 2008-01-03 Siemens Gebäudetechnik Bayern GmbH & Co. oHG Speicherprogrammierbare Steuerung
JP2004062610A (ja) * 2002-07-30 2004-02-26 Citizen Watch Co Ltd 工作機械のプログラム不正使用防止装置
US20060267808A1 (en) * 2005-05-24 2006-11-30 Imation Corp. Secure drive system enabled by matching media code
US8091084B1 (en) 2006-04-28 2012-01-03 Parallels Holdings, Ltd. Portable virtual machine
CN101339595B (zh) * 2008-05-20 2011-08-10 北京深思洛克软件技术股份有限公司 一种通过使用许可控制软件使用的装置
JP5168012B2 (ja) * 2008-07-28 2013-03-21 株式会社ジェイテクト プログラマブルコントローラのプログラム編集装置
DE102009059939A1 (de) * 2009-12-22 2011-06-30 Giesecke & Devrient GmbH, 81677 Verfahren zum Komprimieren von Bezeichnern
US9311457B1 (en) * 2011-11-02 2016-04-12 Google Inc. Platform for cloud application software
CN105426705A (zh) * 2015-11-05 2016-03-23 肖月华 一种会计软件的加密控制系统
CN115859389B (zh) * 2023-02-17 2023-04-28 浪潮通用软件有限公司 一种基于私有化部署的软件序列号授权方法及系统

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339419A (en) * 1990-06-25 1994-08-16 Hewlett-Packard Company ANDF compiler using the HPcode-plus compiler intermediate language
US5446904A (en) * 1991-05-17 1995-08-29 Zenith Data Systems Corporation Suspend/resume capability for a protected mode microprocessor
US5742848A (en) * 1993-11-16 1998-04-21 Microsoft Corp. System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions
US5530752A (en) * 1994-02-22 1996-06-25 Convex Computer Corporation Systems and methods for protecting software from unlicensed copying and use
FR2720532B1 (fr) * 1994-05-25 1997-09-12 Vincent Lorphelin Système de location sécurisée de logiciels par carte à mémoire.
US5724425A (en) * 1994-06-10 1998-03-03 Sun Microsystems, Inc. Method and apparatus for enhancing software security and distributing software
US5701343A (en) * 1994-12-01 1997-12-23 Nippon Telegraph & Telephone Corporation Method and system for digital information protection
WO1996018939A2 (fr) * 1994-12-16 1996-06-20 Graphisoft R & D Software Development Company Limited By Shares Systeme de taxation de l'utilisation d'un logiciel
CN1312549C (zh) * 1995-02-13 2007-04-25 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US5761499A (en) * 1995-12-21 1998-06-02 Novell, Inc. Method for managing globally distributed software components
US5671412A (en) * 1995-07-28 1997-09-23 Globetrotter Software, Incorporated License management system for software applications
WO1997027536A1 (fr) * 1996-01-24 1997-07-31 Sun Microsystems, Inc. Pliage d'instructions pour machine a empilement
US20010011253A1 (en) * 1998-08-04 2001-08-02 Christopher D. Coley Automated system for management of licensed software
US5892904A (en) * 1996-12-06 1999-04-06 Microsoft Corporation Code certification for network transmission
US6263492B1 (en) * 1997-06-06 2001-07-17 Microsoft Corporation Run time object layout model with object type that differs from the derived object type in the class structure at design time and the ability to store the optimized run time object layout model
US6643775B1 (en) * 1997-12-05 2003-11-04 Jamama, Llc Use of code obfuscation to inhibit generation of non-use-restricted versions of copy protected software applications
US6134659A (en) * 1998-01-07 2000-10-17 Sprong; Katherine A. Controlled usage software
US6189146B1 (en) * 1998-03-18 2001-02-13 Microsoft Corporation System and method for software licensing
US6675298B1 (en) * 1999-08-18 2004-01-06 Sun Microsystems, Inc. Execution of instructions using op code lengths longer than standard op code lengths to encode data
US6308256B1 (en) * 1999-08-18 2001-10-23 Sun Microsystems, Inc. Secure execution of program instructions provided by network interactions with processor
US6665796B1 (en) * 1999-08-18 2003-12-16 Sun Microsystems, Inc. Microprocessor instruction result obfuscation
US6757831B1 (en) * 1999-08-18 2004-06-29 Sun Microsystems, Inc. Logic block used to check instruction buffer configuration
JP2001222424A (ja) * 2000-02-08 2001-08-17 Fujitsu Ltd ソフトウェアライセンス管理装置，ソフトウェアライセンス管理方法およびソフトウェアライセンス管理用プログラム記録媒体
US7181572B2 (en) * 2002-12-02 2007-02-20 Silverbrook Research Pty Ltd Cache updating method and apparatus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0129638A2 *

Also Published As

Publication number Publication date
US20020129270A1 (en) 2002-09-12
JP2003512667A (ja) 2003-04-02
WO2001029638A2 (fr) 2001-04-26
DE19950249C1 (de) 2001-02-01
WO2001029638A3 (fr) 2001-11-22
CN1409834A (zh) 2003-04-09

Similar Documents

Publication Publication Date Title
DE68926176T2 (de) Verwaltungssystem für lizenzierte Programme
DE3611223C2 (fr)
DE69522998T2 (de) Gesicherte anwendungskarte zur aufteilung von anwendungsdaten und prozeduren zwischen mehreren mikroprozessoren
DE19612999C2 (de) System zur Sicherung geschützter Software gegen unbefugte Benutzung in Rechnernetzwerken
DE69027165T2 (de) Verfahren und Gerät zum Schutz eines Rechnersystems
DE112007003231B4 (de) Programmierbare Anzeigevorrichtung und Steuersystem
DE3689569T2 (de) Verfahren zur Systemdateiensicherung und Datenverarbeitungseinheit zu dessen Durchführung.
DE69502852T2 (de) Gerät zur Sicherung von Daten
DE69223799T2 (de) Einstellung der systemkonfiguration in einem datenverarbeitungssystem
DE10004822A1 (de) System und Verfahren zur Identifizierung und zum beschleunigten Zugriff auf Online-Dienste
DE4115152A1 (de) Datenschuetzende mikroprozessorschaltung fuer tragbare datentraeger, beispielsweise kreditkarten
DE19918640A1 (de) Verfahren und System zum Liefern einer kundenspezifischen Softwareinstallation an ein Computersystem
EP0522332A1 (fr) Calculateur pour le contrôle d'une machine, notamment d'une presse d'impression
DE10155752A1 (de) Lizenzierungsverfahren
DE19950249C1 (de) Elektronisches Gerät mit Softwareschutz
DE10023820B4 (de) Software-Schutzmechanismus
DE10155755A1 (de) Lizenzgenerierungsverfahren
DE19963471A1 (de) Verfahren und Vorrichtung zur Verhinderung von Raubkopien von Computerprogrammen
DE112010004264T5 (de) Selektiver Schreibschutz für das Austesten der Wiederherstellung nach einem Absturz
WO2001088669A1 (fr) Gestionnaire de licence
EP0464320A2 (fr) Méthode pour protéger individuellement des supports de données contre une utilisation non autorisée
EP0966711B1 (fr) Micro-ordinateur equipe d'une gestion memoire
EP2711794B1 (fr) Procédé de séparation intermittente de données d'objets vis-à-vis de modèles de projet
DE4103173C3 (de) Vorrichtung zum Schutz gegen unautorisierte Benutzung von Software
WO1993023807A1 (fr) Procede de protection de programme assurant la protection d'un systeme informatique

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020222

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RBV Designated contracting states (corrected)

Designated state(s): AT CH DE ES FR GB LI

17Q First examination report despatched

Effective date: 20080110

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080521