EP1456820A2 - Verfahren zur initialisierung einer applikation in terminals - Google Patents

Verfahren zur initialisierung einer applikation in terminals

Info

Publication number
EP1456820A2
EP1456820A2 EP02782612A EP02782612A EP1456820A2 EP 1456820 A2 EP1456820 A2 EP 1456820A2 EP 02782612 A EP02782612 A EP 02782612A EP 02782612 A EP02782612 A EP 02782612A EP 1456820 A2 EP1456820 A2 EP 1456820A2
Authority
EP
European Patent Office
Prior art keywords
application
terminals
imex
lex
terminal
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
EP02782612A
Other languages
English (en)
French (fr)
Inventor
Klaus U. Klosa
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.)
Legic Identsystems AG
Original Assignee
Legic Identsystems 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 Legic Identsystems AG filed Critical Legic Identsystems AG
Publication of EP1456820A2 publication Critical patent/EP1456820A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/22—Microcontrol or microprogram arrangements
    • G06F9/24—Loading of the microprogram
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect

Definitions

  • the invention relates to a method for initializing or expanding an application, i.e. for the transmission of the information assigned to an application to terminals or writing and reading stations of a system with mobile data carriers within the framework of a hierarchical authorization system according to the preamble of claim 1 and a mobile data carrier according to the preamble of claim 28.
  • systems with mobile data carriers e.g. contact-based and preferably Non-contact identification media, chip cards or prepaid cards etc.
  • Terminals that are connected to a central application computer e.g. are connected to a host, a new application or corresponding application programs and information can be provided from there.
  • this entails high costs for the provision and operation of the online connections to the terminals.
  • Decentralized terminals in the sense of stand alone, offline) cannot be reprogrammed or reprogrammed.
  • the terminals are individually reprogrammed by a service technician by exchanging the program memory or by loading a new application program using a service device that is connected via an interface. This requires high costs for this software changeover.
  • a new application app is loaded into a selected, authorized WRZ terminal of the system.
  • the data carriers IM are presented to the authorized terminal, checked by them and, if necessary, loaded with the new application information lex. If these loaded data carriers IMex are presented at other terminals WR of the system, the data carrier is checked again by the terminal and if the new application app is assigned to the terminal, the application app or the corresponding application information lex is loaded into the terminal and in the following also run through the terminal.
  • FIG. 2 schematically shows a sequence of the method according to the invention with status feedback
  • Fig. 3 shows an iterative sequence of the method according to the invention by converting a terminal WR into an authorized terminal WRZ
  • Fig. 4a, b to carry out the inventive method, the structure of an authorized terminal WRZ, a data carrier IMex and a terminal WR with the transmitted application information lex
  • Fig. 5a, b, c illustrate Distribution of application information to the terminals WR and the data medium IMex as well as the execution of applications
  • FIG. 6 schematically shows a system with several authorized terminals
  • FIG. 7 shows an example of a system according to FIG. 6 with initializations of several independent applications from independent ones
  • La, 1b, lc, 2 and 3 illustrate the inventive method for initializing or expanding an application app, ie for the transmission of the application information lex assigned to an application app on terminals or writing and reading stations WR of a system with mobile data carriers IM, terminals WR and a hierarchical authorization system A.
  • the application information lex is loaded onto a mobile data carrier IMex by a selected, authorized terminal WRZ and then loaded When presenting these data carriers IMex at further terminals WR, the application information lex is transferred to these further terminals WR assigned to the application, so that the application app can then be executed on these terminals WR for authorized data carriers IM and IMex.
  • a new or expanded application app is loaded into a selected, authorized terminal WRZ (step 10 in FIG. La), for example into a security module SM with a security level SL-WR.
  • Relatively central terminals which are frequented by many different data carriers IM and from which the data carriers transmit the application information lex to the desired other terminals WR of the system are preferably determined as authorized terminals WRZ.
  • the authorization of the IMex data carrier for this app application is checked by the authorized WRZ terminal (step 11) or vice versa. If there is authorization, the application or the application information lex is written into the memory of the data carrier IMex (12), as shown in FIG.
  • IMex Flag / Pointer F / P in the data carrier. If the data carrier is subsequently transferred (13) to other reading stations or terminals WR of the system and presented there, then a check takes place again between the terminal WR and the data carrier (14). The flag / pointer F / P of the IMex data carrier can also be checked (15). The data carrier or terminal WR checks whether the new application is intended for this terminal WR and to what extent certain security requirements are met, e.g. whether the security level SL-WR of the terminal WR of the new application or the Security level SL-IM of the data carrier corresponds. If this is the case, the application information lex is transmitted (15) to the terminal WR, for example to a security module SM (FIG. 1b). Subsequently, further data carriers IM1, IM2, IM3, etc. can be presented and checked at this terminal WR (17), whereupon this new application app can be authorized by the terminal
  • SM security module
  • Data carriers e.g. IM1, IM3 and possibly also on the transmitting data carrier IMex can be carried out (18), (Fig. Lc), while on an unauthorized data carrier, e.g. IM2, the application cannot be executed.
  • the IMex data carrier can also only serve as a mail carrier for the transfer of the application information lex, without it being intended for this application app itself (without being able to use this application itself).
  • the flag / pointer F / P can be used to determine or check whether application information lex is available on an IMex data carrier.
  • a flag / pointer IMex is primarily assigned to the data carrier IMex and is intended to enable the management of application information lex on the data carrier.
  • a flag / pointer F / P-IMex generally refers to application information Iex (app) or to an application app, which in turn contains application information Iex (app) and a flag / pointer F / P-app.
  • a flag / pointer F / P app of an application app on a data medium IMex A flag / pointer F / P app is primarily assigned to the application app (e.g. as part the application app) and should facilitate the management of application information lex of an application app.
  • step 15 transfer of the application information lex to the terminal WR
  • the terminal WR active
  • the terminal WR can request the data carrier as required as to whether there is any application information lex (for example by checking the flag / pointer F / P-IMex and evaluating it if necessary) ) or the data carrier IMex (active) can tell the terminal WR that application information lex is available (for example by sending the flag / pointer F / P-IMex to the terminal WR for any evaluation).
  • the terminal WR active
  • the data carrier IMex active
  • Appropriate authorization is required to transfer the application information lex to the IMex data carrier and to transfer from the IMex data carrier to the WR terminals. This means that the transfer may only take place on or through authorized data carriers IMex or terminals WR for which the application is intended and in such a way that the required security is guaranteed.
  • This authorization can be carried out in different ways and adapted or selected to the security requirements, depending on the type and importance of the application, for example with the authorization rules of system A corresponding security levels SL-IM, which the data carriers IMex, and security levels SL-WR, which are assigned to the terminals WR and which control the transmission of the new application information lex and their subsequent execution.
  • the properties of the security level SL can be used as part of the authorization system A based on or extending existing hierarchy levels, e.g. by organizational levels OL according to WO 97/34265, or by new levels (with new principles) that are independent of existing levels.
  • Additional security and control elements form identification data ID-IM and ID-WR or additional personal codes pers, as is further explained in FIG. 2. These can be linked to the SL security level.
  • cryp2 it is also possible to introduce a separate cryp2 encryption for the applications.
  • the application information is encrypted with cryp2 in the authorized WRZ terminal, transferred in encrypted form in the IMex data carrier and the transferred application information lex is only decrypted with cryp2 in the WR terminal (Fig. La, lb, 2).
  • the IMex disk itself should not have the cryp2 key.
  • This application information lex should only be able to be decrypted in terminals WR or by data medium IMex, to which a corresponding application is assigned.
  • This encryption cryp2 of the applications is independent of an encryption crypl of the contactless communication RF-K in contactless systems, as shown in the example of FIG. 4.
  • the new applications transmitted according to the invention or the corresponding application information lex are to be understood as application extensions Appu (update) of existing applications in the terminals WR or as new, not yet existing applications Appn.
  • FIG. 2 shows the sequence of the method according to the invention as described in FIG. 1 with actual status feedback.
  • a new application App (Appn or Appu) is loaded from a host (a center) H or a transmission authorization medium AM into an authorized terminal WRZ (step 10).
  • a presented data carrier IMex is checked (step 11) and, if it is authorized and intended for this purpose, application information lex is written into the data carrier (12), which is then transferred to other terminals WR of the system (13).
  • Data carrier IMex contain special identification data ID-IM.
  • the data carriers IMex can thus be determined by means of identification data ID-IM for the transmission of certain application information lex.
  • special identification data ID-WR of the terminal can be used, with which the terminals WR are determined for the reception of certain application information lex.
  • a personal identification of the owner of the data carrier or the terminal owner with a personal code can also be used as an additional security requirement Code.
  • a control mechanism e.g. be provided in time or by a version number. If an earlier application version Appla initialized by a data carrier IMex has been replaced by a later, new, modified version Applb, it must be prevented that this newly installed version can later be replaced by the old version Appla, e.g. if this old version is later presented at the WR terminal by another data medium IMex that still contains the old version. This can be achieved by a time control, e.g. by temporally dating the applications and the condition that a younger application Applb with time tb cannot be deleted or replaced by an older version Appla with time ta: condition tb> ta. Another possibility is to check using a version number vn and the condition that a younger application Applb with version vb cannot be deleted or replaced by an older application Applb with version va: condition vb> va.
  • step 20 also shows the feedback (step 20) of status information about events at the terminals WR regarding the transmission of the application information.
  • mations lex which can be reported back to the authorized WRZ terminals from a data carrier IMex (the one that transferred the application or another), eg which application was installed correctly in which terminal WR.
  • Status messages can also be reported back via the execution of the initialized applications at the WR terminals.
  • the feedback can be initialized at different times, preferably by the terminal WR, for example immediately after the transmission of the application information lex, at a specified later point in time or after the first execution of the application with a data carrier IM.
  • the status feedback can also be used to control the spread of the application information lex.
  • the complete transfer of the application information lex from the data medium IMex to the terminal WR can be made dependent on the fact that the terminal WR transfers status information actual to the data medium IMex. This can be done using a shadow memory, which is described, for example, in WO 97/34265.
  • FIG. 2 and 4 also show an application hardware / software app HW / SW assigned to a terminal WR for the physical execution of applications, or the physical configuration of a terminal (for example control of a door access).
  • This app HW / SW can contain functional devices (such as motors, relays), input devices, display devices, biometric sensors etc.
  • FIG. 2 also illustrates the execution of initialized applications on a terminal WR with the assigned functional device App HW / SW (step 18) for a data carrier IMex or also for further data carriers IM presented below.
  • a terminal can also perform functions for which the terminal was not originally designed, provided the necessary HW / SW app is available and it can be configured using application information lex in accordance with the requirements of the new application.
  • FIG. 3 shows an iterative sequence of the method according to the invention by converting terminals WR into authorized terminals WRZ, in the sense of a controlled spreading or deletion of new applications over several authorized terminals WRZ (virus principle).
  • the first authorized terminals WRZj are selected, generally within the authorization system A, at most by converting terminals WRi into authorized terminals WRZj (step 9).
  • Application information lex is then transferred to data carrier IMex via these first authorized terminals WRZj and to other terminals WR via data carrier IMex.
  • One or more of these WR terminals can be converted into further authorized WRZ terminals as a result of the transmission of application information lex.
  • the application information is then loaded from these further authorized terminal WRZ onto further data carriers IMex, through which the application information lex is in turn transferred to further normal terminals WR.
  • Terminals transferred from a terminal WRi to an authorized terminal WRZj can be returned to terminals WRi at any time (preferably after the application information has been transferred to all terminals WR of a system) (step 22).
  • 3 shows such a controlled, iterative spreading of the application information lex.
  • an authorized WRZ terminal This can be an authorized terminal WRZj, which has been selected as authorized within the system from the beginning. However, a terminal WRi can also be transferred to an authorized terminal WRZj (step 9).
  • the transfer into an authorized terminal WRZj can depend on an authorization by means of authorization information 1 a, which takes place via a host H or an authorization medium (a data carrier) AM. If the functionality as an authorized terminal WRZ is not to be released beforehand using release information If (as an additional, optional security measure), an authorized terminal WRZ is then lex for the recording of application information ready. In the latter case, the transmission of application information lex is considered an implicit release. In the former case, the release takes place by means of release information If, preferably again via a host H or an authorization medium AM.
  • the application information lex is then transferred via the data carriers IMlex, IM2ex to several terminals WRa, WRb, ..., WRd, on which the new application app can then be executed (step 18).
  • certain terminals for example WRd, are selected, which in turn are converted into the status of an authorized terminal WRZd (step 21).
  • the application information lex can also be transferred in a controlled manner via data carriers IMex4, IMex5 to further terminals WRf, ..., WRh via these new authorized terminals WRZd, if necessary after release by means of release information If.
  • the release information If is preferably transmitted by IMex.
  • An important aspect for the controlled propagation is the possibility of converting a terminal WRd, WRh into an authorized terminal WRZd, WRZh without the terminal being connected to a host H and without the application information lex using an additional, special transmission Authorization medium AM must be transferred to the terminal.
  • This leads to further cost reductions when introducing or initializing new ones Applications because the connection of the individual terminals WR to the host H or the transmission on site to each individual terminal WR by means of a transmission authorization medium AM can be dispensed with.
  • the users of a system ie the carriers of the identification media (data carriers) IMex, disseminate a new application in the system in the simplest way: by using the system.
  • a terminal WR can only be temporarily converted into an authorized terminal WRZ.
  • a converted authorized terminal WRZ e.g. WRZd
  • an authorized terminal e.g. WRZd
  • application information lex does not have to be transferred to all IMex, but only if it is intended for it.
  • a terminal WR is only converted into an authorized terminal WRZ for the transfer of status information.
  • FIG. 4a, 4b show a structure of the components WRZ, IM and WR as well as the communication and the flow of information in the method according to the invention.
  • This example shows a non-contact system RF with non-contact Communication RF-K between the elements RF-WRZ, RF-IMex, RF-WR.
  • non-contact systems offer further special advantages and expanded application options.
  • the contactless communication RF-K is encrypted, for example, with crypl encryption using a unit for the logical processing of information, for example a processor for the communication logic, both in the data carriers IM and in the terminals WR.
  • the authorized terminal Rf-WRZ contains a data memory MEM and a microprocessor uP-WR for storing or processing the application information lex as well as for communication and for other security and control functions.
  • the application information lex Idat, Ipar, Icod can contain: Idat application data, e.g. Identification numbers, keys, codes for encryption (cryp)
  • Ipar parameters e.g. adjustable parameters for configuration or choice of communication, type, performance, encryption of communication, communication protocols, interfaces to the HW / SW app, etc.
  • Icod program data or program code Icod program code.
  • Rf-IMex shows two types of possible data carriers Rf-IMex: a data carrier without application microprocessor uP-IM, with a memory
  • MEM for the application information lex and a data carrier which additionally has an application microprocessor uP-IM.
  • This enables the IMex data carrier to run an application or part of an application itself.
  • the corresponding program code Icod is not transferred to the terminal WR, but remains in the data carrier IMex and is executed or controlled by the application processor uP-IM of the data carrier, which thus extends the application processor UP-WR, possibly even the app HW / SW.
  • the rules of the authorization system A are also complied with by the Terminal WR, ie the application data Idat required for this (generally processed by the Icod application) must be made available to the Terminal WR by the IMex data carrier before an application is executed become.
  • FIG. 4b shows the transfer from the RF-IMex data carrier to the Rf-WR terminals.
  • the terminals WR can contain a logical communication and application interface LCAI (Logical Communication and Application Interface), via which application information lex can be loaded into the terminals and read out.
  • LCAI Logical Communication and Application Interface
  • the terminals WR in this example contain a logical communication and application interface LCAI, which ensures that the microprocessor of the terminal WR contains the application information lex, e.g. understands the language of the program code Icod and can process it in compliance with the rules of the authorization system A.
  • the logical communication and application interface LCAI essentially comprises three tasks:
  • Program data Icod and parameters Ipar in particular of data that are directly connected to the application or can only be understood by the application
  • the API is a software interface for standardized access to the functions of a program, so that the logical rules for executing the application are observed.
  • the application information lex must be written (12) into a data carrier IMex via the logical communication and application interface LCAI.
  • application information lex must also be transferred (15) from the data medium IMex to a terminal WR via the logical communication and application interface LCAI, where the security level SL can also be checked.
  • 4a further illustrates two possibilities for the first time to transmit the application information lex to an authorized terminal WRZ in a controlled, authorized manner while observing the rules of the authorization system A.
  • the transmission can be carried out by a transmission authorization means AM (which contains the application information lex and at the same time serves for authorization according to the authorization system A) or by a host H.
  • the rules of the authorization system A have to be observed in another way, e.g. in that the communication between host H and authorized terminal WRZ is explicitly released by an authorization medium AM2, preferably via contactless communication RF-K with the WRZ.
  • the transfer (10) of the application information lex into the authorized terminal WRZ can already take place via the logical communication and application interface LCAI of the terminal, as an additional security measure.
  • the logical communication and application interface LCAI is an important element for compliance with the rules of the authorization system A across all levels and for all terminals WR, WRZ and data carrier IM of the system.
  • Terminals can also be provided which do not yet contain an application, so-called generic terminals g-WR with an application microprocessor uP-WR, into which an application lex is temporarily loaded and also executed by means of a data carrier IMex. Afterwards this application information lex can be deleted again.
  • each IM data carrier can bring its own application, for example, for one-time access or to implement applications with individual application profiles ind.
  • g-WR terminals must have a relatively flexible uP-WR application processor. This can be made available to a data medium IM, IMex, which itself has no application processor uP-IM, i.e. the uP-WR can be used to simulate a non-existing uP-IM. This enables the simultaneous use of data carriers IM, IMex with and without application processor uP-IM in the same system.
  • 5a, b, c illustrate the distribution of application information lex, i.e. of application data Idat and program codes Icod on the terminals WR, WRZ and the data carriers IM, IMex as well as the execution (18) of applications app on the assigned functional devices app HW / SW in compliance with the rules of the authorization system A.
  • the application data Idat and the program codes Icod are processed in the WR terminals and compliance with the authorization rules A is checked by forming a function f (A, Icod, Idat). After this function has been checked (17), the app application is executed on the assigned functional device app HW / SW (18).
  • the authorization rules A are observed in the terminal WR by determining a function f (A, Icod, Idat) by the application processor uP-WR of the terminal.
  • the rules are observed in the WR terminal by determining a function f (A, Icodl, Icod2, Idat) with separate processing of Icodl, Icod2, or a function f (A, Icodl + Icod2, Idat) with combined processing of Icodl and Icod2 , by the application processor uP-WR of the terminal.
  • a function fl (Icod2, Idat) can be determined in the data medium IMex by the uP-IM, which function can be used to determine the function f2 in the terminal.
  • This function f2 can be: f2 (A, fl, Icodl, Icod2, Idat) or f2 (A, fl, Icodl) or in the simplest form f2 (A, fl).
  • the WR, WRZ terminal only complies with the rules of the authorization system A and no processing of Idat, Icodl and Icod2 takes place in the terminal, but only in the IMex data carrier.
  • 5b and 5c also illustrate the concept of the generic terminal g-WR, which is characterized in that there is no program code Icodl assigned to an application in the terminal WR, but only one program code Icod2 in the data carrier. 5b and 5c also illustrate the basis for the Realization of applications with individual application profiles by loading the program code Icod required for the individualization as well as the necessary application data Idat on the IMex data carrier at the authorized WRZ terminal.
  • FIG. 6 schematically shows a system according to the invention for initializing applications app by means of application information lex, which transports terminals WR assigned from authorized terminals WRZ via data medium IMex to the applications app, writes them into them and also executes them there.
  • application information lex which transports terminals WR assigned from authorized terminals WRZ via data medium IMex to the applications app, writes them into them and also executes them there.
  • the example shows several central hosts Hl, H2, several authorized ones
  • Terminals WRZ1, WRZ2, WRZ3 and several terminals WR4 - WR8 can be initialized in any combination via the authorized terminals WRZ and the data media IMex into the various assigned terminals WR, provided the available storage capacities are sufficient for this (FIG. 7).
  • FIG. 7 shows an exemplary embodiment of a system according to FIG. 6 with three different independent applications Appl, App2, App3 by independent users, which transmit from the authorized terminals WRZ1, WRZ2, WRZ3 to the mobile data carriers IMex and are assigned by them
  • Terminals WR4 - WR8 are transferred, e.g. from WRZ1 the application App2 to terminals WR4, 5, 7, from WRZ2 the application Appl to terminals WR4, 7, 8 and from WRZ3 the application App3 temporarily to terminal WR6 ( as g-WR).
  • the status messages are sent to the authorized ones via the IMex data medium Terminals WRZ and from these to the central host H, for example: the application Appl is installed in the terminal WR8, is reported back to WRZ3 and H.
  • the application information lex can only be temporarily available in the data carriers IMex, the terminals WR and / or the authorized terminals WRZ and then deleted again.
  • the application information lex can be temporarily available for a predefinable period of time or for a specific number or type of processes or until a specific condition is met.
  • Examples for the initialization of applications in terminals according to the invention can be new applications Appn or an update of existing applications which are replaced or supplemented by a modified, expanded application Appu.
  • An example of an Appu update application Access to a room is carried out by checking the reference number of a data carrier IM1 and by entering a PIN code from the owner of this data carrier IM1.
  • This existing application is to be expanded so that access is only possible if a second authorized data carrier IM2 is presented in a short time (eg 30 seconds) and the PIN code of this second person is entered at the terminal.
  • This extended Appu application is adapted so that the test process is run twice accordingly.
  • the functional equipment App HW / SW for the physical execution of this application must already be available at Terminal WR.
  • an existing 4-digit PIN code could be replaced with a 6-digit PIN code as an access condition with the Appu.
  • Example of a new Appn application Access was previously carried out by checking the reference number of a data carrier IM. In addition, the PIN code of the owner of the data carrier IM should also be entered and checked.
  • a new application Appn is installed in the terminal WR by means of a data medium IMex, whereby the necessary function device App HW / SW is already available at the terminal or can be simulated, e.g.
  • PSOC Program System on Chip
  • Equipment or functional facilities can be set up at the WR terminals.
  • the adaptation of a parameter of a functional device illustrates as an application example an update of an Appu application in combination with a reconfiguration of the HW / SW app.
  • the application consists in the automatic opening of a door, for example by releasing a contact, mechanically moving a locking pin and opening a door by a motor.
  • the WR terminal can be reconfigured using application information lex.
  • an update of the application parameters Ipar of the functional devices belonging to the HW / SW app (relay, motor) is transferred to the WR terminal, whereby the relay and the motor are operated with new reference values (e.g. with increased current) to prevent that when operating with the old reference values, the relay does not activate the safety pin or the door is stuck.
  • the data media IMex can also have application information lex with individual application profiles ind.
  • Temporary badge for selective access New badges are to be created for an access system to the production facilities of a subsidiary in country b, with which representatives from headquarters from country a to country b can carry out unannounced inspection visits. To do this, an authorized Terminal WRZ data carrier IMex with the corresponding application information lex can be loaded. In country b, the IMex data carriers are presented at the terminals there, the application is temporarily initialized and also executed, ie access is granted for the duration of the planned inspection visit.
  • An application consists of access authorization for an EDP center, whereby the cardholder's data carrier is checked.
  • This access authorization is now to be tightened by a new, expanded application app, with which the access check additionally requires a personal code pers (PIN code or biometric code) of the owner of the data carrier.
  • PIN code or biometric code personal code pers
  • certain data or information should also be output or displayed. If the terminal does not have a display, it is possible to install a display unit next to the terminal, which e.g. how the data carrier should communicate with the terminal without contact. This makes it possible to dispense with cabling the display unit (with the WR terminal or a host H). With such an expansion, the terminal must be able to address the display unit, i.e.
  • the terminal or its corresponding parameter Ipar must be reconfigured so that communication is possible both with an IMex data carrier and with the display unit.
  • the application information lex required for this is transferred to the terminal WR via a data carrier IMex.
  • IMex data carrier
  • a further increase in access security can be initialized, for example, with an additional tightening by another application App2, with which Access is only allowed for two, i.e. in the extended App2 application, the terminal checks the data carrier of a first person and their personal code and then the data carrier of a second person and their personal code, and only then does all data have access to the IT center is released.
  • H host central A authorization system
  • AM authorization means transmission authorization medium
  • ID-IM ID-WR ID of the IM or ID of the WR, WRZ

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Telephone Function (AREA)

