Browse Prior Art Database

SOFTWARE FEATURE PROTECTION FOR REMOTELY CONFIGURED EQUIPMENT

IP.com Disclosure Number: IPCOM000008939D
Original Publication Date: 1999-Jan-01
Included in the Prior Art Database: 2002-Jul-25
Document File: 2 page(s) / 112K

Publishing Venue

Motorola

Related People

Egbert Lenger: AUTHOR [+3]

Abstract

Today more and more features are provided in Existing feature protection is based on a combi- software only and are controlled by a remote contig- nation of information stored in the user's system and urator. These features often run on generic hard- additional protection provided by the configurator. ware and have various prices. This raises the issue of protecting such functions from illegal use.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

@ MO-LA

Technical Developments

SOFTWARE FEATURE PROTECTION FOR REMOTELY CONFIGURED EQUIPMENT

by Egbert Lenger, Klauspeter Hauf and Wolfgang Schier

ABSTRACT INTRODUCTION

  Today more and more features are provided in Existing feature protection is based on a combi- software only and are controlled by a remote contig- nation of information stored in the user's system and urator. These features often run on generic hard- additional protection provided by the configurator. ware and have various prices. This raises the issue
of protecting such functions from illegal use.

Fk 'ntemnn& {-Tq

Fig. 1 System Configuration

  The new idea is to place the protection informa- tion in the user system. The user system may be for example, a 2.way radio. This makes interfacing between the configurator and the user system sim- pler, and the interconnection between the different components does not carry any sensitive or protect- ed information at all.

PROBLEM(S) TO BE SOLVED

  Existing feature protection has the disadvantage that sensitive information has to be transferred between the configurator and the user's system using the interconnection, opening the possibility of such data being spied upon and the protection being broken. This prior art arrangement also requires that the configurator and the user's system run on the same version of feature protection, i.e. a feature pro- tected in the configurator needs also to be known as a protected feature in the user's system as well. This becomes very complicated in configurations where several different software versions are avai- able on a common hardware (user system) and most of them deal with different feature sets.

  Another significant problem found with today's set-up is that, often, each function is protected sepa- rately. As an example, a simple user system sup- porting 10 different features, with each one protect- ed separately, could be configured into 1023 differ- ent versions. However, today's systems often sup- port several hundred independent features. This results in a huge number of different versions which cause trouble in the after-sales situation (e.g. main-

tenance, feature enhancements) where hundreds of different versions must be kept in stock to provide a sufficient service.

PROPOSED SOLUTION TO THE PROBLEM(S)

  With the new implementation all protection is now concentrated in the user's system only. This is the only place where knowledge of features enabled/disabled is kept. This information is dis- tributed to the other devices, i.e. to the contigurator.

  The protection itself is based on a hardware component containing a unique serial number which cannot be mod...