EP1226484A2 - Elektronisches gerät mit softwareschutz - Google Patents

Elektronisches gerät mit softwareschutz

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
English (en)
French (fr)
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
Original Assignee
Siemens AG
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 filed Critical Siemens AG
Publication of EP1226484A2 publication Critical patent/EP1226484A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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.

Abstract

Die Erfindung betrifft ein elektronisches Gerät mit Softwareschutz für Runtime-Software. Zumindest ein Funktionsbaustein (4 ... 11) der Runtime-Software wird mit einer Wertigkeit versehen. In einer Einrichtung (12) ist eine maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt. Durch eine Recheneinheit (1) wird die Summenwertigkeit der Funktionsbausteine der Runtime-Software bestimmt und ein Anzeigesignal (14) ausgegeben, wenn die Summenwertigkeit die maximal zulässige Wertigkeit übersteigt. Funktionsbausteine und Wertigkeitsbausteine können mit einer OEM-Kennung versehen werden, so dass Systemhersteller und OEM unabhängig voneinander einen Softwareschutz gestalten können.

Description

Beschreibung
Elektronisches Gerät
Die Erfindung betrifft ein elektronisches Gerät mit Softwareschutz. Das elektronische Gerat weist eine Recheneinheit zur Abarbeitung eines Programms und einen Speicher auf, in dem eine Betriebssystem-Software und Runtime-Software für die Recheneinheit geladen ist.
Voraussetzung für eine gewinnbringende Vermarktung von Software ist ein entsprechender Schutz, der verhindert, daß die Software von Anwendern mehrfach eingesetzt wird, obwohl kein entsprechendes Nutzungsrecht erworben wurde. Deshalb ist ein technisches Mittel zum Schutz der Software vor unerlaubter Nutzung erforderlich. Insbesondere bei Automatisierungsgeraten, bei denen durch Zusammenschalten verschiedener Funktionsbausteine ein Steuerungsprogramm gebildet wird, ist ein Schutz notwendig, der eine unerlaubte Mehrfachverwendung der Funktionsbausteine verhindert. Dabei soll es sich nicht um einen Kopierschutz handeln, wie er bei vielen Softwareprodukten für Personal Computer üblich ist. Schutz vor unerlaubter Mehrfachverwendung bedeutet, daß eine Software auf einem Automatisierungsgerat nur dann ablauft, wenn der An- wender das Recht dazu erworben hat, d. h., wenn vom Hersteller eine Lizenz erteilt wurde.
Ein Schutz vor einer unerlaubten Mehrfachverwendung von Software konnte an eine eindeutige Kennung des elektronischen Geräts, beispielsweise eine Seriennummer, gekoppelt werden.
Die Software konnte so ausgeführt werden, daß sie nur auf dem Zielsystem ablauffähig wäre, für das sie freigegeben wurde. Das hatte jedoch den Nachteil, daß der Schutz nicht überall anwendbar wäre, da derzeit nicht in allen Zielsystemen Seriennummern vorhanden sind, und daß wegen der Kopplung an ein einzelnes Zielsystem ein Wechsel auf ein anderes, bau- gleiches Zielsystem bei Ausfall des ursprünglichen Zielsystems schwer möglich wäre.
Eine weitere Möglichkeit zum Schutz vor unerlaubter Mehrfach- Verwendung wäre es, im Engineering-System das Laden von geschützter Software auf ein Zielsystem anhand einer eindeutigen Kennung des Zielsystems, z. B. einer Seriennummer, zu überwachen. Auch diese Möglichkeit wird verworfen, da Zielsysteme meist nicht über eine Seriennummer verfugen und em Wechsel auf ein anderes, baugleiches Zielsystem bei Ausfall eines Zielsystems nur schwer möglich wäre. Die Wirksamkeit des Schutzmechanismus wäre in diesem Fall nur auf ein Engineering-System beschrankt. Deshalb waren beim Engineering- System zusätzliche Maßnahmen für einen Softwarekopierschutz erforderlich.
Alternativ konnte die geschützte Software mit Namensdekla- rationen, z. B. einem Pro ektnamen, verknüpft werden. Das Engineering-System mußte dann überprüfen, ob die geschützte Software bei unterschiedlichen Projekten eingesetzt werden soll, und dies gegebenenfalls unterbinden. Diese Maßnahme wäre ohne weitere Ergänzungen allerdings nicht ausreichend, da Software prinzipiell auch außerhalb des Engineering- Systems dupliziert werden kann. Eine sichere Schutzfunktion wurde damit nicht erfüllt.
Eine weitere Möglichkeit konnte darin gesehen werden, die Vervielfältigung von geschützter Runtime-Software durch ein Kopierschutzprogramm ähnlich dem Programm „StopCopy" zu unterbinden. Dieser Kopierschutz mußte sowohl im Bereich der Engineering-Systeme als auch der Zielsysteme wirken. Hinsichtlich eines solchen Kopierschutzes bestehen jedoch Akzeptanzprobleme beim Systemhersteller und beim Anwender wegen des schwierigen Handlmgs, insbesondere bei verlorenen Nut- zungsrechten. Zudem mußte der Schutzmechanismus in der Software des Engineering-Systems und auf allen Komponenten des Zielsystems implementiert werden. Der Erfindung liegt die Aufgabe zugrunde, em elektronisches Gerat zu schaffen, das mit einem wirkungsvollen Schutz gegen unerlaubte Mehrfachverwendung von Software ausgestattet ist und sich durch eme gute Handhabbarkeit der Software bei Her- steller und Anwender auszeichnet.
Zur Losung dieser Aufgabe weist das neue elektronische Gerat der eingangs genannten Art die in Anspruch 1 angegebenen Merkmale auf. In den Ansprüchen 6 und 7 sind eine Einrichtung bzw. ein Funktionsbaustein beschrieben, die zur Verwendung in dem neuen elektronischen Gerat geeignet sind. Vorteilhafte Weiterbildungen der Erfindung sind in den Unteranspruchen angegeben.
In vorteilhafter Weise wird durch die Erfindung ein Schutz von Runtime-Software ermöglicht, die auf ein Zielsystem geladen wird und auf dem Zielsystem ablauft. Unter dem Begriff „Funktionsbausteine der Runtime-Software" werden System- funktionsbauste e, Standardfunktionsbausteine, Anwender- funktionsbausteine, mit Hilfe eines grafischen Projektierungswerkzeugs, das auch als Cont uous-Funct on-Chart bezeichnet wird, erzeugte Funktionsbausteine, ladbare Treiber, Betriebssystem-Add-Ons oder andere, auf eme Recheneinheit ladbare, optionale Softwaremodule verstanden.
Generell können beim Softwareschutz zwei Ausprägungen unterschieden werden. Das ist zum einen der technologische Schutz und zum anderen der Schutz vor einer unerlaubten Mehrfachverwendung. Durch den technologischen Schutz wird verhindert, daß Anwender den Source-Code der Software lesen oder auf ihn zugreifen können. Durch diese Maßnahme wird das technologische oder softwaretechnische Know-how des Herstellers geschützt. Der technologische Schutz ist beispielsweise bei SIMATIC S7-Automatιsιerungssystemen der Siemens AG durch das Attribut KNOWHOW-Protect gewährleistet. Die durch Software- Funktionsbausteme realisierten technologischen Funktionen sind damit für den Anwender nicht zugänglich. Mit dem Begriff „Runtime-Software" wird in diesem Zusammenhang jegliche Art von ladbaren und auf einem Zielsystem ablauffähigen Programmen bezeichnet. Dies können beispielsweise Systemfunktions- bausteme, Funktionsbausteine für technologische Funktionen und Betriebssystemfunktionsbausteine sein.
Ein Nutzungsrecht erlaubt dem Anwender die Nutzung der Software auf einem Zielsystem, beispielsweise einem Automatisie- rungsgerat. Innerhalb des Zielsystems kann die Software be- liebig oft verwendet werden. Das Nutzungsrecht bezieht sich somit auf die Verwendung des Bausteintyps und nicht auf die mit diesem Baustein jeweils realisierte Bausteininstanz innerhalb der Runtime-Software. Die Software wird entsprechend der für sie festgelegten Wertigkeit geschützt. Es wird überprüft, ob die auf einem Zielsystem verwendete geschützte Software in Summe durch die in einer Einrichtung hinterlegte maximale Wertigkeit gedeckt ist. Die Runtime-Software kann nur im Rahmen der erlaubten Nutzungsrechte auf dem Zielsystem verwendet werden. Eme Nutzung ist nur möglich, wenn für ge- schützte Software ein entsprechender Gegenwert in der Einrichtung hinterlegt ist. Der Mehraufwand beim Systemhersteller für das Handling von geschützter Software ist im Vergleich zum Handling von ungeschützter Software m bezug auf Vertrieb und Support minimal. Dabei kann geschützte Software über verschiedene Wege, wie z. B. Diskette, CD, Memory Card oder Internet, vermarktet werden. Für einen Anwender ergeben sich beim Handling von geschützter Software allenfalls geringfügige Änderungen gegenüber dem Handling ungeschützter Software. Zudem ist ein Handling und gemeinsamer Betrieb von geschützter und nicht geschützter Software möglich. Auf den Aufwand für Support durch den Softwarehersteller wirkt es sich gunstig aus, daß im störungsfreien Betrieb keine Interaktionen über eme Hotline zwischen Anwender und Hersteller erforderlich sind. Es müssen z. B. keine Registπerungs- oder Autorisierungsnum ern zum Betrieb der Software angefordert werden. Ist die hinterlegte Wertigkeit im elektronischen Gerat zum Betrieb der Runtime-Software nicht ausreichend, so sind eindeutige Hinweise durch das System an den Anwender möglich. Unterschiedliche Versionen des Betriebssystems des elektronischen Geräts, z. B. bei Updates oder Upgrades, beeinflussen nicht die Verwendung von geschützter Software. Beim Handling neuer Versionen kommen keine neuen Schutzmechanismen hinzu.
Der Schutz ist nicht an die einzelne Softwarekomponente, sondern an ihre Wertigkeit gekoppelt. Dadurch ergibt sich eme wesentlich einfachere und flexiblere Handhabung beim
Systemhersteller wie beim Anwender. Z. B. ist em Austausch oder eme Ergänzung von geschützten Softwarekomponenten ohne weiteres möglich, solange der Wert des Nutzungsrechts ausreichend ist.
In vorteilhafter Weise erfordert der Softwareschutz keine feste Zuordnung zwischen einer Hardwarekomponente, die häufig als Dongle bezeichnet wird, und einer bestimmten geschützten Software. Dies vereinfacht die Handhabung beim Anwender er- heblich, da keine unterschiedlichen Dongles für verschiedene Softwarekomponenten verwendet werden müssen und die geschützte Software nicht nur auf einem einzigen Zielsystem ablaufen kann.
Darüber hinaus wirkt der Schutzmechanismus nur zur Laufzeit der geschützten Software. Sie kann daher vor dem Einsatz auf einem Zielsystem wie ungeschützte Software gehandhabt und beispielsweise beliebig oft kopiert werden. Mit Kopierschutzprogrammen verbundene Probleme werden somit vermieden. Der Wertigkeit kann direkt und flexibel em Preis zugeordnet werden .
Die Einrichtung, in welcher die maximal zulassige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, als em in das elektronische Gerat einsetzbares oder an das elektronische Gerat anschließbares Hardwaremodul auszubilden, hat den Vorteil, daß eme leichte Anpaßbarkeit der Wertigkeit bei Softwareanderungen erreicht wird. Zudem ist der Schutz der Software ohne einen aufwendigen Eingriff m die Hardware des elektronischen Geräts realisierbar. Wenn der Anwender geschützte Software einsetzt, benotigt er - abgesehen von dem leicht austauschbaren Hardwaremodul - keine zusätzlichen
Komponenten zu den vorhandenen Systemkomponenten. Bezüglich eines Austauschs einzelner Baugruppen des elektronischen Geräts gibt es keinen Unterschied im Verhalten von geschützter und nicht geschützter Software. Die bisherige Software kann ohne Änderungen bei Austausch einzelner Baugruppen weiterverwendet werden.
Die Verwendung einer Memory Card als Hardwaremodul hat insbesondere bei Automatisierungsgeraten den Vorteil, daß keine zusätzliche Hardwarekomponente erforderlich ist, da eme
Memory Card ohnehin meist eingesetzt wird. Em komplizierter Hardwareeingriff ist überflüssig, da die Memory Card in einfacher Weise in den dafür vorgesehenen Schacht eingeschoben werden kann. Die Sicherheit einer Memory Card ist für die Schutzfunktion ausreichend. Em Erstellen einer Kopie mit ebenfalls gültiger Wertigkeit ist nicht ohne weiteres möglich.
Vorteilhaft kann die Einrichtung, in welcher die maximal zu- lassige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, eine eindeutige Identifikation, insbesondere eine Seriennummer, aufweisen und die hinterlegte Wertigkeit als ladbarer Wertigkeitsbaustein ausgebildet werden, der nur für die Einrichtung mit der jeweiligen Identifikation Gültigkeit besitzt. Dadurch ist der Wert von Nutzungsrechten leicht zu erhohen, indem em anderer Wertigkeitsbaustein mit dem benotigten Wert n die Einrichtung geladen wird. Die Vermarktung von Wertigkeitsbausteinen ist beispielsweise über Internet automatisierbar. Em Handling von Hardwarekomponenten ist dazu nicht erforderlich. Damit werden sogenannte Wertigkeits- leichen vermieden. Mit dem Begriff „Wertigkeitsleiche" wird eine Einrichtung bezeichnet, in der eme maximal zulassige Wertigkeit fest hinterlegt ist, die für den konkreten Anwendungsfall nicht mehr ausreichend ist, z. B. weil die Anwendung zwischenzeitlich um weitere geschützte Softwarekomponenten ergänzt wurde. Da eme Erhöhung der Wertigkeit ohne nachladbare Wertigkeitsbausteme entweder ganzlich unmöglich wäre oder nur vom Hersteller der Einrichtung vorgenommen werden konnte, wäre eine derartige Einrichtung für den Anwender wertlos geworden. Wertigkeitsbausteme integrieren sich nahtlos in die bestehende Softwarelandschaft von Automatisierungsgeraten, da es sich prinzipiell um Funktionsbausteine handelt.
Wenn die Funktionsbausteine in Gruppen, insbesondere nach Herstellern, mit jeweils zugeordneten Wertigkeitsbausteinen untergliedert werden, hat dies den Vorteil, daß Funktionsbausteine verschiedener Hersteller über eine einzige Einrichtung, auf welcher jeweils die maximal zulassigen Wertigkeiten hinterlegt sind, geschützt werden können. Bei nachladbaren Wertigkeitsbausteinen können sogenannte Original Equipment Manufacturer (OEM) , d. h. Anwender, die selbst
Software erstellen und vermarkten, ihre Software eigenständig und ohne direkte Unterstützung durch den Hersteller des elektronischen Geräts schützen. Eine Wertigkeitsvergabe oder Erhöhung beim Anwender ist unmittelbar, lokal und hardware- unabhängig vom Systemhersteller oder OEM möglich. Em Versenden beispielsweise einer neuen Memory Card, auf welcher die neue, maximal zulassige Wertigkeit hinterlegt ist, ist nicht erforderlich, da eme datentechnische Kopplung zur Hinterlegung einer neuen Wertigkeit ausreicht.
Anhand der Zeichnungen, in denen em Ausfuhrungsbeispiel der Erfindung dargestellt ist, werden im folgenden die Erfindung sowie Ausgestaltungen und Vorteile naher erläutert.
Es zeigen:
Figur 1 em Blockschaltbild eines elektronischen Geräts mit Softwareschutz, Figur 2 ein Blockschaltbild einer Einrichtung, in welcher Wertigkeiten hinterlegt sind,
Figur 3 eine Einrichtung zur Hinterlegung von Wertigkeiten und Funktionsbausteinen zur Verdeutlichung des Wirkungsprinzips,
Figur 4 eine Eingabemaske zur Erstellung von Wertigkeitsbausteinen,
Figur 5 und Figur 6 jeweils ein AblaufSchema zur Überprüfung ausreichender Nutzungsrechte.
Gemäß Figur 1 ist ein elektronisches Gerat mit einer Recheneinheit 1 ausgestattet, die mit Hilfe einer Betriebssystem- Software in einem Speicher 2 eine Runtime-Software in einem Speicher 3 abarbeitet, die applikationsspezifisch ausgeführt und beispielsweise bei Automatisierungsgeraten an die jeweilige Steuerungsaufgabe angepaßt ist. In dem gezeigten Ausfuhrungsbeispiel enthält die Runtime-Software insgesamt acht Funktionsbausteine 4 ... 11. Die Funktionsbausteine 4, 5 und 6 sind ungeschützt und weisen daher keine Wertigkeit auf. Da- gegen sind die Funktionsbausteine 7 ... 11 jeweils mit einer Wertigkeit versehen, die prinzipiell den Wert des Nutzungsrechts darstellt. Jedem geschützten Funktionsbaustein ist somit eme Wertigkeit zugeordnet. Ein Anwender, der die geschützten Funktionsbausteine einsetzen mochte, erwirbt em Nutzungsrecht mit einem bestimmten Wert. Dieses Nutzungsrecht wird durch eme maximal zulassige Wertigkeit für die Runtime- Software wiedergegeben, die in einer Einrichtung 12 auslesbar hinterlegt ist. Der Anwender kann geschützte Software einsetzen, solange die Summenwertigkeit der geschützten Software durch den Wert des Nutzungsrechts gedeckt ist. Die maximal zulassige Wertigkeit ist gemeinsam mit der Runtime-Software auf einer Memory Card 13 abgespeichert. Alternativ zum dargestellten Ausfuhrungsbeispiel kann auch der Speicher für die Betriebssystem-Software auf demselben Speichermedium angeord- net werden. Die Recheneinheit 1 überprüft anhand der Betriebssystem-Software im Speicher 2, ob die Summenwertigkeit aller geschützten Funktionsbausteine, d. h. der Funktions- bausteine 7 ... 11, die in der Einrichtung 12 hinterlegte, maximal zulässige Wertigkeit überschreitet. Ist dies der Fall, so liegt eine Schutzverletzung vor und es wird ein Anzeigesignal 14 ausgegeben, das eine vorbestimmte Reaktion zur Folge haben kann.
Figur 2 zeigt eine Memory Card 13 zur Realisierung der Einrichtung 12 mit nachladbaren Wertigkeitsbausteinen. In einem Kennbitspeicher 20 der Memory Card 13 ist eine Seriennummer 21 in einer Speicherzelle hinterlegt, die nur durch den Hersteller der Memory Card 13 und nicht durch den Anwender beschrieben werden kann. Diese Seriennummer 21 ermöglicht eine eindeutige Identifizierung der Memory Card 13. Wertigkeitsbausteine 22, 23 und 24 sind herstellerspezifisch und in einem freien Speicherbereich 25 der Memory Card 13 hinterlegt. Der Wertigkeitsbaustein 22 ist für den Hersteller des elektronischen Geräts, die Wertigkeitsbausteine 23 und 24 sind für einen ersten OEM bzw. einen zweiten OEM vorgesehen. Der Hersteller und die OEM können somit ihre eigenen Wertig- keitsbausteine herstellen und eigene Nutzungsrechte an den Anwender vergeben. Im freien Bereich 25 der Memory Card 13 ist weiterhin die Runtime-Software abgelegt, die in Figur 2 der Übersichtlichkeit wegen nicht dargestellt ist. Wertigkeitsbausteine sind hinsichtlich der Softwarestruktur mit Funktionsbausteinen identisch und somit wie Funktionsbausteine handhabbar. Sie haben allerdings keinen ablauffähigen Programmcode. Gültigkeit besitzen die Wertigkeitsbausteme 22, 23 und 24 nur in Verbindung mit einer bestimmten Seriennummer 21.
Die Abhängigkeiten zwischen Seriennummer, Wertigkeitsbaustein und geschütztem Funktionsbaustein sind in Figur 3 dargestellt. Beispielsweise enthalt ein geschützter Funktionsbaustein 30 eine Herstellerkennung 31, die aus einem lesbaren Herstellernamen und einem dem Anwender versteckten Password besteht. Dieselbe Herstellerkennung muß auch als Herstellerkennung 38 in einem Wertigkeitsbaustein 32 vorhanden sein, damit dieser eindeutig dem Hersteller des Funktionsbausteins 30 zugeordnet werden kann. Für den Anwender wiederum unzugänglich sind im Wertigkeitsbaustein 32 eine Seriennummer 33 und eine maximal zulassige Wertigkeit 34 abgelegt. Über die Seriennummer 33 wird die Einmaligkeit des Wertigkeitsbausteins 32 sichergestellt und gewährleistet, daß er nur für die Einrichtung Gültigkeit besitzt, deren in einem Kennbitspeicher 35 abgelegte Seriennummer 37 mit der Seriennummer 33 des Wertigkeitsbausteins 32 übereinstimmt. Durch die Uber- prufung der Seriennummern 33 und 37 auf Übereinstimmung wird eme mehrfache Verwendung von Wertigkeitsbausteinen verhindert. Weiterhin ist im Funktionsbaustein 30 eine Wertigkeit 36, d. h. em Wert des Funktionsbausteins 30, für den Anwender nicht beschreibbar abgelegt. Die Summenwertigkeit aller geschützten Funktionsbausteine eines Herstellers muß durch die Wertigkeit 34 auf dem Wertigkeitsbaustein 32 des entsprechenden Herstellers gedeckt werden, damit ausreichende Nutzungsrechte vorliegen.
Eme Verschlüsselung der Daten ist nicht notwendig, wenn der Inhalt von Wertigkeitsbausteinen und geschützten Funktionsbausteinen nicht vom Anwender ausgelesen werden kann. Bei SIMATIC S7 wird dies durch em Setzen des Attributs KNOWHOW- Protect mit ausreichender Sicherheit gewährleistet. Sollte der Schutz vor unerlaubten Zugriffen nicht ausreichen, müssen die Daten verschlüsselt werden.
Figur 4 zeigt die Bedienoberflache eines Tools zur Erstellung von Wertigkeitsbausteinen. Die Herstellerkennung, die in Figur 4 als OEM-Kennung bezeichnet wird, kann der OEM frei wählen. Sie besteht aus zwei Teilen. Der sichtbare Teil ist der OEM-Name, hier Fa. Softy, der für Anwender jederzeit lesbar ist, um zu identifizieren, von welchem Hersteller em Wertigkeitsbaustein oder eme geschützte Software stammt. Der zweite Teil ist e OEM-Password, das nur dem jeweiligen OEM bekannt ist und Anwendern verborgen bleibt. Damit wird em Mißbrauch verhindert, weil nur der OEM, der das Password kennt, m der Lage ist, Wertigkeitsbauste e zu erzeugen. Weiterhin kann in der n Figur 4 dargestellten Eingabemaske eine Seriennummer der Memory Card, hier als MC-Seriennummer bezeichnet, und eine Wertigkeit des Wertigkeitsbausteins ein- getragen werden.
Entsprechend Figur 5 kann immer im Anlauf eines elektronischen Geräts, beim Nachladen von Software oder m geeigneten Abstanden wahrend des Betriebs das ausreichende Vorhandensein von Nutzungsrechten überprüft werden. Auf einer Memory Card 50 sind Funktionsbausteine FB und eme Wertigkeit 51 hinterlegt. Zur Überprüfung der Nutzungsrechte werden durch die Recheneinheit mit Hilfe einer geeigneten Betriebssystem-Software in einem Schritt 52 das Steuerprogramm nach Funktions- baustemen FB durchsucht, die Emzelwertigkeiten ausgelesen und die Summenwertigkeit berechnet. In einem Schritt 53 wird die maximal zulassige Wertigkeit 51 für die Runtime-Software ausgelesen. Danach findet em Vergleich 54 zwischen der im Schritt 52 ermittelten Summenwertigkeit und der maximal zu- lassigen Wertigkeit 51 statt. Übersteigt die Summenwertigkeit die maximal zulassige Wertigkeit 51, wird m einem Schritt 55 ein Anzeigesignal ausgegeben und es erfolgen eventuell weitere Fehlerreaktionen. Andernfalls wird in einem Schritt 56 in den normalen Betrieb übergegangen. Dabei können alle ge- schützten Funktionsbausteine, die sich auf der Memory Card 50 befinden, erfaßt werden. Die Prüfung erfolgt dann unabhängig davon, ob eine Instanz eines Funktionsbausteintyps in einen Ablaufzyklus eingebaut ist oder nicht. Die jeweilige Ver- schaltung der Funktionsbausteine ist in Figur 5 durch einen Programmblock 57 dargestellt. Die beschriebene Überprüfung wird für jeden Hersteller gesondert durchgeführt.
Im folgenden wird eme alternative Möglichkeit zur Überprüfung der Wertigkeiten beschrieben, deren Ablauf m Figur 6 dargestellt ist. Die Funktionsbausteine FB schreiben jeweils beim ersten Aufruf einer durch den Funktionsbaustein realisierten Instanz ihre Wertigkeit und Herstellerkennung in eine Liste des Betriebssystems. Dieser Vorgang entspricht einem Schritt 60 des Ablaufs. Wurde das komplette Applikations- programm einmal durchlaufen, so kann davon ausgegangen werden, daß in der Liste die Wertigkeiten und Herstellerkennun- gen aller beteiligten Funktionsbausteine enthalten sind. In einem Schritt 61 wird die Liste ausgewertet, indem die Wertigkeiten zu einer Summenwertigkeit nach den jeweiligen Herstellerkennungen getrennt aufaddiert werden. In einem Schritt 62 werden die Wertigkeiten 63 aus den Wertigkeits- bausteinen ausgelesen und wiederum in einem Vergleich 64 mit den berechneten Summenwertigkeiten verglichen. Liegen ausreichende Nutzungsrechte vor, wird in einen normalen Betrieb 65 übergegangen, falls nicht, wird in einem Schritt 66 em Anzeigesignal ausgegeben und eme Reaktion eingeleitet. Bei dieser Art der Überprüfung werden nur die Funktionsbausteine FB erfaßt, die entsprechend einer Verschaltung 67 in den Ablauf der Runtime-Software eingebaut sind.
Für die anhand der Figuren 5 und 6 beschriebenen Varianten gilt, daß die Überprüfung vorzugsweise im Anlauf der Recheneinheit des elektronischen Geräts durchgeführt werden muß. Bei Recheneinheiten, die em Entfernen der Einrichtung mit den hinterlegten, maximal zulassigen Wertigkeiten wahrend des laufenden Betriebs ohne Störung zulassen, sollte die Uber- prufung zusätzlich in angemessenen Zeitabstanden erfolgen.
Je nach Anwendung sind verschiedene Reaktionen bei fehlenden Nutzungsrechten möglich. Beispielsweise kann zusatzlich zur Ausgabe eines Anzeigesignals die Recheneinheit mit vermmder- ter Leistungsfähigkeit weiterarbeiten. Eme schwerwiegendere Konsequenz konnte darin bestehen, daß die Recheneinheit bei fehlenden Nutzungsrechten in einen Stoppzustand übergeht und somit das elektronische Gerat nicht funktionsfähig ist.
Um die Handhabung des Softwareschutzes bei Projektierung,
Test, Inbetriebsetzung oder Hardwareausfall zu vereinfachen, können dem Anwender des elektronischen Geräts zwei Hilfen angeboten werden. Die eine besteht darin, daß dem Anwender eine allgemein gültige Memory Card zur Verfugung gestellt wird, deren Wertigkeitsbausteine den Wert ∞ enthalten. Mit dieser Memory Card sind alle geschützten Bausteine unem- geschrankt ablauffähig. Die andere Hilfe besteht darin, über Parametrierung an einem Engineering-System die Recheneinheit des elektronischen Geräts in eme Betriebsart „Probebetrieb" zu schalten. In dieser Betriebsart wird keine Überprüfung der Wertigkeit vorgenommen. Wiederum sind alle geschützten Funk- tionsbausteme uneingeschränkt ablauffahig. Nach einer bestimmten Zeit, z. B. nach 200 Stunden, lauft der Probebetrieb ab und die beschriebenen Schutzmechanismen werden wieder wirksam.
Die Vermarktung von Wertigkeitsbaustemen kann beispielsweise über Versand erfolgen. Der Anwender bestellt dazu schriftlich oder telefonisch unter Nennung der Seriennummer der Memory Card einen Wertigkeitsbaustein mit einer bestimmten Wertigkeit beim Hersteller, dessen Funktionsbausteinbibliothek er verwendet. Der Hersteller kann beispielsweise der Hersteller des elektronischen Geräts oder em OEM sein. Bei diesem wird der Wertigkeitsbaustein erzeugt, auf Diskette gespielt und an den Besteller gegen Rechnung verschickt.
Eine andere, völlig automatisch abwickelbare Möglichkeit zur Vermarktung bietet das Internet. Der Anwender wählt sich in die Service-Homepage des Herstellers em und findet dort einen Menupunkt „Wertigkeitsbausteine bestellen" . Hier gibt er seinen Namen, seine E-mail-Adresse, die Seriennummer der Memory Card, die gewünschte Wertigkeit und die bevorzugte
Zahlungsart, z. B. Rechnung oder Kreditkarte, em und schickt die Bestellung ab. Em Server kann beim Hersteller automatisch anhand dieser Angaben einen Wertigkeitsbaustein erstellen und den Baustein per E-mail an den Besteller ab- schicken. Alternativ zu dem gezeigten Ausfuhrungsbeispiel kann ein Dongle, der hier als Memory Card ausgebildet ist, als em Hardwareschlussel implementiert werden, der im Stecker eines MPI-Verb dungskabels untergebracht oder, wenn keine MPI- Verbindung zum Einsatz kommt, als Blindstecker auf die MPI- Schnittstelle aufgesteckt wird. Diese Realisierungsvariante hat allerdings den Nachteil, daß em neuer Dongle entwickelt werden mußte, der eine neue, zusätzliche Hardwarekomponente darstellt. Der Dongle mußte zudem an zukunftige Weiter- entwicklungen der MPI-Schnittstelle angepaßt werden.
Alternativ zu den nachladbaren Wertigkeitsbaustemen kann eme Gesamtwertigkeit im Kennbitspeicher der Memory Card hinterlegt werden, die somit nicht durch Software anderbar ist. Diese Gesamtwertigkeit deckt den Wert sämtlicher geschützter Software von Systemhersteller und von OEM ab. Die Memory Cards werden mit unterschiedlichen Wertigkeiten produziert und erhalten als jeweils verschiedene Produkte auch unterschiedliche Bestellnummern. D. h., bei n verschiedenen Wertigkeiten müssen n verschiedene Typen von Memory Cards als Produkte gehalten und bevorratet werden. Bei dieser Variante ist keine Unterscheidung zwischen Systemhersteller und OEM möglich, da lediglich eine Gesamtwertigkeit für beide gemeinsam hinterlegt wird. Da die Wertigkeit nicht nachtraglich ge- ändert werden kann, entstehen die oben beschriebenen „Wertig- keitsleichen" .
Eine weitere Variante entsteht, wenn im Kennbitspeicher der Memory Card feste Summenwertigkeiten jeweils für System- hersteiler und OEM getrennt hinterlegt werden. Somit kann beim Softwareschutz zwischen der Software des Systemherstellers und des OEM unterschieden werden. Die Memory Cards werden mit unterschiedlichen Wertigkeiten produziert, wobei ede Wertigkeitskombmation einem eigenständigen Pro- dukt mit Bestellnummer entspricht. Demgemäß vervielfacht sich die Anzahl der Produkte, die bevorratet werden müssen. Zu- satzlich kann die OEM-Kennung den jeweiligen Wertigkeiten zugeordnet werden.
Als weitere Alternative kann eine Memory Card geschaffen wer- den, deren Kennbitspeicher über einen Bereich verfugt, in welchen Anwenderdaten geschrieben werden können. Dieser Bereich sollte allerdings nur zuganglich sein, wenn der zugehörige Programmiermechanismus bekannt ist. Dort werden die Wertigkeit und die OEM-Kennung hinterlegt. Ein OEM benotigt in diesem Fall em spezielles Programmiertool mit dem Programmiermechanismus, um auf diesen Bereich des Kennbitspeichers zugreifen zu können. Dieses Programmiertool kann als Erweiterung eines vom Hersteller der Memory Card zur Verfugung gestellten Engineering-Systems realisiert werden. Bei dieser Variante können OEMs die Wertigkeit und ihre
Kennung selbst andern. Somit müssen weniger Produkte bevorratet werden und der Schutz ist mit einem geringeren Aufwand verbunden.
Abweichend von dem beschriebenen Ausfuhrungsbeispiel können Wertigkeitsbausteme m den Speicher 2 oder 3 des elektronischen Geräts geladen werden, so daß der Speicherbereich der Einrichtung 12, m welchem eme maximal zulassige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, durch einen Teil des Speichers 2 bzw. 3 ersetzt wird. In diesem
Fall tragt die Einrichtung 12 eme eindeutige Identifikation, beispielsweise eme Seriennummer, und wird vorzugsweise als austauschbares Hardwaremodul ausgebildet.