Abstract

Das Verfahren zur Initialisierung oder Erweiterung einer Applikation App, d.h. zur Übertragung von den einer Applikation App zugeordneten Informationen Iex auf Terminals WR eines Systems mit mobilen Datenträgern IM, Terminals WR und mit einem hierarchischen Autorisierungssystem A verwendet Applikationsinformationen lex, die von einem ausgewählten, autorisierten Terminal WRZ auf mobile Datenträger IMex geladen werden. Anschliessend werden beim Präsentieren dieser Datenträgern IMex an weiteren Terminals WR die Applikationsinformationen Iex auf die der Applikation zugeordneten Terminals WR übertragen, so dass anschliessend die Applikation App an diesen Terminals WR für berechtigte Datenträger IM ausführbar ist. Diese Terminals WR können auch in weitere autorisierte Terminals WRZ für die weitere kontrollierte Ausbreitung oder Löschung der Applikations-informationen Iex übergeführt werden ('Virus'-Prinzip).

Description

VERFAHREN ZUR INITIALISIERUNG EINER APPLIKATION IN TERMINALS
Die Erfindung betrifft ein Verfahren zur Initialisierung oder Erweiterung einer Applikation, d.h. zur Übertragung von den einer Applikation zugeordneten Informationen auf Terminals bzw. Schreib- und Lesestationen eines Systems mit mobilen Datenträgern im Rahmen eines hierarchischen Autorisierungssystems gemäss Oberbegriff von Patentanspruch 1 sowie einen mobilen Datenträger nach Oberbegriff von Anspruch 28. Systeme mit mobilen Datenträgern (z.B. kontaktbehaftete und vorzugsweise berührungslose Identifikationsmedien, Chipkarten oder Wertkarten usw.) ermöglichen dem Benutzer an zugeordneten Schreib- und Lesestationen die Ausübung von entsprechenden Applikationen wie den Zugriff auf Dienstleistungen (PC-Zugang und Waren) bzw. den Zugang zu geschützten Bereichen, Gebäuden, Veranstaltungen usw.
Ein Beispiel für ein solches System mit berührungslosen Identifikationsmedien bzw. mobilen Datenträgern und einem hierarchischen Autorisierungssystem ist beschrieben in der WO 97/34265.
Vor allem in grösseren Systemen müssen diese Applikationen an den verschiedenen Terminals immer wieder erweitert, ergänzt und geändert werden, d.h. es müssen neue oder erweiterte Applikationen App an bestimmten Terminals eingerichtet werden. Diese Erneuerung und Anpassung von Applikationsprogrammen in den Terminals kann bisher nur auf zwei Arten erfolgen:
1. Terminals, welche über eine Datenleitung mit einem zentralen Applikationsrechner, z.B. einem Host verbunden sind, können von dort aus mit einer neuen Applikation bzw. entsprechenden Applikationsprogrammen und Informationen versehen werden. Dies bedingt jedoch hohe Kosten für die Bereitstellung und den Betrieb der Online- Verbindungen zu den Terminals. Dezentrale Terminals (im Sinne von Stand alone, offline) können so nicht neu oder umprogrammiert werden. 2. Die Terminals werden von einem Servicetechniker einzeln umprogrammiert durch Austausch des Programmspeichers oder durch Laden eines neuen Applikationsprogramms mittels eines Servicegeräts, das über eine Schnittstelle angeschlossen wird. Dies erfordert hohe Kosten für diese Software-Umstellung.
Es ist nun Aufgabe der Erfindung, eine neue einfache Methode zu finden, um
Applikationen in Terminals und vor allem auch in dezentralen Terminals zu ändern und einzurichten. Diese Aufgabe wird erf indungsgemäss gelöst durch ein Verfahren nach Anspruch 1 und einen mobilen Datenträger nach Anspruch 28.
Dabei wird eine neue Applikation App in ein ausgewähltes, autorisiertes Terminal WRZ des Systems geladen. Die Datenträger IM werden dem autorisierten Terminal präsentiert, von diesem geprüft und gegebenenfalls mit den neuen Applikationsinformationen lex geladen. Wenn diese geladenen Datenträger IMex an weiteren Terminals WR des System präsentiert werden, so wird wiederum der Datenträger vom Terminal geprüft und falls die neue Applikation App dem Terminal zugeordnet ist, wird die Applikation App bzw. die entsprechenden Applikationsinformationen lex in das Terminal geladen und im folgenden auch durch das Terminal ausgeführt. Die abhängigen Ansprüche betreffen vorteilhafte Weiterbildungen der Erfindung mit besonderen Vorteilen bezüglich Anwendungen, Sicherheit und Anpassung an weitere Bedingungen. Im folgenden wird die Erfindung anhand von Figuren und Beispielen weiter erläutert. Es zeigen: Fig. la, b, c das erfindungsgemässe Verfahren mit Übertragung einer neuen
Applikation von einem autorisierten Terminal WRZ auf einen Datenträger IMex, vom Datenträger auf ein anderes Terminal WR und die Ausführung der Applikation mit weiteren Datenträgern IM, Fig. 2 schematisch einen Ablauf des erf indungsgemässen Verfahrens mit Statusrückmeldungen, Fig. 3 einen iterativen Ablauf des erfindungsgemässen Verfahrens durch Umwandlung eines Terminals WR in ein autorisiertes Terminal WRZ, Fig. 4a, b zur Ausführung des erfindungsgemässen Verfahrens den Aufbau eines autorisierten Terminals WRZ, eines Datenträgers IMex und eines Terminals WR mit den übertragenen Applikationsinformationen lex, Fig. 5a, b, c illustrieren die Verteilung von Applikationsinformationen auf die Terminals WR und die Datenträger IMex sowie die Ausführung von Applikationen, Fig. 6 schematisch ein System mit mehreren autorisierten Terminals
WRZ, Datenträgern IMex und Terminals WR, Fig. 7 ein Beispiel eines Systems nach Fig. 6 mit Initialisierungen mehrerer unabhängiger Applikationen von unabhängigen
Anwendern, mit Informationsfluss lex und Statusrückmeldungen.
Die Fig. la, 1b, lc, 2 und 3 illustrieren das erfindungsgemässe Verfahren zur Initialisierung oder Erweiterung einer Applikation App, d.h. zur Übertragung von den einer Applikation App zugeordneten Applikationsinformationen lex auf Terminals bzw. Schreib- und Lesestationen WR eines Systems mit mobilen Datenträgern IM, Terminals WR und einem hierarchischen Autorisierungssystem A. Die Applikationsinformationen lex werden von einem ausgewählten, autorisierten Terminal WRZ auf mobile Datenträger IMex geladen und anschliessend werden beim Präsentieren von diesen Datenträgern IMex an weiteren Terminals WR die Applikationsinformationen lex auf diese weiteren, der Applikation zugeordneten Terminals WR übertragen, so dass anschliessend die Applikation App an diesen Terminals WR für berechtigte Datenträger IM und IMex ausführbar ist.
Eine neue oder erweiterte Applikation App wird in ein ausgewähltes, autorisiertes Terminal WRZ geladen (Schritt 10 in Fig. la), z.B. in ein Sicherheitsmodul SM mit einem Sicherheitslevel SL-WR. Als autorisierte Terminals WRZ werden vorzugsweise relativ zentrale Terminals bestimmt, die von vielen verschiedenen Datenträ- gern IM frequentiert werden, und von welchen aus die Datenträger die Applikationsinformationen lex an die gewünschten anderen Terminals WR des Systems weitertragen. Beim Präsentieren des Datenträgers IMex wird vom autorisierten Terminal WRZ die Berechtigung des Datenträgers IMex für diese Applikation App geprüft (Schritt 11) oder umgekehrt. Bei vorhandener Berechtigung wird die Applikation bzw. die Applikationsinformationen lex in den Speicher des Datenträgers IMex eingeschrieben (12) wie Fig. la zeigt. Hier können im Datenträger IMex Flag/Pointer F/P gesetzt werden. Wenn der Datenträger anschliessend zu weiteren Lesestationen bzw. Terminals WR des Systems transferiert (13) und dort präsentiert wird, so findet zwischen dem Terminal WR und dem Datenträger wiederum eine Prüfung statt (14). Dabei können auch Flag/Pointer F/P des Datenträgers IMex geprüft werden (15). Vom Datenträger oder vom Terminal WR wird geprüft, ob die neue Applikation für dieses Terminal WR bestimmt ist und inwieweit bestimmte Sicherheitsanforderungen erfüllt sind, z.B. ob der Sicherheitslevel SL-WR des Terminals WR der neuen Applikation bzw. dem Sicherheitslevel SL-IM des Datenträgers entspricht. Falls dies zutrifft, werden die Applikationsinformationen lex in das Terminal WR übertragen (15), z.B. in ein Sicherheitsmodul SM (Fig. lb). Anschliessend können weitere Datenträger IM1, IM2, IM3 usw. an diesem Terminal WR präsentiert und geprüft werden (17), worauf diese neue Applikation App durch das Terminal an den weiteren, berechtigten
Datenträgern z.B. IM1, IM3 und allenfalls auch am übertragenden Datenträger IMex ausgeführt werden kann (18), (Fig. lc), während an einen nicht berechtigten Datenträger, z.B. IM2, die Applikation nicht ausgeführt werden kann.
Die Ausführung einer Applikation durch ein Terminal WR unmittelbar nach der Übertragung dieser Applikation vom Datenträger IMex auf das Terminal WR ermöglicht die Realisierung von Applikationen mit individuellen Applikations- profilen ind.
Der Datenträger IMex kann aber auch nur als Briefträger für die Übertragung der Applikationsinformation lex dienen, ohne dass er selber für diese Applikation App bestimmt ist (ohne diese Applikation selber ausüben zu können).
Mittels Flag/Pointer F/P kann festgelegt oder geprüft werden, ob auf einem Daten- träger IMex Applikationsinformationen lex vorhanden sind.
Es muss insbesondere zwischen folgenden Flag/Pointer F/P unterschieden werden:
- Flag/Pointer F P-IMex des Datenträgers IMex: Ein Flag/Pointer IMex ist primär dem Datenträger IMex zugeordnet und soll das Management von Applikationsinformationen lex auf dem Datenträger ermöglichen. Ein Flag/Pointer F/P-IMex verweist im Allgemeinen auf eine Applikationsinformation Iex(App) oder auf eine Applikation App, welche ihrerseits eine Applikationsinformation Iex(App) und einen Flag/Pointer F/P-App enthält.
- Flag/Pointer F/P-App einer Applikation App auf einem Datenträger IMex: Ein Flag/Pointer F/P-App ist primär der Applikation App zugeordnet (z.B. als Teil der Applikation App) und soll das Management von Applikationsinformationen lex einer Applikation App erleichtern.
Im Rahmen der Übertragung von Applikationsinformationen lex zwischen den Elementen WR, WRZ und IMex kann unterschieden werden, ob diese aktiv (d.h. als Sender die Applikationsinformationen lex von sich aus zur Verfügung stellend) oder passiv (d.h. als Empfänger die Applikationsinformationen lex empfangend) auftreten. Die Verwendung, d.h. das Setzen von Flag/Pointer F/P ist eine Möglichkeit zur Realisierung aktiver Elemente WR, WRZ, IMex. So kann beim Schritt 15 (Übertragung der Applikationsinformationen lex auf das Terminal WR) je nach Bedarf das Terminal WR (aktiv) den Datenträger anfragen, ob eine Applikationsinformation lex vorhanden sei (indem z.B. der Flag/Pointer F/P-IMex überprüft und gegebenenfalls ausgewertet wird) oder es kann der Datenträger IMex (aktiv) an das Terminal WR mitteilen, dass eine Applikationsinformation lex vorhanden sei (indem z.B. der Flag/Pointer F/P-IMex an das Terminal WR zur allfälligen Auswertung gesendet wird). Analoges gilt auch für die Rückmeldung von Statusinformationen Ist.
Zur Übertragung der Applikationsinformationen lex auf die Datenträger IMex und zur Übertragung von den Datenträgern IMex auf die Terminals WR wird eine ange- messene Autorisierung benötigt. D.h. die Übertragung darf nur auf bzw. durch berechtigte Datenträger IMex bzw. Terminals WR erfolgen, für die die Applikation bestimmt ist und so, dass die erforderliche Sicherheit gewährleistet ist. Diese Berechtigung kann auf verschiedene Arten ausgeführt und den Sicherheitsanforderungen, entsprechend der Art und Wichtigkeit der Applikation, angepasst bzw. gewählt werden, beispielsweise mit den Autorisierungsregeln des Systems A entsprechenden Sicherheitslevels SL-IM, welche den Datenträgern IMex, und Sicherheitslevels SL-WR, welche den Terminals WR zugeordnet werden und welche die Übertragung der neuen Applikationsinformationen lex und deren anschliessende Ausführung kontrollieren. Dabei ist es wichtig, dass die Regeln des Autorisierungs- systems A verhindern, dass ein Sicherheitslevel SL-IM oder SL-WR in einem Datenträger oder in einem Terminal erhöht oder geändert werden kann. Damit wird die Verbreitung der Applikationen App auf die Terminals WR und deren Anwendung mittels der Datenträger IM kontrolliert und beschränkt.
Die Eigenschaften des Sicherheitslevels SL können hierbei im Rahmen des Autori- sierungssystems A in Anlehnung oder Erweiterung bereits vorhandener Hierarchieebenen, z.B. von Organisationslevels OL nach WO 97/34265, oder durch neue, von bestehenden Ebenen unabhängige Levels (mit neuen Prinzipien) festgelegt werden.
Es besteht aber auch die Möglichkeit, dass die Sicherheitslevels SL nicht im Rahmen des Autorisierungssystems A, sondern im Rahmen eines zusätzlichen unabhängigen Sicherheits-Autorisierungssystems SA festgelegt werden.
Weitere Sicherheits- und Kontrollelemente bilden Identifikationsdaten ID-IM und ID-WR oder zusätzliche persönliche Codes pers, wie in Fig. 2 weiter erläutert wird. Diese können mit den Sicherheitslevels SL verknüpft sein.
Es ist auch möglich, für die Applikationen eine separate Verschlüsselung cryp2 einzuführen. Dabei werden die Applikationsinformationen mit cryp2 im autorisierten Terminal WRZ verschlüsselt, im Datenträger IMex in verschlüsselter Form transferiert und die transferierten Applikationsinformationen lex erst im Terminal WR mit cryp2 wieder entschlüsselt (Fig. la, lb, 2). Dabei soll der Datenträger IMex selber meist nicht über den Schlüssel cryp2 verfügen. Diese Applikationsinfor- mationen lex sollen nur in Terminals WR oder durch Datenträger IMex entschlüsselt werden können, welchen eine entsprechende Applikation zugeordnet ist.
Es können für verschiedene unabhängige Applikationen Appl, App2 von unabhängigen Anwendern und die zugeordneten Terminals WR auch verschiedene voneinan- der unabhängige Verschlüsselungen cryp2 gewählt werden. Diese Verschlüsselung cryp2 der Applikationen ist unabhängig von einer Verschlüsselung crypl der berührungslosen Kommunikation Rf-K in berührungslosen Systemen wie am Beispiel von Fig. 4 gezeigt ist.
Die erfindungsgemäss übertragenen neuen Applikationen bzw. die entsprechenden Applikationsinformationen lex sind zu verstehen als Applikationserweiterungen Appu (Update) bestehender Applikationen in den Terminals WR oder als neue, noch nicht vorhandene Applikationen Appn.
Fig. 2 zeigt den Ablauf des erfindungsgemässen Verfahrens wie in Fig. 1 beschrieben mit Statusrückmeldungen Ist. Eine neuen Applikation App (Appn oder Appu) wird von einem Host (eine Zentrale) H oder einem Übertragungs-Autorisierungsmedium AM in ein autorisiertes Terminal WRZ geladen (Schritt 10). Dort wird ein präsentier- ter Datenträger IMex geprüft (Schritt 11) und, falls er dafür berechtigt und bestimmt ist, werden Applikationsinformationen lex in den Datenträger eingeschrieben (12), welcher anschliessend zu weiteren Terminals WR des Systems transferiert wird (13). Hier wird geprüft, ob das Terminal WR der neuen Applikation (bzw. ob der Datenträger IMex dem Terminal WR) zugeordnet ist und ob alle Berechtigungen vorhan- den sind, z.B. mittels Überprüfung der gegenseitigen Zuordnung der Sicherheitslevel SL und von Referenz-/Seriennummern (Schritt 14), worauf die Informationen lex in das Terminal WR eingeschrieben bzw. übertragen werden (15).
Zur Prüfung der Autorisierung und Berechtigung an den autorisierten Terminals WRZ oder an den einer Applikation zugeordneten Terminals WR kann der
Datenträger IMex spezielle Identifikationsdaten ID-IM enthalten. So können die Datenträger IMex durch Identifikationsdaten ID-IM für die Übertragung von bestimmten Applikationsinformationen lex bestimmt werden. Und zur Prüfung der Autorisierung und Berechtigung am Terminal WR können spezielle Identifikationsdaten ID-WR des Terminals dienen, mit welchen die Terminals WR für die Aufnahme von bestimmten Applikations Informationen lex bestimmt werden.
Bei der Übertragung der neuen Applikationsinformationen lex auf die Datenträger IMex und von den Datenträgern auf die Terminals WR kann als zusätzliche Sicherheitsanforderung auch eine persönliche Identifikation des Inhabers des Datenträgers oder des Inhabers des Terminals mit einem persönlichen Code pers (z.B. ein PIN- Code oder ein biometrischer Code) vorgeschrieben sein.
Um zu verhindern, dass versehentlich eine neuere Applikation durch eine ältere Applikation überschrieben wird, kann ein Kontrollmechanismus, z.B. zeitlich oder durch eine Versionennummer, vorgesehen sein. Wenn eine frühere von einem Daten- träger IMex initialisierte Applikationsversion Appla durch eine spätere, neue, geänderte Version Applb ersetzt wurde, so muss verhindert werden, dass diese neu installierte Version später wieder durch die alte Version Appla ersetzt werden kann, z.B. wenn diese alte Version am Terminal WR später durch einen anderen Datenträger IMex, welcher noch die alte Version enthält, präsentiert wird. Dies kann durch eine Zeitkontrolle erreicht werden, z.B. durch zeitliches Datieren der Applikationen und die Bedingung, dass eine jüngere Applikation Applb mit Zeitpunkt tb nicht durch eine ältere Version Appla mit Zeitpunkt ta gelöscht bzw. ersetzt werden kann: Bedingung tb > ta. Eine andere Möglichkeit besteht in einer Kontrolle mittels einer Versionennummer vn und der Bedingung, dass eine jüngere Applikation Applb mit Version vb nicht durch eine ältere Applikation Appl mit Version va gelöscht bzw. ersetzt werden kann: Bedingung vb > va.
Fig. 2 zeigt auch die Rückmeldung (Schritt 20) von Statusinformationen Ist über Ereignisse an den Terminals WR bezüglich Übertragung der Applikationsinfor- mationen lex, welche von einem Datenträger IMex (demjenigen, welcher die Applikation übertragen hat oder von einem anderen) an die autorisierten Terminals WRZ zurück gemeldet werden können, z.B. welche Applikation wann in welchem Terminal WR korrekt installiert wurde. Auch Statusmeldungen Ist über die Aus- führung der initialisierten Applikationen an den Terminals WR können so zurückgemeldet werden. Die Rückmeldung kann hierbei zu verschiedenen Zeiten, vorzugsweise durch das Terminal WR, initialisiert werden, z.B. unmittelbar im Anschluss an die Übertragung der Applikationsinformationen lex, zu einem festgelegten späteren Zeitpunkt oder im Anschluss an eine erstmalige Ausführung der Applikation mit einem Datenträger IM. Die Statusrückmeldung kann auch zur Kontrolle der Ausbreitung der Applikationsinformationen lex eingesetzt werden. So kann die vollständige Übertragung der Applikationsinformationen lex vom Datenträger IMex auf das Terminal WR davon abhängig gemacht werden, dass das Terminal WR Statusinformationen Ist auf den Datenträger IMex überträgt. Dies kann mittels eines Schattenspeichers geschehen, welcher z.B. in WO 97/34265 beschrieben ist.
Die Fig. 2 und 4 zeigen zudem eine einem Terminal WR zugeordnete Applikations- Hardware/Software App HW/SW zur physikalischen Ausführung von Applikationen, bzw. die physikalische Konfiguration eines Terminals (z.B. Steuerung eines Türzu- gangs). Diese App HW/SW kann Funktionsgeräte (wie Motoren, Relais), Eingabegeräte, Anzeigegeräte, biometrische Sensoren etc. enthalten. Fig. 2 illustriert auch die Ausführung von initialisierten Applikationen an einem Terminal WR mit der zugeordneten Funktionseinrichtung App HW/SW (Schritt 18) für einen Datenträger IMex oder auch für weitere im folgenden präsentierte Datenträger IM. Mit einer neu initialisierten Applikation kann ein Terminal auch Funktionen ausführen, für welche das Terminal ursprünglich nicht konzipiert war, soweit die dazu notwendige App HW/SW vorhanden ist und diese durch Applikationsinformationen lex gemäss den Anforderungen der neuen Applikation konfiguriert werden kann. Fig. 3 zeigt einen iterativen Ablauf des erfindungsgemässen Verfahrens durch Umwandlung von Terminals WR in autorisierte Terminals WRZ, dies im Sinne einer kontrollierten Ausbreitung bzw. Löschung von neuen Applikationen über mehrere autorisierte Terminals WRZ (Virusprinzip). Dabei werden erste autorisierte Terminals WRZj ausgewählt, im Allgemeinen im Rahmen des Autorisierungs- systems A, allenfalls durch die Überführung von Terminals WRi in autorisierte Terminals WRZj (Schritt 9). Über diese ersten autorisierten Terminals WRZj erfolgt anschliessend die Übertragung von Applikationsinformationen lex auf Datenträger IMex und über die Datenträger IMex auf weitere Terminals WR. Ein oder mehrere dieser Terminals WR können als Ergebnis der Übertragung von Applikationsinformationen lex in weitere autorisierte Terminals WRZ umgewandelt werden. Anschliessend werden die Applikationsinformationen von diesen weiteren autorisierten Terminal WRZ auf weitere Datenträger IMex geladen, durch welche die Applikations Informationen lex wiederum auf weitere normale Terminals WR übertragen werden. Aus einem Terminal WRi in ein autorisiertes Terminal WRZj übergeführte Terminals können jederzeit (vorzugsweise nachdem die Applikationsinformation auf alle Terminals WR eines Systems übertragen wurden) wieder in Terminals WRi zurückgeführt werden (Schritt 22). Fig. 3 zeigt eine solche kontrollierte, iterative Ausbreitung der Applikationsinformationen lex. Am Anfang des Verfahrens steht die Wahl eines autorisierten Terminals WRZ. Dies kann ein autorisiertes Terminal WRZj sein, welches im Rahmen des Systems von Anfang an als autorisiert ausgewählt wurde. Es kann aber auch ein Terminal WRi in ein autorisiertes Terminal WRZj übergeführt werden (Schritt 9). Die Überführung in ein autorisiertes Terminal WRZj kann von einer Autorisierung mittels Autorisierungs- Informationen la abhängig sein, welche über einen Host H oder ein Autorisierungs- medium (ein Datenträger) AM erfolgt. Falls nicht vorangehend eine Freigabe der Funktionalität als autorisiertes Terminal WRZ mittels Freigabeinformationen If erfolgen soll (als zusätzliche, optionale Sicherheitsmassnahme), ist ein autorisiertes Terminal WRZ anschliessend für die Aufnahme von Applikationsinformationen lex bereit. Im letzteren Fall gilt die Übertragung von Applikationsinformationen lex als implizite Freigabe. Im ersteren Fall erfolgt die Freigabe mittels Freigabeinformationen If, vorzugsweise wieder über einen Host H oder ein Autorisierungsmedium AM. Ausgehend von einem oder mehreren zentralen Terminals WRZ1, WRZ2 werden dann die Applikationsinformationen lex über die Datenträger IMlex, IM2ex auf mehrere Terminals WRa, WRb, ..., WRd übertragen, an welchen anschliessend die neue Applikation App ausgeführt werden kann (Schritt 18). Davon werden gewisse Terminals, z.B. WRd, ausgewählt, welche ihrerseits in den Status eines autorisierten Terminals WRZd umgewandelt werden (Schritt 21). Auch über diese neuen autorisierten Terminals WRZd kann die Applikationsinformation lex mittels Datenträger IMex4, IMex5 auf weitere Terminals WRf, ..., WRh kontrolliert übertragen werden, allenfalls nach der Freigabe mittels Freigabeinformationen If . Für dieses neue autorisierte Terminal WRZd erfolgt die Übertragung der Freigabeinformationen If vorzugsweise durch IMex. Wie ersichtlich, ist zur Übertragung von Applikationsinformationen lex auf die Datenträger IMex4 und IMex5 kein direkter Kontakt mit einem an einen Host H angebundenen autorisierten Terminal, z.B. WRZ1, erforderlich. Dieses iterative Prinzip kann beliebig oft wiederholt werden, z.B. kann das Terminal WRh umgewandelt werden in das autorisierte Terminal WRZh. Dies ermöglicht die kontrollierte Übertragung der Applikationsinformationen lex innerhalb eines Systems mit verschiedenen autorisierten Terminals WRZ, verschiedenen Terminals WR und Datenträgern IM bzw. IMex und damit eine schnellere und gezieltere Ausbreitung einer neuen Applikation in einem System.
Ein wichtiger Aspekt für die kontrollierte Ausbreitung ist die Möglichkeit, ein Terminal WRd, WRh in ein autorisiertes Terminal WRZd, WRZh umzuwandeln, ohne dass das Terminal mit einem Host H verbunden ist und ohne dass die Applikations Informationen lex mittels eines zusätzlichen, speziellen-Übertragungs- Autorisierungsmediums AM in das Terminal übertragen werden müssen. Dies führt zu weiteren Kostenreduktionen bei der Einführung bzw. Initialisierung neuer Applikationen, weil auf die Anbindung der einzelnen Terminals WR an den Host H oder auf die Übertragung vor Ort in jedes einzelne Terminal WR mittels eines Übertragungs-Autorisierungsmediums AM verzichtet werden kann. Die Benutzer eines Systems, d.h. die Träger der Identifikationsmedien (Datenträger) IMex, verbreiten eine neue Applikation im System auf einfachste Art: durch die Benutzung des Systems.
Analog zu dieser kontrollierten Ausbreitung nach dem Virus-Prinzip kann auch eine kontrollierte Löschung einer Applikation App durchgeführt werden, unabhängig davon, wie und woher diese Applikation in ein Terminal WR geladen bzw. übertragen wurde.
Dabei kann ein Terminal WR auch nur temporär in ein autorisiertes Terminal WRZ umgewandelt werden. So kann ein umgewandeltes autorisiertes Terminal WRZ (z.B. WRZd) nach einer bestimmten Zeit oder aufgrund bestimmter Kriterien wieder in ein normales Terminal WRd zurückgeführt werden, z.B. nachdem die Applikationsinformation lex auf eine vorgegebene Anzahl von Datenträgern IMex übertragen wurde oder in Abhängigkeit von bestimmten Statusinformationen Ist.
Auch hier gilt, dass ein autorisiertes Terminal, z.B. WRZd, eine Applikationsinformation lex nicht auf alle IMex übertragen muss, sondern nur wenn sie dafür bestimmt ist.
Es ist auch möglich, dass ein Terminal WR nur für die Übertragung von Statusinfor- mationen in ein autorisiertes Terminal WRZ umgewandelt wird.
Die Fig. 4a, 4b zeigen einen Aufbau der Komponenten WRZ, IM und WR sowie die Kommunikation und den Informationsfluss im erfindungsgemässen Verfahren. Dieses Beispiel zeigt ein berührungsloses System Rf mit berührungsloser Kommunikation Rf-K zwischen den Elementen Rf-WRZ, Rf-IMex, Rf-WR. Im Vergleich zu Kontaktsystemen bieten berührungslose Systeme weitere besondere Vorteile und erweiterte Anwendungsmöglichkeiten. Dabei wird die berührungslose Kommunikation Rf -K verschlüsselt z.B mit einer Verschlüsselung crypl mittels einer Einheit zur logischen Verarbeitung von Informationen, z.B. eines Prozessors für die Kommunikationslogik sowohl in den Datenträgern IM wie in den Terminals WR.
Das autorisierte Terminal Rf-WRZ enthält einen Datenspeicher MEM sowie einen Microprozessor uP-WR zur Speicherung bzw. Verarbeitung der Applikationsinformationen lex sowie für die Kommunikation und für weitere Sicherheits- und Kontrollfunktionen. Die Applikationsinformationen lex = Idat, Ipar, Icod können dabei enthalten: Idat Applikationsdaten, z.B. Identifikationsnummern, Schlüssel, Codes für Verschlüsselungen (cryp)
Ipar Parameter, z.B. einstellbare Parameter zur Konfiguration bzw. Wahl der Kommunikation, Art, Leistung, Verschlüsselung der Kommunikation, Kommunikationsprotokolle, Schnittstellen zur App HW/SW, etc. Icod Programmdaten bzw. Programmcode.
Diese Fig. 4 zeigt zwei Arten von möglichen Datenträgern Rf-IMex: einen Datenträger ohne Applikations-Microprozessor uP-IM, mit einem Speicher
MEM für die Applikationsinformationen lex und einen Datenträger, der zusätzlich einen Applikations-Microprozessor uP-IM aufweist. Dies ermöglicht es, dass der Datenträger IMex selber eine Applikation oder einen Teil einer Applikation ausführen kann. Dabei wird der entsprechende Programmcode Icod nicht in das Terminal WR übertragen, sondern verbleibt im Datenträger IMex und wird durch den Applikationsprozessors uP-IM des Datenträgers ausgeführt bzw. gesteuert, welcher damit eine Erweiterung des Applikations- prozessors uP-WR, allenfalls sogar der App HW/SW bildet. Die Einhaltung der Regeln des Autorisierungssystems A erfolgt jedoch auch im Falle einer solchen Erweiterung durch das Terminal WR, d.h. die dafür notwendigen (im Allgemeinen durch die Applikation Icod verarbeiteten) Applikationsdaten Idat müssen dem Terminal WR vom Datenträger IMex vor der Ausführung einer Applikation zur Verfügung gestellt werden.
Fig. 4a zeigt die Übertragung der Applikationsinformationen lex = Idat, Ipar, Icod vom autorisierten Terminal Rf-WRZ auf den Datenträger Rf-IMex und Fig. 4b zeigt die Übertragung vom Datenträger RF-IMex auf die Terminals Rf-WR.
Die Terminals WR können eine logische Kommunikations- und Applikationsschnittstelle LCAI (Logical Communication and Application Interface) enthalten, über welche Applikationsinformationen lex in die Terminals geladen und ausgelesen werden können.
Die Terminals WR in diesem Beispiel enthalten eine logische Kommunikations- und Applikationsschnittstelle LCAI, welche sicherstellt, dass der Microprozessor des Terminals WR die Applikationsinformation lex, z.B. die Sprache des Programmcodes Icod versteht und unter Einhaltung der Regeln des Autorisierungssystems A verarbeiten kann. Die logische Kommunikations- und Applikationsschnittstelle LCAI umfasst im wesentlichen drei Aufgaben:
- Sie wirkt erstens als Interpreter oder Virtual Machine, insbesondere für die Verarbeitung von Programmdaten Icod und Parametern Ipar,
- zweitens als ein Application Programming Interface API, insbesondere für die Verarbeitung von Applikationsdaten Idat und auch für die Verarbeitung von
Programmdaten Icod und Parametern Ipar, insbesondere von Daten, die direkt mit der Applikation verbunden sind bzw. nur von der Applikation verstanden werden
- und drittens sichert sie die Einhaltung der Regeln des Autorisierungssystems A. Das API stellt eine Software-Schnittstelle für den standardisierten Zugriff auf Funktionen eines Programms dar, so dass die logischen Regeln für die Ausführung der Applikation eingehalten werden.
Entsprechend muss das Einschreiben (12) von Applikationsinformationen lex in einen Datenträger IMex über die logische Kommunikations- und Applikationsschnittstelle LCAI erfolgen. Analog muss auch die Übertragung (15) von Applikationsinformationen lex vom Datenträger IMex an ein Terminal WR über die logische Kommunikations- und Applikationsschnittstelle LCAI erfolgen, wo zudem auch die Überprüfung der Sicherheitslevel SL stattfinden kann.
Fig. 4a illustriert weiter zwei Möglichkeiten, die Applikationsinformationen lex auf kontrollierte, autorisierte Art und Weise unter Einhaltung der Regeln des Autorisierungssystems A erstmalig in ein autorisiertes Terminal WRZ zu übertragen. Die Übertragung kann durch ein Übertragungs-Autorisierungsmittel AM (welches die Applikationsinformationen lex enthält und gleichzeitig zur Autorisierung gemäss dem Autorisierungssystem A dient) oder durch einen Host H erfolgen. Bei Übertragung über den Host H müssen die Regeln des Autorisierungssystems A auf andere Art und Weise eingehalten werden, z.B. indem die Kommunikation zwischen Host H und autorisiertem Terminal WRZ durch ein Autorisierungsmedium AM2, vorzugsweise über eine berührungslose Kommunikation Rf-K mit der WRZ, explizit freigegeben wird. Hierbei kann bereits die Übertragung (10) der Applikationsinformationen lex in das autorisierte Terminal WRZ über die logische Kommunikationsund Applikationsschnittstelle LCAI des Terminals erfolgen, als zusätzliche Sicherheitsmassnahme.
Die logische Kommunikations- und Applikationsschnittstelle LCAI ist ein wichtiges Element zur Einhaltung der Regeln des Autorisierungssystems A über alle Stufen und für alle Terminals WR, WRZ und Datenträger IM des Systems. Es können auch Terminals vorgesehen sein, die noch keine Applikation enthalten, sogenannte generische Terminals g-WR mit einem Applikations-Microprozessor uP- WR, in welche eine Applikation lex durch einen Datenträger IMex temporär geladen und auch ausgeführt wird. Nachher kann diese Applikationsinformation lex wieder gelöscht werden. So kann im Prinzip jeder Datenträger IM seine Applikation selber mitbringen, z.B. für einen einmaligen Zutritt oder zur Realisierung von Applikationen mit individuellen Applikationsprofilen ind.
Ein weiterer Vorteil generischer Terminals g-WR besteht darin, dass sie über einen relativ flexiblen Applikations-Prozessor uP-WR verfügen müssen. Dieser kann einem Datenträger IM, IMex, welcher selber über keinen Applikations-Prozessor uP-IM verfügt, zur Verfügung gestellt werden, d.h. der uP-WR kann zur Simulierung eines nicht vorhandenen uP-IM verwendet werden. Dies ermöglicht die gleichzeitige Verwendung von Datenträgern IM, IMex mit und ohne Applikations-Prozessor uP- IM im gleichen System.
Die Fig. 5a, b, c illustrieren die Verteilung von Applikationsinformationen lex, d.h. von Applikationsdaten Idat und Programmcodes Icod auf die Terminals WR, WRZ und die Datenträger IM, IMex sowie die Ausführung (18) von Applikationen App an den zugeordneten Funktionseinrichtungen App HW/SW unter Einhaltung der Regeln des Autorisierungssystems A. Die Applikationsdaten Idat und die Programmcodes Icod werden in den Terminals WR verarbeitet und die Einhaltung der Autorisierungs- regeln A wird geprüft durch Bildung einer Funktion f(A, Icod, Idat). Nach erfolgter Prüfung (17) dieser Funktion wird die Applikation App an der zugeordneten Funktionseinrichtung App HW/SW ausgeführt (18).
Die Fig. 5a beschreibt den bekannten Stand der Technik für berührungslose Systeme. Hier findet eine strenge Trennung zwischen dem Programmcode Icod im Terminal WR und den Applikationsdaten Idat im Datenträger IM statt. Die Einhaltung der Autorisierungsregeln A erfolgt im Terminal WR durch Ermittlung einer Funktion f (A, Icod, Idat) durch den Applikationsprozessor uP-WR des Terminals.
Fig. 5b beschreibt eine neue Möglichkeit nach dem erfindungsgemässen Verfahren. Die bisherige strenge Trennung zwischen dem Programmcode Icodl im Terminal WR oder WRZ und den Applikationsdaten Idat im Datenträger IMex wird aufgehoben. Teile des Programmcodes Icod2 (oder auch der ganze Programmcode) befinden sich hier im Datenträger IMex. Der Programmcode Icod2 wird wie die Applikationsdaten Idat in das Terminal WR, WRZ übertragen. Die Einhaltung der Regeln erfolgt im Terminal WR durch Ermittlung einer Funktion f(A, Icodl, Icod2, Idat) mit separater Verarbeitung von Icodl, Icod2, oder einer Funktion f (A, Icodl + Icod2, Idat) mit kombinierter Verarbeitung von Icodl und Icod2, durch den Applikationsprozessor uP-WR des Terminals.
Fig. 5c beschreibt eine weitere neue Möglichkeit, falls der Datenträger IMex auch über einen Applikations-Prozessor uP-IM verfügt. In diesem Fall kann im Datenträger IMex durch den uP-IM eine Funktion fl(Icod2, Idat) ermittelt werden, welche zur Ermittlung der Funktion f2 im Terminal verwendet werden kann. Diese Funktion f2 kann sein: f2(A, fl, Icodl, Icod2, Idat) oder f2(A, fl, Icodl) oder in der einfachsten Form f2(A, fl). In der einfachsten Form erfolgt im Terminal WR, WRZ nur noch die Einhaltung der Regeln des Autorisierungssystems A und es findet keine Verarbeitung von Idat, Icodl und Icod2 im Terminal statt, sondern nur im Datenträger IMex.
Die Fig. 5b und 5c verdeutlichen auch das Konzept des generischen Terminals g- WR, welches sich dadurch auszeichnet, dass im Terminal WR kein einer Applikation zugeordneter Programmcode Icodl vorhanden ist, sondern nur ein Programmcode Icod2 im Datenträger. Die Fig. 5b und 5c illustrieren auch die Grundlage für die Realisierung von Applikationen mit individuellen Applikationsprofilen ind, indem beim autorisierten Terminal WRZ sowohl der für die Individualisierung notwendige Programmcode Icod wie auch die notwendigen Applikationsdaten Idat auf den Datenträger IMex geladen werden.
Die Fig. 6 zeigt schematisch ein erfindungsgemässes System zur Initialisierung von Applikationen App mittels Applikationsinformationen lex, welche von autorisierten Terminals WRZ über Datenträger IMex an den Applikationen App zugeordnete Terminals WR transportiert, in diese eingeschrieben und dort auch ausgeführt werden. Das Beispiel zeigt mehrere zentrale Hosts Hl, H2, mehrere autorisierte
Terminals WRZ1, WRZ2, WRZ3 und mehrere Terminals WR4 - WR8. Im Rahmen des Autorisierungssystems A können im Prinzip beliebige verschiedene und unabhängige Applikationen über die autorisierten Terminals WRZ und die Datenträger IMex in die verschiedenen zugeordneten Terminals WR in beliebiger Kombination initialisiert werden, soweit die vorhandenen Speicherkapazitäten dazu ausreichen (Fig. 7).
Die Fig. 7 zeigt ein Ausführungsbeispiel eines Systems nach Fig. 6 mit drei verschiedenen unabhängigen Applikationen Appl, App2, App3 von unabhängigen Anwen- dem, welche von den autorisierten Terminals WRZ1, WRZ2, WRZ3 auf die mobilen Datenträger IMex übertragen und von diesen an zugeordnete Terminals WR4 - WR8 übertragen werden, z.B von der WRZ1 die Applikation App2 in die Terminals WR4, 5, 7, von der WRZ2 die Applikation Appl in die Terminals WR4, 7, 8 und von der WRZ3 die Applikation App3 temporär in das Terminal WR6 (als g-WR).
Nachdem die Applikationen in den Terminals WR installiert sind, erfolgen durch die Datenträger IMex entsprechende Statusrückmeldungen Ist an die autorisierten Terminals WRZ und von diesen an den zentralen Host H, z.B.: die Applikation Appl sei installiert im Terminal WR8, wird zurückgemeldet an WRZ3 und H.
In der Praxis werden meist mehrere Datenträger IMex dieselbe Applikation lex an ein bestimmtes Terminal WR präsentieren, wo diese Applikation natürlich nur einmal in das Terminal transferiert werden muss. Ebenso kann die gleiche Statusmeldung Ist bezüglich Einschreiben einer bestimmten Applikation in ein bestimmtes Terminal WR von mehreren Datenträgern IMex an die autorisierten Terminals WRZ (und den Host H) zurückgemeldet werden. Nachdem alle gewünschten Applikationen in allen gewünschten Terminals WR installiert sind, kann diese Applikation in den Datenträgern IMex und im autorisierten Terminal WRZ im Prinzip wieder gelöscht bzw. weitere Übertragungen an die IMex gestoppt werden. Und nachdem alle benötigten Statusrückmeldungen Ist erfolgt sind, können auch weitere Statusrückmeldungen gestoppt werden. Statusrückmeldungen bezüglich Ausübungen von Applikationen an den Terminals WR könnten nach Bedarf, soweit und solange benötigt, auch weitergeführt werden.
Je nach Bedarf können die Applikationsinformationen lex in den Datenträgern IMex, den Terminals WR und/oder den autorisierten Terminals WRZ nur temporär vorhan- den sein und anschliessend wieder gelöscht werden. Dabei können die Applikationsinformationen lex für eine vorgebbare Zeitdauer oder für eine bestimmte Anzahl oder Art von Vorgängen oder bis eine bestimmte Bedingung erfüllt ist temporär vorhanden sein.
Beispiele für die erfindungsgemässe Initialisierung von Applikationen in Terminals: Dabei kann es sich um neue Applikationen Appn handeln oder um ein Update bestehender Applikationen, welche durch eine geänderte, erweiterte Applikation Appu ersetzt bzw. ergänzt werden. Ein Beispiel für eine Update- Applikation Appu: Der Zutritt zu einem Raum erfolge durch Prüfung der Referenznummer eines Datenträgers IM1 und durch Eingabe eines PIN-Codes durch den Inhaber dieses Datenträgers IM1. Diese bestehende Applikation soll erweitert werden, so dass der Zutritt nur möglich ist, wenn in kurzer Zeit (z.B. 30 Sekunden) ein zweiter berechtigter Datenträger IM2 präsentiert und der PIN- Code dieser zweiten Person am Terminal eingegeben wird. Diese erweiterte Applikation Appu wird so angepasst, dass der Prüfungsvorgang entsprechend zweimal durchlaufen wird. Die Funktionsausrüstung App HW/SW zur physischen Ausführung dieser Applikation muss am Terminal WR schon vorhanden sein.
Als weiteres Beispiel einer Applikationserweiterung Appu könnte ein bestehender 4-stelliger PIN-Code als Zutrittsbedingung mit der Appu durch einen 6-stelligen PIN-Code ersetzt werden.
Beispiel einer neuen Applikation Appn: Der Zutritt erfolge bisher durch Prüfung der Referenznummer eines Datenträgers IM. Neu soll zusätzlich auch die Eingabe und Überprüfung des PIN-Codes des Inhabers des Datenträgers IM erfolgen. Dazu wird durch einen Datenträger IMex eine neue Applikation Appn im Terminal WR installiert, wobei die notwendige Funktionseinrichtung App HW/SW am Terminal schon vorhanden ist oder simuliert werden kann, z.B. mit einem PSOC (Programmable System on Chip) einem Baustein, bestehend aus einem Microprozessor und einem Analogteil, wobei die Funktionalität des Analogteils in gewissen Grenzen durch den Microprozessor bestimmt und geändert werden kann (d.h. im weitesten Sinn wird mittels Software die Hardware des Bauteils simuliert). Mit neuen Applikationen Appn kann somit auch eine neue oder erweiterte Nutzung von bestehenden
Ausrüstungen bzw. Funktionseinrichtungen an den Terminals WR eingerichtet werden. Die Anpassung einer Kenngrösse eines Funktionsgerätes veranschaulicht als Anwendungsbeispiel ein Update einer Applikation Appu in Kombination mit einer Rekonfiguration der App HW/SW. Die Applikation bestehe im automatischen Öffnen einer Türe, indem z.B. ein Relais einen Kontakt freischaltet, mechanisch ein Sicherungsstift bewegt wird und ein Motor die Türe öffnet. Zur Kompensation von Alterung und Verschleiss dieser Komponenten kann das Terminal WR über eine Applikationsinformation lex rekonfiguriert werden. Dazu wird in das Terminal WR ein Update der Applikationsparameter Ipar der zur App HW/SW gehörenden Funktions gerate (Relais, Motor) übertragen, wodurch das Relais und der Motor mit neuen Referenzwerten (z.B. mit erhöhtem Strom) betrieben werden, um zu verhindern, dass bei einem Betrieb mit den alten Referenzwerten das Relais den Sicherungsstift nicht freischaltet bzw. die Türe klemmt.
Die Datenträger IMex können auch Applikationsinformationen lex mit individuellen Applikationsprofilen ind aufweisen.
Beispielsweise können individuelle Zutrittszeiten für jede Person nur auf ihrem eigenen Datenträger IM gespeichert sein, währenddem nur die allgemeinen Zutrittsbedingung als Applikation in den Terminals WR eingeschrieben werden. Oder es können auch Applikationen lex mit individuellem Profil ind initialisiert werden, welche je nach Inhaber des Datenträgers IMex unterschiedlich sind. Beispielsweise soll der Zutritt zu einem Raum im Terminal WR unterschiedlich geprüft werden. Für einen bestimmten Kreis von engeren Mitarbeitern ist nur die Prüfung der Referenznummern ihrer Datenträger erforderlich. Während für andere Personen auch eine Prüfung ihres PIN-Codes zusätzlich zu den Referenznummern erforderlich ist.
Temporärer Ausweis für selektiven Zutritt: Für ein Zutrittssystem zu Produktionsanlagen einer Tochterfirma im Land b sollen neu Ausweise erstellt werden, mit denen Beauftragte der Zentrale aus dem Land a in Land b unangekündigte Kontrollbesuche ausführen können. Dazu können in der Zentrale an einem autorisierten Terminal WRZ Datenträger IMex mit den entsprechenden Applikationsinformationen lex geladen werden. Im Land b werden die Datenträger IMex an den dortigen Terminals präsentiert, die Applikation wird temporär initialisiert und auch ausgeführt, d.h. der Zutritt wird während der Dauer des geplanten Kontrollbesuchs gewährt.
Ein weiteres Beispiel: Eine Applikation bestehe in der Zugangsberechtigung für ein EDV-Zentrum, wobei der Datenträger des Karteninhabers geprüft wird. Diese Zugangsberechtigung soll nun verschärft werden durch eine neue, erweiterte Applikation App, mit welcher die Zugangsprüfung zusätzlich einen persönlichen Code pers (PIN Code oder biometrischen Code) des Inhabers des Datenträgers erfordert. Weiter sollen auch gewisse Daten oder Informationen ausgegeben oder angezeigt werden. Verfügt das Terminal über kein Display, so besteht die Möglichkeit, neben dem Terminal eine Display einheit anzubringen, welche z.B. wie der Datenträger berührungslos mit dem Terminal kommunizieren soll. Dies erlaubt es, auf eine Verkabelung der Display einheit (mit dem Terminal WR oder einem Host H) zu verzichten. Bei einer solchen Erweiterung muss das Terminal in die Lage versetzt werden, die Displayeinheit anzusprechen, d.h. das Terminal bzw. dessen entsprechende Parameter Ipar müssen so rekonfiguriert werden, dass die Kommunikation sowohl mit einem Datenträger IMex wie mit der Displayeinheit möglich ist. Die hierfür notwendigen Applikationsinformation lex werden über einen Datenträger IMex in das Terminal WR übertragen. Im Falle einer Anwendung mit individuellem Anforderungsprofil ind wird weiter z.B. aufgrund der Applikationsinformationen lex auf dem Datenträger IMex entschieden, ob die Displayeinheit Bestandteil der Applikation App ist und wie sie vom Terminal WR angesprochen werden soll.
Eine weitere Erhöhung der Zugangssicherheit kann z.B. mit einer zusätzlichen Verschärfung durch eine weitere Applikation App2 initialisiert werden, mit welcher der Zutritt nur zu zweit erlaubt wird, d.h. in der erweiterten Applikation App2 prüft das Terminal den Datenträger einer ersten Person und dessen persönlichen Code und anschliessend den Datenträger einer zweiten Person und deren persönlichen Code, worauf erst bei Übereinstimmung aller Daten der Zugang zum EDV-Zentrum freigegeben wird.
Im Rahmen dieser Beschreibung werden die folgenden Bezeichnungen verwendet:
H Host, Zentrale A Autorisierungssystem
AM Autorisierungsmittel, Übertragungs-Autorisierungsmedium
IM mobiler Datenträger, Identifikationsmedium
IMex IM zur Übertragung von Applikationsinformationen lex
Rf berührungslos Rf-K berührungslose Kommunikation
WR Terminal, Schreib- und Lesestation
WRZ autorisiertes Terminal, bestimmtes zentrales Terminal g-WR generische WR
App Applikation Appn neue Applikation
Appu Applikationserweiterung, Update
Appl, App2 unabhängige Applikationen ind individuelle Applikationsprofile
App HW/SW Applikations-Hardware/-Software zu WR, Funktionseinrichtungen lex Applikationsinformationen
Idat Daten einer Applikation
Ipar Parameter
Icod Programmdaten, Programmcode lex = Idat, Ipar, Icod Ist Statusinformationen f Funktion mit Prüfgrössen
SL Sicherheitslevel
SL-IM, SL-WR SL von IM bzw. von WR, WRZ
ID Identifikationsdaten
ID-IM, ID-WR ID der IM bzw. ID der WR, WRZ
SM Sicherheitsmodul
MEM Memory, Datenspeicher
API Application Programming Interface crypl Verschlüsselung der Kommunikation cryp2 Verschlüsselung der Applikation pers persönliche Daten oder Code (PIN, biometrischer Code) uP-WR Microprozessor inWR für App uP-IM Microprozessor in IM für App ta, tb Zeitpunkte va, vb Versionennummern la Autorisierungsinformation
F/P Flag/Pointer
F/P-IMex F/P von IMex
F/P-App F/P einer Applikation mit lex (App)
If Freigabeinformation
9 Überführung WR in WRZ, Auswahl, Autorisierung
10 neue Applikation in WRZ laden
11 Prüfung von IMex
12 Einschreiben von lex, Setzen von F/P
13 Transfer der IMex
14 Prüfung von WR, IMex
15 Übertragung an WR
17 Prüfung von IM 18 Ausführung von App
20 Status Rückmeldungen
21 Umwandlung WR in WRZ
22 Rückführung von WRZ in WR

