DE19950249C1 - Elektronisches Gerät mit Softwareschutz - Google Patents
Elektronisches Gerät mit SoftwareschutzInfo
- Publication number
- DE19950249C1 DE19950249C1 DE19950249A DE19950249A DE19950249C1 DE 19950249 C1 DE19950249 C1 DE 19950249C1 DE 19950249 A DE19950249 A DE 19950249A DE 19950249 A DE19950249 A DE 19950249A DE 19950249 C1 DE19950249 C1 DE 19950249C1
- Authority
- DE
- Germany
- Prior art keywords
- value
- software
- electronic device
- protected
- runtime
- 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.)
- Expired - Fee Related
Links
- 230000004224 protection Effects 0.000 title claims description 35
- 238000012545 processing Methods 0.000 claims abstract description 3
- 230000006870 function Effects 0.000 claims description 48
- 238000000034 method Methods 0.000 abstract description 5
- 230000008569 process Effects 0.000 abstract description 3
- 230000007246 mechanism Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 238000007792 addition Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000009993 protective function Effects 0.000 description 2
- 206010022528 Interactions Diseases 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003292 diminished effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000009979 protective mechanism Effects 0.000 description 1
- 108090000623 proteins and genes Proteins 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
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
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
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 daß Systemhersteller und OEM unabhängig voneinander einen Softwareschutz gestalten können.
Description
Die Erfindung betrifft ein elektronisches Gerät mit Soft
wareschutz. Das elektronische Gerät weist eine Recheneinheit
zur Abarbeitung eines Progranms 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 Soft
ware 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 Automatisierungs
geräten, bei denen durch Zusammenschalten verschiedener Funk
tionsbausteine 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 Software
produkten für Personal Computer üblich ist. Schutz vor un
erlaubter Mehrfachverwendung bedeutet, daß eine Software auf
einem Automatisierungsgerät nur dann abläuft, wenn der An
wende das Recht dazu erworben hat, d. h., wenn vom Her
steller eine Lizenz erteilt wurde.
Ein Schutz vor einer unerlaubten Mehrfachverwendung von
Software könnte an eine eindeutige Kennung des elektronischen
Geräts, beispielsweise eine Seriennummer, gekoppelt werden.
Die Software könnte so ausgeführt werden, daß sie nur auf dem
Zielsystem ablauffähig wäre, für das sie freigegeben wurde.
Das hätte 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 Ziel
systems schwer möglich wäre.
Eine weitere Möglichkeit zum Schutz vor unerlaubter Mehrfach
verwendung wäre es, im Engineering-System das Laden von ge
schützter Software auf ein Zielsystem anhand einer eindeuti
gen Kennung des Zielsystems, z. B. einer Seriennummer, zu
überwachen. Auch diese Möglichkeit wird verworfen, da Ziel
systeme meist nicht über eine Seriennummer verfügen und ein
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 Engi
neering-System beschränkt. Deshalb wären beim Engineering-
System zusätzliche Maßnahmen für einen Softwarekopierschutz
erforderlich.
Alternativ könnte die geschützte Software mit Namensdekla
rationen, z. B. einem Projektnamen, verknüpft werden. Das
Engineering-System müß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
würde damit nicht erfüllt.
Eine weitere Möglichkeit könnte darin gesehen werden, die
Vervielfältigung von geschützter Runtime-Software durch ein
Kopierschutzprogramm ähnlich dem Programm "StopCopy" zu
unterbinden. Dieser Kopierschutz müßte sowohl im Bereich der
Engineering-Systeme als auch der Zielsysteme wirken. Hin
sichtlich eines solchen Kopierschutzes bestehen jedoch Ak
zeptanzprobleme beim Systemhersteller und beim Anwender wegen
des schwierigen Handlings, insbesondere bei verlorenen Nut
zungsrechten. Zudem müßte der Schutzmechanismus in der Soft
ware des Engineering-Systems und auf allen Komponenten des
Zielsystems implementiert werden.
Aus der US-PS 5 870 726 ist ein elektronisches Gerät mit
einer Recheneinheit bekannt, bei welchem eine Chipkarte zum
Schutz der Software verwendet wird. Die Software kann aus
mehreren Teilen bestehen, in denen jeweils ein Betriebssys
temaufruf zum Zugriff auf die Chipkarte enthalten ist. Bei
diesem Zugriff wird geprüft, ob ein ausreichendes Guthaben
für die Benutzung der Software vorhanden ist.
Aus der US-PS 5 671 412 ist ein Verfahren zur Verwaltung von
Software-Lizenzen bekannt. Dabei wird ein Softwarepaket mit
verschiedenen, genau aufgelisteten Einzelkomponenten betrach
tet und sichergestellt, dass nur diejenigen Einzelkomponenten
benutzt werden, auf die sich die Paketlizenz eines Benutzers
erstreckt.
Der Erfindung liegt die Aufgabe zugrunde, ein elektronisches
Gerät zu schaffen, das mit einem wirkungsvollen Schutz gegen
unerlaubte Mehrfachverwendung von Software ausgestattet ist
und sich durch eine gute Handhabbarkeit der Software bei Her
steller und Anwender auszeichnet.
Zur Lösung dieser Aufgabe weist das neue elektronische Gerät
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 Gerät geeignet sind. Vorteilhafte
Weiterbildungen der Erfindung sind in den Unteransprüchen
angegeben.
In vorteilhafter Weise wird durch die Erfindung ein Schutz
von Runtime-Software ermöglicht, die auf ein Zielsystem ge
laden wird und auf dem Zielsystem abläuft. Unter dem Begriff
"Funktionsbausteine der Runtime-Software" werden System
funktionsbausteine, Standardfunktionsbausteine, Anwender
funktionsbausteine, mit Hilfe eines grafischen Projektie
rungswerkzeugs, das auch als Continuous-Function-Chart be
zeichnet wird, erzeugte Funktionsbausteine, ladbare Treiber,
Betriebssystem-Add-Ons oder andere, auf eine Recheneinheit
ladbare, optionale Softwaremodule verstanden.
Generell können beim Softwareschutz zwei Ausprägungen unter
schieden werden. Das ist zum einen der technologische Schutz
und zum anderen der Schutz vor einer unerlaubten Mehrfach
verwendung. 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 technologi
sche oder softwaretechnische Know-how des Herstellers ge
schützt. Der technologische Schutz ist beispielsweise bei
SIMATIC S7-Automatisierungssystemen der Siemens AG durch das
Attribut KNOWHOW-Protect gewährleistet. Die durch Software-
Funktionsbausteine 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 Program
men bezeichnet. Dies können beispielsweise Systemfunktions
bausteine, Funktionsbausteine für technologische Funktionen
und Betriebssystemfunktionsbausteine sein.
Ein Nutzungsrecht erlaubt dem Anwender die Nutzung der Soft
ware auf einem Zielsystem, beispielsweise einem Automatisie
rungsgerät. 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 entspre
chend 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. Eine Nutzung ist nur möglich, wenn für ge
schützte Software ein entsprechender Gegenwert in der Ein
richtung hinterlegt ist. Der Mehraufwand beim Systemherstel
ler für das Handling von geschützter Software ist im Ver
gleich zum Handling von ungeschützter Software in 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 ge
ringfü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 günstig aus, daß im störungsfreien Betrieb keine Inter
aktionen über eine Hotline zwischen Anwender und Hersteller
erforderlich sind. Es müssen z. B. keine Registrierungs- oder
Autorisierungsnummern zum Betrieb der Software angefordert
werden. Ist die hinterlegte Wertigkeit im elektronischen
Gerät 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, be
einflussen nicht die Verwendung von geschützter Software.
Beim Handling neuer Versionen kommen keine neuen Schutz
mechanismen hinzu.
Der Schutz ist nicht an die einzelne Softwarekomponente,
sondern an ihre Wertigkeit gekoppelt. Dadurch ergibt sich
eine wesentlich einfachere und flexiblere Handhabung beim
Systemhersteller wie beim Anwender. Z. B. ist ein Austausch
oder eine Ergänzung von geschützten Softwarekomponenten ohne
weiteres möglich, solange der Wert des Nutzungsrechts aus
reichend 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ütz
te 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 Kopierschutz
programmen verbundene Probleme werden somit vermieden. Der
Wertigkeit kann direkt und flexibel ein Preis zugeordnet
werden.
Die Einrichtung, in welcher die maximal zulässige Wertigkeit
für die Runtime-Software auslesbar hinterlegt ist, als ein in
das elektronische Gerät einsetzbares oder an das elektroni
sche Gerät anschließbares Hardwaremodul auszubilden, hat den
Vorteil, daß eine leichte Anpaßbarkeit der Wertigkeit bei
Softwareänderungen erreicht wird. Zudem ist der Schutz der
Software ohne einen aufwendigen Eingriff in die Hardware des
elektronischen Geräts realisierbar. Wenn der Anwender ge
schützte Software einsetzt, benötigt 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ütz
ter 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 ins
besondere bei Automatisierungsgeräten den Vorteil, daß keine
zusätzliche Hardwarekomponente erforderlich ist, da eine
Memory Card ohnehin meist eingesetzt wird. Ein komplizierter
Hardwareeingriff ist überflüssig, da die Memory Card in ein
facher Weise in den dafür vorgesehenen Schacht eingeschoben
werden kann. Die Sicherheit einer Memory Card ist für die
Schutzfunktion ausreichend. Ein Erstellen einer Kopie mit
ebenfalls gültiger Wertigkeit ist nicht ohne weiteres mög
lich.
Vorteilhaft kann die Einrichtung, in welcher die maximal zu
lässige Wertigkeit für die Runtime-Software auslesbar hinter
legt 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
erhöhen, indem ein anderer Wertigkeitsbaustein mit dem be
nötigten Wert in die Einrichtung geladen wird. Die Vermark
tung von Wertigkeitsbausteinen ist beispielsweise über Inter
net automatisierbar. Ein Handling von Hardwarekomponenten ist
dazu nicht erforderlich. Damit werden sogenannte Wertigkeits
leichen vermieden. Mit dem Begriff "Wertigkeitsleiche" wird
eine Einrichtung bezeichnet, in der eine maximal zulässige
Wertigkeit fest hinterlegt ist, die für den konkreten An
wendungsfall nicht mehr ausreichend ist, z. B. weil die
Anwendung zwischenzeitlich um weitere geschützte Software
komponenten ergänzt wurde. Da eine Erhöhung der Wertigkeit
ohne nachladbare Wertigkeitsbausteine entweder gänzlich un
möglich wäre oder nur vom Hersteller der Einrichtung vor
genommen werden könnte, wäre eine derartige Einrichtung für
den Anwender wertlos geworden. Wertigkeitsbausteine integrie
ren sich nahtlos in die bestehende Softwarelandschaft von
Automatisierungsgeräten, da es sich prinzipiell um Funktions
bausteine handelt.
Wenn die Funktionsbausteine in Gruppen, insbesondere nach
Herstellern, mit jeweils zugeordneten Wertigkeitsbausteinen
untergliedert werden, hat dies den Vorteil, daß Funktions
bausteine verschiedener Hersteller über eine einzige Ein
richtung, auf welcher jeweils die maximal zulässigen Wertig
keiten hinterlegt sind, geschützt werden können. Bei nach
ladbaren 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 elek
tronischen Geräts schützen. Eine Wertigkeitsvergabe oder Er
höhung beim Anwender ist unmittelbar, lokal und hardware
unabhängig vom Systemhersteller oder OEM möglich. Ein Ver
senden beispielsweise einer neuen Memory Card, auf welcher
die neue, maximal zulässige Wertigkeit hinterlegt ist, ist
nicht erforderlich, da eine datentechnische Kopplung zur
Hinterlegung einer neuen Wertigkeit ausreicht.
Anhand der Zeichnungen, in denen ein Ausführungsbeispiel der
Erfindung dargestellt ist, werden im folgenden die Erfindung
sowie Ausgestaltungen und Vorteile näher erläutert.
Es zeigen:
Fig. 1 ein Blockschaltbild eines elektronischen Geräts mit
Softwareschutz,
Fig. 2 ein Blockschaltbild einer Einrichtung, in welcher
Wertigkeiten hinterlegt sind,
Fig. 3 eine Einrichtung zur Hinterlegung von Wertigkeiten
und Funktionsbausteinen zur Verdeutlichung des
Wirkungsprinzips,
Fig. 4 eine Eingabemaske zur Erstellung von Wertigkeits
bausteinen,
Fig. 5 und Fig. 6 jeweils ein Ablaufschema zur Überprüfung
ausreichender Nutzungsrechte.
Gemäß Fig. 1 ist ein elektronisches Gerät mit einer Rechen
einheit 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 Automatisierungsgeräten an die je
weilige Steuerungsaufgabe angepaßt ist. In dem gezeigten Aus
führungsbeispiel 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 Nutzungs
rechts darstellt. Jedem geschützten Funktionsbaustein ist
somit eine Wertigkeit zugeordnet. Ein Anwender, der die ge
schützten Funktionsbausteine einsetzen möchte, erwirbt ein
Nutzungsrecht mit einem bestimmten Wert. Dieses Nutzungsrecht
wird durch eine maximal zulässige Wertigkeit für die Runtime-
Software wiedergegeben, die in einer Einrichtung 12 auslesbar
hinterlegt ist. Der Anwender kann geschützte Software ein
setzen, solange die Summenwertigkeit der geschützten Software
durch den Wert des Nutzungsrechts gedeckt ist. Die maximal
zulässige Wertigkeit ist gemeinsam mit der Runtime-Software
auf einer Memory Card 13 abgespeichert. Alternativ zum dar
gestellten Ausführungsbeispiel kann auch der Speicher für die
Betriebssystem-Software auf demselben Speichermedium angeord
net werden. Die Recheneinheit 1 überprüft anhand der Be
triebssystem-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.
Fig. 2 zeigt eine Memory Card 13 zur Realisierung der Ein
richtung 12 mit nachladbaren Wertigkeitsbausteinen. In einem
Kennbitspeicher 20 der Memory Card 13 ist eine Seriennummer
21 in einer Speicherzelle hinterlegt, die nur durch den Her
steller der Memory Card 13 und nicht durch den Anwender be
schrieben werden kann. Diese Seriennummer 21 ermöglicht eine
eindeutige Identifizierung der Memory Card 13. Wertigkeits
bausteine 22, 23 und 24 sind herstellerspezifisch und in
einem freien Speicherbereich 25 der Memory Card 13 hinter
legt. 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 Fig. 2
der Übersichtlichkeit wegen nicht dargestellt ist. Wertig
keitsbausteine sind hinsichtlich der Softwarestruktur mit
Funktionsbausteinen identisch und somit wie Funktionsbau
steine handhabbar. Sie haben allerdings keinen ablauffähigen
Programmcode. Gültigkeit besitzen die Wertigkeitsbausteine
22, 23 und 24 nur in Verbindung mit einer bestimmten Serien
nummer 21.
Die Abhängigkeiten zwischen Seriennummer, Wertigkeitsbaustein
und geschütztem Funktionsbaustein sind in Fig. 3 darge
stellt. Beispielsweise enthält ein geschützter Funktionsbau
stein 30 eine Herstellerkennung 31, die aus einem lesbaren
Herstellernamen und einem dem Anwender versteckten Password
besteht. Dieselbe Herstellerkennung muß auch als Hersteller
kennung 38 in einem Wertigkeitsbaustein 32 vorhanden sein,
damit dieser eindeutig dem Hersteller des Funktionsbausteins
30 zugeordnet werden kann. Für den Anwender wiederum un
zugänglich sind im Wertigkeitsbaustein 32 eine Seriennummer
33 und eine maximal zulässige Wertigkeit 34 abgelegt. Über
die Seriennummer 33 wird die Einmaligkeit des Wertigkeits
bausteins 32 sichergestellt und gewährleistet, daß er nur für
die Einrichtung Gültigkeit besitzt, deren in einem Kennbit
speicher 35 abgelegte Seriennummer 37 mit der Seriennummer 33
des Wertigkeitsbausteins 32 übereinstimmt. Durch die Über
prüfung der Seriennummern 33 und 37 auf Übereinstimmung wird
eine mehrfache Verwendung von Wertigkeitsbausteinen ver
hindert. Weiterhin ist im Funktionsbaustein 30 eine Wertig
keit 36, d. h. ein 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.
Eine Verschlüsselung der Daten ist nicht notwendig, wenn der
Inhalt von Wertigkeitsbausteinen und geschützten Funktions
bausteinen nicht vom Anwender ausgelesen werden kann. Bei
SIMATIC S7 wird dies durch ein 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.
Fig. 4 zeigt die Bedienoberfläche eines Tools zur Erstellung
von Wertigkeitsbausteinen. Die Herstellerkennung, die in
Fig. 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 les
bar ist, um zu identifizieren, von welchem Hersteller ein
Wertigkeitsbaustein oder eine geschützte Software stammt. Der
zweite Teil ist ein OEM-Password, das nur dem jeweiligen OEM
bekannt ist und Anwendern verborgen bleibt. Damit wird ein
Mißbrauch verhindert, weil nur der OEM, der das Password
kennt, in der Lage ist, Wertigkeitsbausteine zu erzeugen.
Weiterhin kann in der in Fig. 4 dargestellten Eingabemaske
eine Seriennummer der Memory Card, hier als MC-Seriennummer
bezeichnet, und eine Wertigkeit des Wertigkeitsbausteins ein
getragen werden.
Entsprechend Fig. 5 kann immer im Anlauf eines elektroni
schen Geräts, beim Nachladen von Software oder in geeigneten
Abständen während des Betriebs das ausreichende Vorhandensein
von Nutzungsrechten überprüft werden. Auf einer Memory Card
50 sind Funktionsbausteine FB und eine Wertigkeit 51 hinter
legt. Zur Überprüfung der Nutzungsrechte werden durch die
Recheneinheit mit Hilfe einer geeigneten Betriebssystem-Soft
ware in einem Schritt 52 das Steuerprogramm nach Funktions
bausteinen FB durchsucht, die Einzelwertigkeiten ausgelesen
und die Summenwertigkeit berechnet. In einem Schritt 53 wird
die maximal zulässige Wertigkeit 51 für die Runtime-Software
ausgelesen. Danach findet ein Vergleich 54 zwischen der im
Schritt 52 ermittelten Summenwertigkeit und der maximal zu
lässigen Wertigkeit 51 statt. Übersteigt die Summenwertigkeit
die maximal zulässige Wertigkeit 51, wird in einem Schritt 55
ein Anzeigesignal ausgegeben und es erfolgen eventuell wei
tere 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 Fig. 5 durch einen
Programmblock 57 dargestellt. Die beschriebene Überprüfung
wird für jeden Hersteller gesondert durchgeführt.
Im folgenden wird eine alternative Möglichkeit zur Über
prüfung der Wertigkeiten beschrieben, deren Ablauf in Fig. 6
dargestellt ist. Die Funktionsbausteine FB schreiben jeweils
beim ersten Aufruf einer durch den Funktionsbaustein reali
sierten 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 wer
den, 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 aus
reichende Nutzungsrechte vor, wird in einen normalen Betrieb
65 übergegangen, falls nicht, wird in einem Schritt 66 ein
Anzeigesignal ausgegeben und eine Reaktion eingeleitet. Bei
dieser Art der Überprüfung werden nur die Funktionsbausteine
FB erfaßt, die entsprechend einer Verschaltung 67 in den Ab
lauf der Runtime-Software eingebaut sind.
Für die anhand der Fig. 5 und 6 beschriebenen Varianten
gilt, daß die Überprüfung vorzugsweise im Anlauf der Rechen
einheit des elektronischen Geräts durchgeführt werden muß.
Bei Recheneinheiten, die ein Entfernen der Einrichtung mit
den hinterlegten, maximal zulässigen Wertigkeiten während des
laufenden Betriebs ohne Störung zulassen, sollte die Über
prüfung zusätzlich in angemessenen Zeitabständen erfolgen.
Je nach Anwendung sind verschiedene Reaktionen bei fehlenden
Nutzungsrechten möglich. Beispielsweise kann zusätzlich zur
Ausgabe eines Anzeigesignals die Recheneinheit mit verminder
ter Leistungsfähigkeit weiterarbeiten. Eine schwerwiegendere
Konsequenz könnte darin bestehen, daß die Recheneinheit bei
fehlenden Nutzungsrechten in einen Stoppzustand übergeht und
somit das elektronische Gerät 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 Verfügung gestellt
wird, deren Wertigkeitsbausteine den Wert ~ enthalten. Mit
dieser Memory Card sind alle geschützten Bausteine unein
geschränkt ablauffähig. Die andere Hilfe besteht darin, über
Parametrierung an einem Engineering-System die Recheneinheit
des elektronischen Geräts in eine Betriebsart "Probebetrieb"
zu schalten. In dieser Betriebsart wird keine Überprüfung der
Wertigkeit vorgenommen. Wiederum sind alle geschützten Funk
tionsbausteine uneingeschränkt ablauffähig. Nach einer be
stimmten Zeit, z. B. nach 200 Stunden, läuft der Probebetrieb
ab und die beschriebenen Schutzmechanismen werden wieder
wirksam.
Die Vermarktung von Wertigkeitsbausteinen kann beispielsweise
über Versand erfolgen. Der Anwender bestellt dazu schriftlich
oder telefonisch unter Nennung der Seriennummer der Memory
Card einen Wertigkeitsbaustein mit einer bestimmten Wertig
keit beim Hersteller, dessen Funktionsbausteinbibliothek er
verwendet. Der Hersteller kann beispielsweise der Hersteller
des elektronischen Geräts oder ein 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 ein und findet dort
einen Menüpunkt "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, ein und schickt
die Bestellung ab. Ein Server kann beim Hersteller automa
tisch anhand dieser Angaben einen Wertigkeitsbaustein er
stellen und den Baustein per E-mail an den Besteller ab
schicken.
Alternativ zu dem gezeigten Ausführungsbeispiel kann ein
Dongle, der hier als Memory Card ausgebildet ist, als ein
Hardwareschlüssel implementiert werden, der im Stecker eines
MPI-Verbindungskabels untergebracht oder, wenn keine MPI-
Verbindung zum Einsatz kommt, als Blindstecker auf die MPI-
Schnittstelle aufgesteckt wird. Diese Realisierungsvariante
hat allerdings den Nachteil, daß ein neuer Dongle entwickelt
werden müßte, der eine neue, zusätzliche Hardwarekomponente
darstellt. Der Dongle müßte zudem an zukünftige Weiter
entwicklungen der MPI-Schnittstelle angepaßt werden.
Alternativ zu den nachladbaren Wertigkeitsbausteinen kann
eine Gesamtwertigkeit im Kennbitspeicher der Memory Card
hinterlegt werden, die somit nicht durch Software änderbar
ist. Diese Gesamtwertigkeit deckt den Wert sämtlicher ge
schützter Software von Systemhersteller und von OEM ab. Die
Memory Cards werden mit unterschiedlichen Wertigkeiten pro
duziert 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 gemein
sam hinterlegt wird. Da die Wertigkeit nicht nachträglich 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
hersteller und OEM getrennt hinterlegt werden. Somit kann
beim Softwareschutz zwischen der Software des System
herstellers und des OEM unterschieden werden. Die Memory
Cards werden mit unterschiedlichen Wertigkeiten produziert,
wobei jede Wertigkeitskombination einem eigenständigen Pro
dukt mit Bestellnummer entspricht. Demgemäß vervielfacht sich
die Anzahl der Produkte, die bevorratet werden müssen. Zu
sätzlich kann die OEM-Kennung den jeweiligen Wertigkeiten
zugeordnet werden.
Als weitere Alternative kann eine Memory Card geschaffen wer
den, deren Kennbitspeicher über einen Bereich verfügt, in
welchen Anwenderdaten geschrieben werden können. Dieser Be
reich sollte allerdings nur zugänglich sein, wenn der zu
gehörige Programmiermechanismus bekannt ist. Dort werden die
Wertigkeit und die OEM-Kennung hinterlegt. Ein OEM benötigt
in diesem Fall ein spezielles Programmiertool mit dem Pro
grammiermechanismus, um auf diesen Bereich des Kennbit
speichers zugreifen zu können. Dieses Programmiertool kann
als Erweiterung eines vom Hersteller der Memory Card zur
Verfügung gestellten Engineering-Systems realisiert werden.
Bei dieser Variante können OEMs die Wertigkeit und ihre
Kennung selbst ändern. Somit müssen weniger Produkte bevor
ratet werden und der Schutz ist mit einem geringeren Aufwand
verbunden.
Abweichend von dem beschriebenen Ausführungsbeispiel können
Wertigkeitsbausteine in den Speicher 2 oder 3 des elektroni
schen Geräts geladen werden, so daß der Speicherbereich der
Einrichtung 12, in welchem eine maximal zulässige Wertigkeit
für die Runtime-Software auslesbar hinterlegt ist, durch
einen Teil des Speichers 2 bzw. 3 ersetzt wird. In diesem
Fall trägt die Einrichtung 12 eine eindeutige Identifikation,
beispielsweise eine Seriennummer, und wird vorzugsweise als
austauschbares Hardwaremodul ausgebildet.
Claims (7)
1. Elektronisches Gerät mit Softwareschutz
- - mit einer Recheneinheit (1) zur Abarbeitung eines Pro gramms,
- - mit einem Speicher (2), in den eine 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) enthält, der mit einer Wertigkeit versehen ist,
- - mit einer Einrichtung (2, 3, 12), in welcher eine maximal zulässige 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 Anzeigesignals (14), wenn die Summenwertigkeit die maximal zulässige Wertigkeit übersteigt.
2. Elektronisches Gerät nach Anspruch 1, dadurch gekenn
zeichnet,
- - daß die Einrichtung (12), in welcher die maximal zulässige Wertigkeit für die Runtime-Software auslesbar hinterlegt ist, als ein in das elektronische Gerät einsetzbares oder an das elektronische Gerät anschließbares Hardwaremodul ausgebildet ist.
3. Elektronisches Gerät nach Anspruch 2, dadurch gekenn
zeichnet,
- - daß das Hardwaremodul eine Memory Card ist.
4. Elektronisches Gerät nach einem der vorhergehenden An
sprüche, dadurch gekennzeichnet,
- - daß eine Einrichtung (12) vorgesehen ist, die eine ein deutige Identifikation, insbesondere eine Seriennummer (21), aufweist, und
- - daß die hinterlegte Wertigkeit als ladbarer Wertigkeits baustein (22, 23, 24) ausgebildet ist, der nur für die Einrichtung (13) mit der jeweiligen Identifikation Gültig keit besitzt.
5. Elektronisches Gerät nach Anspruch 4, dadurch gekenn
zeichnet,
- - daß die Funktionsbausteine in Gruppen, insbesondere nach Herstellern, untergliedert sind,
- - daß jeder Gruppe ein Wertigkeitsbaustein (22, 23, 24) zu geordnet ist und
- - daß Mittel vorhanden sind zur Bestimmung der Summen wertigkeit der Funktionsbausteine einer Gruppe und zur Ausgabe eines Anzeigesignals, wenn die Summenwertigkeit die maximal zulässige Wertigkeit des jeweiligen Wertig keitsbausteins ü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, insbeson
dere als Memory Card, ausgebildet ist, dadurch gekenn
zeichnet,
- - 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 elek tronische 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.
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
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 |
CN00817048A CN1409834A (zh) | 1999-10-18 | 2000-10-17 | 具有软件保护的电子设备 |
JP2001532368A JP2003512667A (ja) | 1999-10-18 | 2000-10-17 | 電子装置 |
EP00983028A EP1226484A2 (de) | 1999-10-18 | 2000-10-17 | Elektronisches gerät mit softwareschutz |
US10/124,329 US20020129270A1 (en) | 1999-10-18 | 2002-04-18 | Electronic device for providing software protection |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19950249A DE19950249C1 (de) | 1999-10-18 | 1999-10-18 | Elektronisches Gerät mit Softwareschutz |
Publications (1)
Publication Number | Publication Date |
---|---|
DE19950249C1 true DE19950249C1 (de) | 2001-02-01 |
Family
ID=7926110
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19950249A Expired - Fee Related DE19950249C1 (de) | 1999-10-18 | 1999-10-18 | 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) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10105363B4 (de) * | 2001-02-06 | 2008-01-03 | Siemens Gebäudetechnik Bayern GmbH & Co. oHG | Speicherprogrammierbare Steuerung |
Families Citing this family (11)
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 |
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 | 浪潮通用软件有限公司 | 一种基于私有化部署的软件序列号授权方法及*** |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5671412A (en) * | 1995-07-28 | 1997-09-23 | Globetrotter Software, Incorporated | License management system for software applications |
US5870726A (en) * | 1994-05-25 | 1999-02-09 | Lorphelin; Vincent | Protected software rental using smart cards |
Family Cites Families (22)
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 |
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 |
AU4398196A (en) * | 1994-12-16 | 1996-07-03 | Graphisoft R&D Software Development Company Limited By Shares | Software usage metering system |
CN100501754C (zh) * | 1995-02-13 | 2009-06-17 | 英特特拉斯特技术公司 | 用于安全交易管理和电子权利保护的***和方法 |
US5761499A (en) * | 1995-12-21 | 1998-06-02 | Novell, Inc. | Method for managing globally distributed software components |
JP3801643B2 (ja) * | 1996-01-24 | 2006-07-26 | サン・マイクロシステムズ・インコーポレイテッド | スタックを用いる演算マシンのための命令フォールディング処理 |
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 |
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 |
US6308256B1 (en) * | 1999-08-18 | 2001-10-23 | Sun Microsystems, Inc. | Secure execution of program instructions provided by network interactions with processor |
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 |
-
1999
- 1999-10-18 DE DE19950249A patent/DE19950249C1/de not_active Expired - Fee Related
-
2000
- 2000-10-17 JP JP2001532368A patent/JP2003512667A/ja not_active Withdrawn
- 2000-10-17 WO PCT/DE2000/003649 patent/WO2001029638A2/de active Application Filing
- 2000-10-17 CN CN00817048A patent/CN1409834A/zh active Pending
- 2000-10-17 EP EP00983028A patent/EP1226484A2/de not_active Withdrawn
-
2002
- 2002-04-18 US US10/124,329 patent/US20020129270A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5870726A (en) * | 1994-05-25 | 1999-02-09 | Lorphelin; Vincent | Protected software rental using smart cards |
US5671412A (en) * | 1995-07-28 | 1997-09-23 | Globetrotter Software, Incorporated | License management system for software applications |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10105363B4 (de) * | 2001-02-06 | 2008-01-03 | Siemens Gebäudetechnik Bayern GmbH & Co. oHG | Speicherprogrammierbare Steuerung |
Also Published As
Publication number | Publication date |
---|---|
WO2001029638A2 (de) | 2001-04-26 |
EP1226484A2 (de) | 2002-07-31 |
WO2001029638A3 (de) | 2001-11-22 |
US20020129270A1 (en) | 2002-09-12 |
CN1409834A (zh) | 2003-04-09 |
JP2003512667A (ja) | 2003-04-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19612999C2 (de) | System zur Sicherung geschützter Software gegen unbefugte Benutzung in Rechnernetzwerken | |
DE3689569T2 (de) | Verfahren zur Systemdateiensicherung und Datenverarbeitungseinheit zu dessen Durchführung. | |
DE3611223C2 (de) | ||
DE3855475T2 (de) | Software-Verwaltungsstruktur | |
DE69927022T2 (de) | Verfahren zur steuerung der benutzung von softwarekomponenten | |
DE19950249C1 (de) | Elektronisches Gerät mit Softwareschutz | |
DE68926176T2 (de) | Verwaltungssystem für lizenzierte Programme | |
DE69228039T2 (de) | Lizenz-verwaltungssystem | |
DE69228350T2 (de) | Verwaltungssschnittstelle und format für lizenzverwaltungssystem | |
DE10155752A1 (de) | Lizenzierungsverfahren | |
DE102006007084B4 (de) | System zum Liefern von Programmen zu einer von einem Nutzer bedienbaren Vorrichtung | |
DE4235193A1 (de) | Netzwerksystem und zugehoeriges softwareverwaltungsverfahren | |
DE4033336A1 (de) | Verfahren zum erzeugen einer ausfallmeldung und mechanismus fuer ausfallmeldung | |
DE10004822A1 (de) | System und Verfahren zur Identifizierung und zum beschleunigten Zugriff auf Online-Dienste | |
EP0522332A1 (de) | Rechner für den Leitstand einer Maschine, insbesondere eine Druckmaschine | |
DE10023820B4 (de) | Software-Schutzmechanismus | |
DE19963471A1 (de) | Verfahren und Vorrichtung zur Verhinderung von Raubkopien von Computerprogrammen | |
EP1285322A1 (de) | Lizenzmanager | |
WO2001088670A2 (de) | Lizenzierung und zugangsauthorisierung | |
DE69729440T2 (de) | Prozessorssystem | |
EP0464320A2 (de) | Verfahren zum Erzeugen eines individuellen Datenträgerschutzes gegen eine unautorisierte Benutzung | |
DE102005033698A1 (de) | Verfahren zum Export von Nutzungsrechten an elektronischen Datenobjekten | |
EP1241570A2 (de) | Automatisierte Versions-Analyse von zu einer Softwareapplikation gehörenden Softwarekomponenten | |
EP3309698B1 (de) | Verfahren zum betreiben eines computersystems | |
DE10303452B4 (de) | Verfahren zur Steuerung der Unterbrechung und/oder der Aufzeichnung von Ausführungsdaten eines Programms in einem Mikrocontroller und Mikrocontroller mit einer Anordnung zur Durchführung des Verfahrens |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8100 | Publication of the examined application without publication of unexamined application | ||
D1 | Grant (no unexamined application published) patent law 81 | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |
Effective date: 20140501 |