Claims

Patentansprüche
1. Elektronisches Gerat mit Softwareschutz
- mit einer Recheneinheit (1) zur Abarbeitung eines Pro- gramms,
- mit einem Speicher (2) , in den eme Betriebssystem- Software für die Recheneinheit (1) geladen ist,
- mit einem Speicher (3), in den Runtime-Software geladen ist, die zumindest einen Funktionsbaustein (7 ... 11) enthalt, der mit einer Wertigkeit versehen ist,
- mit einer Einrichtung (2, 3, 12) , m welcher eme maximal zulassige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist,
- wobei Mittel vorhanden sind zur Bestimmung der Summen- Wertigkeit der Funktionsbausteine (4 ... 11) der
Runtime-Software und zur Ausgabe eines Anzeigesignais (14), wenn die Summenwertigkeit die maximal zulassige Wertigkeit übersteigt.
2. Elektronisches Gerat nach Anspruch 1, dadurch gekennzeichnet ,
- daß die Einrichtung (12), in welcher die maximal zulassige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, als em in das elektronische Gerat einsetzbares oder an das elektronische Gerat anschließbares Hardwaremodul ausgebildet ist.
3. Elektronisches Gerat nach Anspruch 2, dadurch gekennzeichnet, - daß das Hardwaremodul eme Memory Card ist.
4. Elektronisches Gerat nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
- daß eme Einrichtung (12) vorgesehen ist, die eme ein- deutige Identifikation, insbesondere eme Seriennummer
(21) , aufweist, und - daß die hinterlegte Wertigkeit als ladbarer Wertigkeitsbaustein (22, 23, 24) ausgebildet ist, der nur für die Einrichtung (13) mit der jeweiligen Identifikation Gültigkeit besitzt.
5. Elektronisches Gerät nach Anspruch 4, dadurch gekennzeichnet,
- daß die Funktionsbausteine in Gruppen, insbesondere nach Herstellern, untergliedert sind, - daß jeder Gruppe ein Wertigkeitsbaustein (22, 23, 24) zugeordnet ist und
- daß Mittel vorhanden sind zur Bestimmung der Summenwertigkeit der Funktionsbausteine einer Gruppe und zur Ausgabe eines Anzeigesignals, wenn die Summenwertigkeit die maximal zulässige Wertigkeit des jeweiligen Wertigkeitsbausteins übersteigt.
6. Einrichtung, die als ein in ein elektronisches Gerät nach einem der vorhergehenden Ansprüche einsetzbares oder an das elektronische Gerät anschließbares Hardwaremodul, insbesondere als Memory Card, ausgebildet ist, dadurch gekennzeichnet,
- daß in der Einrichtung eine maximal zulässige Wertigkeit für eine Runtime-Software und/oder eine eindeutige Identi- fikation, insbesondere eine Seriennummer, durch das elektronische Gerät auslesbar hinterlegt ist.
7. Funktionsbaustein zur Verwendung in der Runtime-Software eines elektronischen Geräts nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet,
- daß der Funktionsbaustein mit einer Wertigkeit versehen ist.
EP00983028A 1999-10-18 2000-10-17 Elektronisches gerät mit softwareschutz Withdrawn EP1226484A2 (de)