Claims

PATENT ANSPRUCHE
1. Verfahren zur Initialisierung oder Erweiterung einer Applikation App, d.h. zur Übertragung von den einer Applikation App zugeordneten Applikations- Informationen lex auf Terminals bzw. Schreib- und Lesestationen WR eines
Systems mit mobilen Datenträgern IM, Terminals WR und einem hierarchischen Autorisierungssystem A, dadurch gekennzeichnet, dass bestimmte Terminals WRZ ausgewählt und autorisiert werden, die Applikationsinformationen lex von einem autorisierten Terminal WRZ auf mobile Datenträger IMex geladen werden und dass anschliessend beim Präsentieren von diesen Datenträgern IMex an weiteren Terminals WR die Applikationsinformationen lex auf diese weiteren, der Applikation zugeordneten Terminals WR übertragen werden, so dass anschliessend die Applikation App an diesen Terminals WR für berechtigte Datenträger IM und IMex ausführbar ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Terminal WR mittels Autorisierungsinformationen la in ein autorisiertes Terminal WRZ übergeführt wird.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Laden von Applikationsinformationen lex von einem autorisierten Terminal WRZ auf einen Datenträger IMex nach der Freigabe des autorisierten Terminals WRZ mittels Freigabeinformationen If erfolgt. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das System eine berührungslose Kommunikation (Rf-K) zwischen den Terminals WR, WRZ und den Datenträgern IM, IMex aufweist.
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die. Applikationsinformationen lex Applikationsdaten Idat, Applikationsparameter Ipar und Programmdaten Icod enthalten können.
6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass von den mobilen Datenträgern IMex. Statusinformationen Ist über Ereignisse an den Terminals WR bezüglich Übertragung der Applikations Informationen lex und
Ausführung der entsprechenden Applikation an die autorisierten Terminals WRZ zurückgemeldet werden.
7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Terminal WR mittels der Übertragung von Applikationsinformationen lex durch einen Datenträger IMex in ein weiteres autorisiertes Terminal WRZ umgewandelt wird und dass anschliessend die Applikationsinformationen lex von diesem weiteren autorisierten Terminal WRZ auf weitere Datenträger IMex geladen werden, durch welche die Applikationsinformationen lex wiederum auf weitere Terminals WR übertragen werden.
. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass ein Terminal WR nur temporär in ein autorisiertes Terminal WRZ umgewandelt wird.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass ein Terminal WR nur für die Übertragung von Statusinformationen Ist in ein autorisiertes Terminal WRZ umgewandelt wird.
10. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Applikationsinformationen lex in den Datenträgern IMex, den Terminals WR und/oder den autorisierten Terminals WRZ nur temporär vorhanden sind und anschliessend wieder gelöscht werden.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Applikationsinformationen lex für eine vorgebbaren Zeitdauer oder für eine bestimmte Anzahl oder Art von Vorgängen temporär vorhanden sind.
12. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Kontrollmechanismus vorgesehen ist, welcher sicherstellt, dass eine neuere Applikation Appb in einem Terminal WR nicht durch eine ältere Applikation Appa gelöscht bzw. überschrieben werden kann, welche später durch einen anderen Datenträger IMex präsentiert wird.
3. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Kontrollmechanismus eine Zeitkontrolle (tb > ta)) oder eine Versionenkontrolle (vb > va) aufweist.
14. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Datenträger IM einen Sicherheitslevel SL-IM und die Terminals WR einen Sicherheitslevel SL-WR enthalten, welche die Übertragung der neuen Applikation App auf die Datenträger IMex und auf die Terminals WR oder deren anschliessende Ausführung kontrollieren.
15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass die Sicherheitslevels SL ein funktioneller Bestandteil des Autorisierungssystems A sind und die Regeln des Autorisierungssystems A verhindern, dass ein Sicherheitslevel
SL-IM oder SL-WR in einem Datenträger IM oder in einem Terminal WR erhöht werden kann.
16. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Applikations- Informationen lex zur Übertragung vom autorisierten Terminal WRZ bis zu den Terminals WR mit einer separaten Verschlüsselung cryp2 verschlüsselt und nur in Terminals WR oder durch Datenträger IMex entschlüsselt werden können, welche einer den Applikationsinformationen lex entsprechenden Applikation zugeordnet sind.
17. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Datenträger IMex durch Identifikationsdaten ID-IM für die Übertragung von bestimmten Applikationsinformationen lex bestimmt werden.
18. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Terminals WR durch Identifikationsdaten ID-WR für die Aufnahme von bestimmten Applikationsinformationen lex bestimmt werden.
19. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass für die Übertragung der neuen Applikation App auf die Datenträger IMex oder von den Datenträgern auf die Terminals WR als zusätzliche Sicherheitsanforderung eine persönliche Identifikation pers (wie PIN-Code oder biometrischer Code) des Karteninhabers oder des Inhabers des Terminals benötigt wird.
20. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zur Übertragung der Applikationsinformationen lex oder von Statusinformationen Ist die Datenträger IMex und/oder die Terminals WR aktiv (d.h. von sich aus Informationen lex, Ist zur Verfügung stellend) wirken können.
21. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in den
Datenträgern IMex mit der Übertragung von Applikationsinformationen lex auch Flag/Pointer F/P gesetzt werden.
22. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Datenträger IMex einen Applikations-Microprozessor (uP-IM) aufweisen, welcher Applikationsinformationen lex in Zusammenarbeit mit dem Applikations- Microprozessor des Terminals (uP-WR) verarbeiten kann.
23. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Datenträger IMex Applikationsinformationen lex mit individuellen Applikationsprofilen ind aufweisen.
24. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass generische Terminals g-WR mit einem Applikations-Microprozessor (uP-WR) vorgesehen sind, in welchen eine bestimmte Applikation nicht enthalten ist und in welche diese Applikation durch einen Datenträger IMex temporär geladen wird.
25. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Terminals WR eine logische Kommunikations- und Applikationsschnittstelle LCAI enthalten, über welche Applikationsinformationen lex in die Terminals geladen und ausgelesen werden können.
26. Verfahren nach Anspruch 25, dadurch gekennzeichnet, dass eine Applikation App nur nach dem Laden und Auslesen über die logische Kommunikationsund Applikationsschnittstelle LCAI ausgeführt werden kann.
27. Verfahren nach Anspruch 25, dadurch gekennzeichnet, dass die logische Kommunikations- und Applikationsschnittstelle LCAI die Einhaltung von Regeln des Autorisierungssystems A sicherstellt.
28. Verfahren nach Anspruch 25, dadurch gekennzeichnet, dass die Überprüfung der Sicherheitslevel SL in der logischen Kommunikations- und Applikationsschnittstelle LCAI erfolgt.
29. Verfahren nach Anspruch 25, dadurch gekennzeichnet, dass die logische
Kommunikations- und Applikationsschnittstelle LCAI einen Interpreter oder ein Application Programming Interface (API) enthält.
30. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mehrere unabhängige Applikationen (Appl, App2) je von unabhängigen Anwendern für zugeordnete Terminals (WRI, WR2) je an zugeordneten autorisierten Terminals (WRZ1, WRZ2) in die mobilen Datenträger IMex geladen werden und je an entsprechende zugeordnete Terminals (WRI, WR2) übertragen werden.
31. Mobiler Datenträger in einem System mit Datenträgern IM, zugeordneten Terminals WR und einem hierarchischen Autorisierungssystem A, dadurch gekennzeichnet, dass der Datenträger IMex in einem Speicher eine von einem ausgewählten, autorisierten Terminal WRZ geladene neue oder erweiterte Applikation App mit Applikationsinformationen lex enthält, welche beim Präsentieren des Datenträgers an weiteren, der Applikation zugeordneten
Terminals WR eingeschrieben und im Folgenden durch die Terminals auch ausgeführt werden kann.
2. Mobiler Datenträger nach Anspruch 31, dadurch gekennzeichnet, dass der Datenträger IMex Applikationsinformationen Iexl, Iex2 von verschiedenen unabhängigen Applikationen (Appl, App2) enthält, welche auf verschiedene zugeordnete Terminals (WRI, WR2) übertragbar sind.
33. System mit mobilen Datenträgern IM, Terminals WR und einem hierarchischen Autorisierungssystem A, gekennzeichnet durch mindestens ein ausgewähltes, autorisiertes Terminal WRZ, an welchem neue oder erweiterte Applikationen App mit Applikationsinformationen lex in Datenträger IMex geladen werden, welche Informationen lex an weiteren, der Applikation App zugeordneten Terminals WR in diese eingeschrieben und durch die Terminals auch ausgeführt werden.
EP02782612A 2001-12-17 2002-12-17 Verfahren zur initialisierung einer applikation in terminals Withdrawn EP1456820A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CH23072001 2001-12-17
CH23072001 2001-12-17
PCT/CH2002/000701 WO2003052704A2 (de) 2001-12-17 2002-12-17 Verfahren zur initialisierung einer applikation in terminals