Applications Claiming Priority (3)

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

Publications (1)

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

Family

ID=7926110

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00983028A Withdrawn EP1226484A2 (de) 1999-10-18 2000-10-17 Elektronisches gerät mit softwareschutz

Country Status (6)

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

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
US5551033A (en) * 1991-05-17 1996-08-27 Zenith Data Systems Corporation Apparatus for maintaining one interrupt mask register in conformity with another in a manner invisible to an executing program
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 (en) * 1994-12-16 1996-06-20 Graphisoft R & D Software Development Company Limited By Shares Software usage metering system
EP1555591B1 (de) * 1995-02-13 2013-08-14 Intertrust Technologies Corp. Verfahren und Vorrichtung zur gesicherten Transaktionsverwaltung
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 (en) * 1996-01-24 1997-07-31 Sun Microsystems, Inc. Instruction folding for a stack-based machine
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
US6308256B1 (en) * 1999-08-18 2001-10-23 Sun Microsystems, Inc. Secure execution of program instructions provided by network interactions with processor
US6757831B1 (en) * 1999-08-18 2004-06-29 Sun Microsystems, Inc. Logic block used to check instruction buffer configuration
US6665796B1 (en) * 1999-08-18 2003-12-16 Sun Microsystems, Inc. Microprocessor instruction result obfuscation
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
JP2001222424A (ja) * 2000-02-08 2001-08-17 Fujitsu Ltd ソフトウェアライセンス管理装置，ソフトウェアライセンス管理方法およびソフトウェアライセンス管理用プログラム記録媒体
US7165824B2 (en) * 2002-12-02 2007-01-23 Silverbrook Research Pty Ltd Dead nozzle compensation

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
WO2001029638A3 (de) 2001-11-22
WO2001029638A2 (de) 2001-04-26
DE19950249C1 (de) 2001-02-01
JP2003512667A (ja) 2003-04-02
CN1409834A (zh) 2003-04-09

Similar Documents

Publication Publication Date Title
DE3611223C2 (de)
DE19612999C2 (de) System zur Sicherung geschützter Software gegen unbefugte Benutzung in Rechnernetzwerken
DE112007003231B4 (de) Programmierbare Anzeigevorrichtung und Steuersystem
DE4123126C1 (de)
EP0829046B1 (de) Setup-verfahren und setup-system für benutzerprogramme, sowie benutzerrechner in einem rechnernetz
DE4115152A1 (de) Datenschuetzende mikroprozessorschaltung fuer tragbare datentraeger, beispielsweise kreditkarten
DE10004822A1 (de) System und Verfahren zur Identifizierung und zum beschleunigten Zugriff auf Online-Dienste
DE19918640A1 (de) Verfahren und System zum Liefern einer kundenspezifischen Softwareinstallation an ein Computersystem
DE10155752A1 (de) Lizenzierungsverfahren
DE19950249C1 (de) Elektronisches Gerät mit Softwareschutz
DE10023820B4 (de) Software-Schutzmechanismus
DE19963471A1 (de) Verfahren und Vorrichtung zur Verhinderung von Raubkopien von Computerprogrammen
DE112010004264B4 (de) Selektiver Schreibschutz für das Austesten der Wiederherstellung nach einem Absturz
WO2001088669A1 (de) Lizenzmanager
EP0464320A2 (de) Verfahren zum Erzeugen eines individuellen Datenträgerschutzes gegen eine unautorisierte Benutzung
EP0966711B1 (de) Mikrocomputer mit einer speicherverwaltungseinheit
EP2711794B1 (de) Verfahren zur zeitweiligen Separierung von Objektdaten von Entwurfsmodellen
DE4103173C2 (de) Vorrichtung zum Schutz gegen unautorisierte Benutzung von Software
WO1993023807A1 (de) Programmsicherungsverfahren zum schutz einer datenverarbeitungsanlage
DE19701323C2 (de) Verfahren und Vorrichtung zur Aktualisierung der Betriebssoftware
EP3309698B1 (de) Verfahren zum betreiben eines computersystems
DE102015119140A1 (de) Verfahren zum Steuern des Zugriffs auf verschlüsselte Dateien und Computersystem
EP1329903B1 (de) Speichereinrichtung, die durch eine einen oder mehrere Schreibzugriffe umfassende Kommandosequenz in eine Testbetriebsart versetzbar ist
DE4302634A1 (de) Rechner
DE102022116086A1 (de) Verfahren zur Bereitstellung von Programmen für Steuerungseinrichtungen technischer Einrichtungen

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