Publications (1)

Publication Number Publication Date
EP1456820A2 true EP1456820A2 (de) 2004-09-15

Family

ID=4568492

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02782612A Withdrawn EP1456820A2 (de) 2001-12-17 2002-12-17 Verfahren zur initialisierung einer applikation in terminals

Country Status (8)

Country Link
US (1) US20050086506A1 (de)
EP (1) EP1456820A2 (de)
JP (1) JP2005513635A (de)
KR (1) KR20040068229A (de)
CN (1) CN1313984C (de)
AU (1) AU2002347190A1 (de)
CA (1) CA2470806A1 (de)
WO (1) WO2003052704A2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH716409B1 (de) * 2003-11-12 2021-01-29 Legic Identsystems Ag Verfahren zum Einschreiben einer Datenorganisation in Identifikationsmedien und zum Einschreiben und Ausführen von Applikationen in der Datenorganisation.
EP2418828A1 (de) * 2010-08-09 2012-02-15 Eltam Ein Hashofet Verfahren und System zum Laden von Firmware

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0993662A1 (de) * 1997-07-02 2000-04-19 Sonera Oyj Verfahren zur kontrolle von anwendungen gespeichert in einem teilnehmererkennungsmodul

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09167098A (ja) * 1995-07-28 1997-06-24 Hewlett Packard Co <Hp> 携帯装置用通信システム
JP4071285B2 (ja) * 1996-03-11 2008-04-02 カバ シュリースシステーメ アーゲー パッシブ型電子データキャリアを持つ識別媒体
US6230267B1 (en) * 1997-05-15 2001-05-08 Mondex International Limited IC card transportation key set
JP3906535B2 (ja) * 1997-11-07 2007-04-18 ソニー株式会社 ダウンロードシステム、及び記録媒体
US6678741B1 (en) * 1999-04-09 2004-01-13 Sun Microsystems, Inc. Method and apparatus for synchronizing firmware
US6671737B1 (en) * 1999-09-24 2003-12-30 Xerox Corporation Decentralized network system
WO2001042598A1 (en) * 1999-12-07 2001-06-14 Kaba Ilco Inc. Key control system for electronic locks
JP4618467B2 (ja) * 2000-01-05 2011-01-26 ソニー株式会社 汎用コンピュータおよび汎用コンピュータにおける著作権管理方法
US20010051928A1 (en) * 2000-04-21 2001-12-13 Moshe Brody Protection of software by personalization, and an arrangement, method, and system therefor

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0993662A1 (de) * 1997-07-02 2000-04-19 Sonera Oyj Verfahren zur kontrolle von anwendungen gespeichert in einem teilnehmererkennungsmodul

Also Published As

Publication number Publication date
KR20040068229A (ko) 2004-07-30
WO2003052704A2 (de) 2003-06-26
CA2470806A1 (en) 2003-06-26
CN1313984C (zh) 2007-05-02
WO2003052704A3 (de) 2004-06-24
AU2002347190A1 (en) 2003-06-30
US20050086506A1 (en) 2005-04-21
CN1620675A (zh) 2005-05-25
JP2005513635A (ja) 2005-05-12

Similar Documents

Publication Publication Date Title
DE69525732T3 (de) Kartenförmiges Speichermedium
DE10256799B3 (de) Verfahren zur Programmierung von Flash-E-PROMs in einer mit einem Mikroprozessor ausgerüsteten Steuerelektronik für Straßenfahrzeuge
EP2626824A1 (de) Management durch ein mobiles Endgerät bereitgestellter virtueller Brieftaschen
DE10040438A1 (de) Adressvergabeverfahren für mindestens einen neu an ein Bussystem angeschlossenen Busteilnehmer
WO1997001147A2 (de) Verfahren zur vereinfachung der kommunikation mit chipkarten
DE102006032129A1 (de) Skalierbares Verfahren zur Zugriffssteuerung
EP1421460A2 (de) Verfahren zur bereitstellung von software zur verwendung durch ein steuergerät eines fahrzeugs
EP1196902B1 (de) Verfahren zum betreiben eines zur ausführung von nachladbaren funktionsprogrammen ausgebildeten datenträgers
EP3620917A1 (de) Verwalten von lizenzen für soft-ip auf einem partiell rekonfigurierbaren hardware-system
EP1456820A2 (de) Verfahren zur initialisierung einer applikation in terminals
DE10048939B4 (de) Bedingte Unterdrückung der Überprüfung eines Karteninhabers
DE102015101523A1 (de) Verfahren zur Berechtigungsverwaltung in einer Anordnung mit mehreren Rechensystemen
DE102017005057A1 (de) Personalisieren eines Halbleiterelements
EP0847031A1 (de) Verfahren zum gesicherten nachträglichen Programmieren einer Mikroprozessorkarte für eine zusätzliche Anwendung
EP1218862A1 (de) Verfahren zur initialisierung von mobilen datenträgern
DE102017204156B3 (de) System und Verfahren zur sicheren Fahrzeugkommunikation
EP3038062B1 (de) Verfahren und Fahrzeugeinrichtungen zur DSRC-Kommunikation
DE60213632T2 (de) Byte-übertragungsverwaltung in einer chipkarte
EP1634252A1 (de) Verfahren zum laden von tragbaren datenträgern mit daten
EP2740070B1 (de) Mechanismus zur kommunikation zwischen zwei applikationen auf einem sicherheitsmodul
EP1739559A2 (de) Behandlung von Fehlerereignissen bei einem tragbarem Datenträger
EP1927870A2 (de) Tragbarer Datenträger
DE102018001565A1 (de) Sicherheitselement und Verfahren zur Zugriffskontrolle auf ein Sicherheitselement
CH716409B1 (de) Verfahren zum Einschreiben einer Datenorganisation in Identifikationsmedien und zum Einschreiben und Ausführen von Applikationen in der Datenorganisation.
EP1691290B1 (de) Verfahren zur Sicherung einer Datenbank und Vorrichtung zur Durchführung des Verfahrens

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: 20040524

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO

17Q First examination report despatched

Effective date: 20101118

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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: 20170701

RIC1 Information provided on ipc code assigned before grant

Ipc: G07F 7/10 20060101AFI20030702BHEP