EP1579318A2 - Tragbarer datenträger mit netzserverfunktionalität - Google Patents

Tragbarer datenträger mit netzserverfunktionalität

Info

Publication number
EP1579318A2
EP1579318A2 EP03785881A EP03785881A EP1579318A2 EP 1579318 A2 EP1579318 A2 EP 1579318A2 EP 03785881 A EP03785881 A EP 03785881A EP 03785881 A EP03785881 A EP 03785881A EP 1579318 A2 EP1579318 A2 EP 1579318A2
Authority
EP
European Patent Office
Prior art keywords
data carrier
data
interpreter
application program
transmission mode
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.)
Ceased
Application number
EP03785881A
Other languages
English (en)
French (fr)
Inventor
Daniel Ciesinger
Frank GÖTZE
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.)
Giesecke+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient GmbH
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 Giesecke+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of EP1579318A2 publication Critical patent/EP1579318A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/073—Special arrangements for circuits, e.g. for protecting identification code in memory
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/0772—Physical layout of the record carrier
    • G06K19/07733—Physical layout of the record carrier the record carrier containing at least one further contact interface not conform ISO-7816
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

  • the invention is based on a portable data carrier according to the preamble of the main claim.
  • a portable data carrier such is known for example from EP 932 865 B1.
  • It describes an IC card that offers the option of loading applications that were written in the high-level Java programming language (see also http://java.sun.com).
  • class files In clear text created in Java applications are first in so-called “class files” compiled, which are subsequently subjected to conversion. Therein, the class files in compact "card class files” or “card application files” or “CAP-fil 'it "transferred, which are finally transferred to the IC card.
  • CAP-fil 'it transferred
  • a chip card as a web server, ie as a network server on the Internet and to provide the card with a proxy functionality.
  • a five-layer network structure is set up on the card, which has a physical transmission layer, a data transmission layer, a network layer, a transport layer and an application layer includes.
  • the application path includes utilities that implement the functionality of a web server on the one hand and the functionality of a proxy server on the other.
  • the physical transmission layer and the data transmission layer correspond to the current chip card standards and support conventional card commands, so that the card can be addressed in a known manner.
  • the proposed card enables secure handling of data that are exchanged between a terminal and a network server.
  • the font does not provide information on how an application can be loaded into the card.
  • An operating system for realizing a multi-application card is also known ("OSSCA”: Operating System for Smart Cards, prospectus from KEYCORP Ltd., March 1999, available at http://keycorp.net/smartcard/ ossca.pdf), which is used for execution of application programs written in a variant of the high level programming language FORTH is set up and such application programs can be reloaded.
  • the operating system allows up to four applications to be executed simultaneously.
  • communication between chip card and terminal takes place in accordance with a conventional, standardized chip card protocol a standard chip card interface Communication with the chip card requires special, suitable terminals.
  • the object of the invention is to provide a portable data carrier which is suitable for being used as a network server and which, for this use, places the lowest possible demands on the usage environment.
  • the object is achieved by a portable data carrier with the features of the main claim.
  • the basis for the portable data carrier according to the invention is the approach of not initially providing elements that only serve to set up the data carrier for use in applications tailored specifically to portable data carriers.
  • He- Portable data carriers according to the invention only have a standard interface adopted from the field of computer technology and means for carrying out two different transmission modes, a first transmission mode being used to set up applications, while the other is used to use the applications using a known network protocol.
  • An essential element of these means is a distribution unit which prevents the setting of the transmission mode to be used in each case.
  • the data carrier according to the invention has the advantage that applications can be addressed using a conventional network protocol which is not specific to the data carrier and which is common for communication between participants connected via a network.
  • the network protocol can be a conventional TCP / IP protocol.
  • the data carrier can thus be used in any TCP / IP environment.
  • a data carrier equipped with TCP / IP is suitable for use in a local area network ("LAN") which can be connected to the Internet via an address translator. The data carrier then behaves like a regular Internet user.
  • LAN local area network
  • Another particular advantage of the data carrier according to the invention is that programs for implementing new applications can be loaded onto a portable data carrier in a high-language format without preprocessing.
  • the high-level language FORTH is particularly suitable for program creation.
  • the applications placed on a portable data carrier advantageously comprise a card-resident network server, by means of which the applications can be navigated.
  • the network server can in particular be a Web server for use on the Internet.
  • a first network server can be an HTTP server and a second network server can be an FTP server.
  • the structure provided for a data carrier according to the invention makes it possible to initially equip data carriers with only one interpreter during production, but no applications yet. This can be done by the customers of the data carriers.
  • FIG. 2 shows the structures of a portable data carrier with network server functionality and of a terminal device interacting with the portable data carrier
  • Fig. 6 shows a practical application of a data carrier.
  • USB Universal Serial Bus
  • Protocol Software component that acts as an intermediary between a sending and a receiving entity during data transmission.
  • SLIP Serial Line Internet Working Protocol
  • PPP Point to Point Protocol
  • TCP Transmission Control Protocol.
  • IP Internet Working Protocol
  • UDP User Datagram Protocol. Particularly simple protocol without overhead.
  • DHCP Dynamic Host Contention Protocol Automatic address assignment in the network under Windows.
  • CGI Common Gateway Interface
  • HTML Hypertext Markup Language
  • OSI layer model Open System Interconnection layer model.
  • ASCII code assignment rule that corresponds to a defined alphanumeric
  • FIG. 1 illustrates the basic structure of a chip card 10 which is suitable as a multifunction card for use in different applications and which can be loaded with new application programs in the context of a high-level language programming environment.
  • An essential element of the chip card 10 is an integrated circuit 1 in the form of a microcontroller, which has a processor core 2 and a memory system with three memory fields 3, 4 and 5 on a single semiconductor chip.
  • the microcontroller 1 is also connected to a data carrier interface 24 for the exchange of data with an external terminal 100.
  • the first 3 is typically a mask-programmed read-only memory in the form of a ROM
  • the second is an electrically erasable and writable read-only memory in the form of an EEPROM or a FLASH memory
  • the third is a volatile read / write memory , usually in the form of a RAM.
  • the first memory field 3 contains the program code of the operating system of the chip card 10. Furthermore, the program code of basic application programs that should be present on all chip cards 10 can be stored in the first memory field 3. The entire program code stored in the first memory field 3 is used to produce the chip card 10 by means of a Mask attached to the card as machine code.
  • the second memory field 4 is used to hold the code of application programs subsequently placed on a chip card 10. In addition, it usually also serves as working memory.
  • the third memory field 5 serves as fast working memory in a known manner.
  • the interface 24 can be of the contact type and in particular can be designed as a conventional chip card contact field.
  • the interface 24 can be of the contactless type and can have, for example, the shape of a coil which forms an antenna.
  • the entire structure of the chip card shown in FIG. 1 is known per se and is described, inter alia, in the “manual of chip cards” mentioned.
  • the essential component of the terminal device 100 is a controller 101 with all elements and the basic functionality of a conventional computer.
  • the controller 101 provides a network navigator 150, that is to say an application program for carrying out accesses to data contents which are stored in a network structure such as the Internet.
  • the controller 101 is set up to execute a terminal program 102 which, via a suitable interface, for example a serial RS 232 interface, allows communication with a portable data carrier 10 through data exchange.
  • a suitable interface for example a serial RS 232 interface
  • the terminal device 100 has an interface 122 corresponding to the data transmission interface 24.
  • a software is also installed on the terminal device 100 on the terminal device 100, which interface 122 adapts to the applications located on the terminal device 100, in particular the terminal program 102, the network navigator 150 or a dial-up network with SLIP / PPP.
  • this software provides the interface 122 as a serial interface, for example as an RS 232 interface.
  • the terminal 100 expediently also offers a programming environment by means of which it is possible in connection with a portable data carrier 10 to create new application programs for the portable data carrier 10.
  • Part of the terminal 100 is furthermore a user interface 140 which has means 142 in order to present information of the terminal 100 to a user; typically these means 142 are in the form of a screen.
  • the user interface 140 also has means 144, typically in the form of a keyboard, to enable a user to enter commands to the terminal program 102.
  • the terminal device 100 can be a single arrangement which is accessed by a single user, for example a correspondingly set up conventional computer, but also e.g. a terminal that is available to a large number of users and is, for example, part of an application solution set up on a network.
  • Terminal program 102 and the network navigator 150 Via the terminal program 102 and the network navigator 150, the terminal device 100, under the control of a user, enables activation and use of a functionality available on a portable data carrier 10.
  • Terminal program 102 and network navigator 150 provide the program routines necessary for this. For example, they offer a program routine for establishing communication over the serial Interface 122 or a modem.
  • the terminal program 102 also enables the introduction of new application programs onto a portable data carrier 10.
  • FIG. 2 illustrates the basic logical structure of the arrangement shown in Fig.l.
  • the right-hand part of FIG. 2 shows the structure of the portable data carrier 10, hereinafter referred to only as a data carrier, and the left-hand part shows the structure of a terminal 100.
  • the data carrier 10 is divided into a communication area 20, an interaction area 40 and a server area 50.
  • the terminal device 100 includes a communication area 120, a user interface 140, a terminal program 102 and a network navigator 150.
  • the communication area 20 of the data carrier 10 contains means for carrying out a data exchange between the data carrier 10 and an external terminal 100.
  • Part of this means is in particular a distribution unit 26 which, depending on the data received from the terminal 100, includes a data path to the interaction area 40 or Server area 50 sets up and sets a corresponding transmission mode.
  • the application programs located in the server area 50 are transmitted using a standardized network protocol via the data carriers.
  • Interface 24 supplied incoming data.
  • the data path between the data carrier interface 24 and the server area 50 has an architecture based on the OSI layer model in the form of a protocol stack.
  • the standardized network works protocol is in particular the "TCP / IP" protocol.
  • the interaction area 40 contains an interpreter 44 for setting up application programs in the server area 50 and for executing the application programs.
  • the interaction area 40 also contains a configuration area 48 for receiving parameterizations and settings for the interpreter 44 and the server area 50.
  • the data path into the interaction area 40 is implemented as transparent mode 39, in which the data coming in via the distribution unit 26 are forwarded unchanged.
  • the communication area 20 of the data carrier 10 has a protocol stack structure made up of a plurality of protocol layers one above the other, which is traversed successively by incoming and outgoing data.
  • Each protocol layer implements defined services in which it subjects the data it receives to the specified processing. In doing so, it builds on the services of the layer below and in turn offers its services to the layer above.
  • the services are defined in the form of protocols.
  • Protocol stack structure Basic elements of the protocol stack structure are a feed area 21 and a transport system 22.
  • the first component of the feed area 21 is a transfer layer with the data transmission interface 24 for physical transfer and receipt. acceptance of data to or from a corresponding interface 122 of a terminal 100.
  • the data transmission interface 24 can in particular be designed as a USB or Firewire or as an Ethernet interface.
  • a distribution unit 26 Associated with the data transmission interface 24, as a second component of the feed area 21, is a distribution unit 26. Depending on the data received via the data carrier interface 24, it defines a data path on which the data is forwarded and sets the transmission mode to be used for the data transmission. 2, a first data path points into the interaction area 40, a second data path into the server area 50. In the first case, the data transmission takes place in transparent mode 39. In the second case, the data transmission takes place in a network protocol mode 38 using a network protocol. In the latter case, the set data path points to the first layer 28 of the transport system 22 that is based on the data transmission interface 24. The number of data paths is not limited to two but can be increased as desired within the scope of the hardware resources available on the data carrier 10.
  • FIG. 3 illustrates an arrangement for the technical implementation of a transmission mode change when using an interpreter working with a namespace switch, in particular a FORTH interpreter 44.
  • the distribution unit 26 is on the one hand via a direct connection 39 and on the other hand via the transport system 22 with an activation meter - Mechanism 37 connected, the interpreter 44 is connected downstream on the output side.
  • the data transmission via the transport system 22 takes place in the network protocol mode.
  • the direct data transmission from the distribution unit 26 to the activation mechanism 37 realizes the transparent mode.
  • a separate activation Signal connection 27 led to the activation mechanism 37.
  • the interpreter 44 has two namespaces 45, 46 in which applicable functions and basic routines are created.
  • the first namespace 45 contains functions and basic routines for implementing the transparent mode 39.
  • the second namespace 46 contains functions and basic routines for implementing the network protocol mode 38.
  • the respectively valid namespace is set via the activation signal connection 27.
  • the transparent mode 39 is expediently always set at the beginning of a data exchange between a terminal 100 and a data carrier 10.
  • the data stream flowing via the data carrier interface 24 is in this case passed directly from the distribution unit 26 to the interpreter 44 and processed by the latter.
  • the distribution unit 26 continuously monitors the data stream to determine whether a specific control element appears in it.
  • a defined byte sequence which has meaning in one of the transmission modes and is not provided in the other, expediently serves as the control element.
  • the distribution unit 26 changes to the second transmission mode, ie to the network protocol mode 38, and sets the data path to the server area 50.
  • the data stream is then no longer routed directly to the interpreter 44 but to the transport route 22.
  • the distribution unit 26 generates an activation signal, which it transmits to the activation mechanism 37 via the activation signal connection 27.
  • the activation mechanism In turn, mechanism 37 then prepares interpreter 44 for executing application programs from server area 50. For this purpose, the activation mechanism 37 inserts an instruction into the data stream that designates a specific network server 52.
  • the activation mechanism 37 inserts the instruction “4HTTP” into the data stream in order to call an HTTP server.
  • the functionality of such a network server 52 is described using second namespace 46.
  • the interpreter 44 sets the namespace 46 assigned to the network protocol mode 45 as the namespace to be used and blocks the other.
  • the transport system 22 which in turn consists of three protocol layers 26, 28, 30, is placed on the distribution unit 26.
  • the protocol layer sequence 26, 28, 30 is designed to enable the known TCP / IP network protocol.
  • TCP / IP is quasi-standardized by RFCs and is particularly widespread on the Internet.
  • the first layer of the transport system 22 is a protocol layer 28 for management of the transmission of data packets.
  • the transmission layer 28 is in the form of a SLIP, a PPP or an RNDIS protocol layer.
  • the transmission layer 28 there is a network layer 30 for determining the recipients or the destination addresses of data packets to be transmitted in the server area 50.
  • the network layer 30 is designed as an IP protocol layer.
  • a transport layer 32 for controlling the data flow to the server area 50 lies over the network layer 30.
  • the transport layer 32 is designed as a TCP protocol layer.
  • the transition between communication area 20 and server area 50 can be implemented as an I / O buffer.
  • the transport layer 32 provides service requests therein, which specify which application in the server area 50 is to be activated in each case.
  • the service requests are formed by port numbers, each of which designates a network server 52.
  • All layers of the transport system 22 are expediently permanently created in the memory 2 of the processor core 1 by mask programming and form a static component of the portable data carrier 10.
  • the data transmission interface 24 is designed via existing contact means or via contact means set up specifically for this purpose. For example, it uses a coil present on the data carrier 10 or works via certain contacts of a standard chip card contact field.
  • FIG. 4 illustrates the operation of the protocol stack 24 to 32 when using TCP / IP when the data carrier interface is designed as USB interface.
  • the data coming from the terminal 100 is transferred to the data carrier 10 in packets 410 of, for example, 64 bytes.
  • the packets 410 each contain sub-packets 400 'of user data 400.
  • the beginning and end of each packet 410 are each marked by a CO byte 420, ie the number 192 decimal.
  • the CO byte 420 is not assigned to any character within the ASCII code. It therefore also serves as a control element for the distribution unit 26 for setting the transmission mode.
  • the distribution unit 26 selects the network protocol transmission mode 38 accordingly for the forwarding of the data packets 410 and transfers the data packets 410 to the SLIP transmission layer 28, which packs them into a coherent data block 430. Furthermore, the distribution unit 26 sends an activation signal to the activation mechanism 37.
  • the SLIP transmission layer 28 passes the unfragmented data block 430 to the IP switching layer 30, which evaluates the IP header 440 contained in the data block 430 and determines the destination address contained therein.
  • the data block is subsequently transferred to the TCP transport layer 32, which evaluates the TCP header 450 contained in the data block 430 in order to determine the service request 420 contained therein.
  • the service request is a port number 460 in TCP / IP. It denotes a network server 52 to be used to execute the service; Widespread are, for example, the HTTP server to which port number 80 is assigned, or the FTP server with port numbers 20 and 21.
  • Port number 460 is provided at the exit of transport layer 32, from where network server 52, designated by port number 460, thus, for example, the HTTP server or the FTP server, which accesses the user data 400 contained in the data block.
  • the faulty data packet 430 is rejected.
  • the content of data packets 430 that are fundamentally meaningful is provided, for an HTTP server, for example, the instructions GET, HEAD or POST with associated variables, for example “host:”, and parameters, for example “/index/.html”.
  • the protocol layers 28, 30, 32 of the communication area 20 can be executed multiple times or in a branching manner in order to enable other or further network protocols.
  • a further transport layer can be set up approximately parallel to a first transport layer 32, which transports data for other services.
  • An example of a second transport layer is a UDP layer.
  • An integral part of the interaction area 40 is an interpreter 44. It is addressed via the data transmission interface 24 in the transparent mode 39. In transparent mode 39, ASCII data are typically transmitted to it. Other data formats also come into consideration, such as APDU commands in the field of chip cards.
  • the interpreter 44 realizes two basic functionalities. On the one hand, upon access to corresponding textual instructions, it executes application programs stored as machine code in the storage system of the data carrier 10 and thereby realizes the functionalities and applications assigned to the data carrier 10. This first basic functionality is carried out when using the network protocol mode 38.
  • the interpreter 44 also enables the reloading of new application programs on the data carrier 10.
  • the program source text to be loaded is compiled when it is loaded into native machine code and is preferably stored in the non-volatile memory field 3 of the data carrier 10.
  • the program source text to be loaded can be the source text of an application to be brought onto the data carrier 10 or the HEX - Dump a patch for an existing application program.
  • the second basic functionality is implemented in transparent mode 39.
  • the program source text supplied is in a high-level programming language. It is conveniently written in the high-level programming language FORTH.
  • the interpreter 44 is a FORTH interpreter according to ISO 15948, which is composed of an outer interpreter 42 and an inner interpreter 43.
  • Such an interpreter 44 can be implemented with a space requirement of typically 8 kB in the storage system 3, 4.
  • the outer interpreter 42 interprets textual instructions coming from the feed area 21 - for example HTTP commands in the network protocol mode or configuration instructions in the transparent mode - and checks the text for basic routines (“words”) contained therein.
  • the inner interpreter 43 runs and executes the Basic routines through the processor core 1 of the data carrier 10 by interpreting memory addresses present in binary form.
  • the inner interpreter 43 thus executes the actual execution of application programs. Parameters are passed from the outer to the inner interpreter via a stack memory (“stack”).
  • interpreter 44 can also be based on other programming environments, for example if the storage capacity of the data carrier 10 this allows on Java. Depending on the programming environment chosen, modifications to the internal structure of interpreter 44 may be necessary.
  • the functional scope of a FORTH interpreter 44 on which this is based is determined by the basic routines.
  • a basic set of elementary basic routines is permanently created in the non-volatile memory area 3 during the production of the data carrier 10 as a mask code.
  • the functional scope of the FORTH interpreter 44 can be expanded by reloading basic routines based on these elementary routines. Usually there is an extension in connection with the reloading of new application programs. When the strings are loaded, the interpreter 44 compiles new basic routines to memory addresses of elementary routines, which are then each executed by the inner interpreter 43 when an application program is executed.
  • the basic routines are organized in a number of namespaces 45, 46, one namespace 45, 46 each being assigned to a basic functionality of interpreter 44.
  • Basic functionalities of interpreter 44 are the reloading of new program codes and the execution of existing application programs.
  • the first basic functionality corresponds to the transparent mode 39, the second to the network protocol mode 38.
  • a first namespace 45 comprises basic routines assigned to the transparent mode 39. These include the commands SET-IP, NET STAT, HELP.
  • a second namespace 46 assigned to the network protocol mode 38 correspondingly comprises the commands GET, HEAD, POST.
  • the interaction area 40 further contains a configuration area 48, which is used to manage configurations and parameterizations.
  • the Configuration area 48 enables the interactive configuration of settings of communication area 20 or server area 50 in transparent mode 39. In transparent mode 39, it can be addressed directly by a terminal 100 and provides operating aids, for example input masks that implement user guidance.
  • the configuration area 48 for example, the IP address valid for the portable data carrier 10 or an application located in the server area 50 or the default gateway for unknown addresses are defined.
  • Part of the configuration area 48 is also a configuration manager 49 with which the usability of the transparent mode 39 can be set.
  • the configuration manager 49 allows the transparent mode to be restricted in such a way that only configuration instructions can be entered in the transparent mode 39, but changes to the range of functions of the interpreter 44, for example by loading new basic routines, are no longer possible.
  • the configuration manager 49 is implemented by blocking the execution of certain basic routines of the associated namespace 45. Configuration manager 49 is expediently set up after all other application programs have been loaded,
  • a basic version of the interpreter 44 with elementary routines and the configuration area 48 are expediently stored as a mask program in the non-volatile memory fields 3, 4 of the portable data carrier 10.
  • the server area 50 contains the application programs executable with the data carrier 10 and the files required for their function. At least one of the application programs implements the functionality of a network server 52.
  • the network server 52 can be an HTTP server, for example or be an FTP server. With the help of a network server 52, the data carrier 10 becomes a full network server in relation to the terminal 100. For example, the execution of an application program implementing an HTTP server by the interpreter 44 causes an HTML page or other data and a header to be output.
  • Appendix A shows an example of an application program for realizing a network server, a FORTH source text that realizes a basic network server.
  • the source text can be transmitted by means of the terrestrial program 102 in transparent mode from a terminal device 100 to a data carrier 10 and produces the network server functionality there.
  • the application program that realizes the functionality of a network server 52 is executed by the interpreter 44 if the transport system 22, after passage through the switching and transport layer, has a useful service request at the exit of the transport system 22.
  • the service request can be, for example, the request to execute an HTTP command such as GET, HEAD or POST. If there is such a service request, the interpreter 44 determines whether a program code implementing the requested service is present in the server area 50. If this is the case, it transmits a confirmation message to the transport system 22 and executes the program code found.
  • the requested service can consist, for example, in the output of an HTML file containing a text.
  • the trigger for the request can be an address requested by a user via a network navigator 150, for example the address “http://160.1.1.1/index/html”.
  • the network navigator 150 uses this to generate an http instruction that issues the HTTP command “ GET "contains, for example” GET / index.html http / 1.1 ".
  • This HTTP instruction is in the Network protocol mode 38 passed to the interpreter 44 via the transport system 22.
  • the interpreter 44 functions as an HTTP network server 52 and executes basic routines in order to deliver the requested file to the network navigator 150.
  • the network navigator 150 displays the received file in the terminal 100 via the user interface 140.
  • auxiliary application programs are connected to the network server 52, the type and number of which depend on the type of network server and the particular requirements.
  • a source code analyzer for example in the form of a
  • XML parsers 54 for example for compiling CGI scripts 66
  • a block of security configuration files 58 in which security settings for the operation of the interpreter are stored.
  • the network server 52 is assigned a file system 68 with files for recording user data, i.e. in particular files 60 with applets, files 62 with images, or files 64 with graphics to be displayed, such as HTML files.
  • Application programs and files to be stored in the server area 50 are loaded in transparent mode 39 via interpreter 44 or in network protocol mode 38 using a suitable command, for example the HTTP command POST.
  • Certain basic structures for example the structure of the file system 68, are expediently provided in the memory 4 used to set up the server area 50.
  • an HTTP server 52 in the server area 50 several network servers 52 can also be set up, which provide different services.
  • an FTP server and / or a Telnet server can also be provided, which becomes active when port 20/21 for the FTP port is located at the exit of the TCP transport layer. Server or 23 for the Telnet server is requested. Own file systems can be assigned to all network servers 52. However, as illustrated in FIG. 6, you can also access the same file system 68.
  • the grain communication area 120 of the terminal 100 forms the counterpart to the communication area 20 of a data carrier 10 and serves to carry out a data exchange with the latter. Like that, the communication area 120 of the terminal 100 has a layer structure. To data carrier 10, it has a physical interface 122 corresponding to its data transmission interface 24, in particular one
  • USB a Firewire or an Ethernet interface.
  • adaptation layer 124 which converts the data transmitted via the interfaces 122 from the format used on the interface 122 into the format required by the microcontroller 101 of the terminal 100. If, for example, the interface 122 is a USB interface, but the microcontroller 101 is only designed for processing simple serial signals, then the adaptation layer 26 forms a virtual serial interface.
  • a transport system 130 is formed above the adaptation layer 124 for forwarding to or receiving data transmitted via the data transmission interface 122 to the network navigator 150.
  • the transport system 130 as indicated in FIG. 1, comprises a SLIP or PPP layer 132, an IP layer 134 and a TCP layer 136, ie corresponding to a protocol layer sequence based on the OSI layer model the OSI layers 2, 3 and 4 in the communication area of the data carrier 10.
  • the terminal program 102 is used to establish a transparent mode data connection to a data carrier 10. It is operated via the user interface 140 and realizes the data exchange in the transparent mode 39. Using the terminal program 102, among other things, the creation of new application programs for the server area and access to configuration area 48.
  • Network navigator 150 is typically a common browser. If the data carrier 10 has a network server 52, it allows, in particular, selection and calling of a specific application from the server area 50 of the portable data carrier 10. The user navigates the network navigator 150 via the user interface 140 ,
  • a practical use of a data carrier 10 is described below with reference to FIG. 6.
  • the use shown is divided into three phases, the first phase e.g. is carried out at the manufacturer of the data carrier 10, the second phase by a user and the third phase by an end user.
  • the first phase begins by the manufacturer providing a data carrier 10, step 300.
  • the interaction region 40 and the communication region 20 with a communication device for executing at least one network protocol are created on the data carrier 10 by mask programming.
  • the applications to be applied directly by the manufacturer are also loaded, step 302 and set the associated configurations in configuration area 48, step 304.
  • the data carrier 10 is then transferred to the application provider, step 310.
  • the application provider is, in particular, an institution that operates a network of terminals 100, on which certain applications can be carried out using a data carrier 10.
  • Such an application provider can be, for example, a bank or an authority.
  • the application provider presents the data carrier 10 received from the manufacturer at the interface 122 of a suitable terminal 100 and establishes a connection to the data carrier 10 using a suitable terminal program 102, step 310.
  • the data carrier 10 initially sets the transparent mode 39 as the transmission mode, and thus a data path to the interaction area 40, step 312.
  • the application provider now loads its own applications, step 316, for example special banking or governmental applications, onto the data carrier 10, where they are loaded into the server area 50.
  • the application provider also makes adjustments in the configuration area 48 before step 320 and loads them onto the data carrier 10. For example, it may be necessary to convert a manufacturer-related IP address of the data carrier 10 that was initially created by the manufacturer into an IP address that is valid on the end devices 100 of the user. Change address. In transparent mode 39, the application provider therefore enters into a direct dialog with the configuration area 48 and sets the changed IP address by means of the terminal 100. If all intended accesses have taken place, the application provider ends the communication with the data carrier 10 by removing it from the terminal 122 on the terminal side, step 322. The data carrier 10 is now handed over to the end user.
  • the end user in turn presents the data carrier 10, step 330, for executing an application to a suitable terminal 100, for example the reader of a home computer, and establishes a connection to the data carrier 10 using a suitable communications program 102.
  • the data carrier 10 then first switches to the transparent mode 39, step 332, and offers a dialog with the interaction area 40 via the terminal 100. As a rule, changes in the design area 40 are not to be made by an end user.
  • the end user regularly initiates the execution of an application. For this purpose it changes from the to the communication structure 'program routine employed in a form suitable for access to a server located in the area 50 of the data carrier 10 application program routine, such as a conventional network browser and requests access to the' on application. The request is made using the browser's network protocol, step 334. This causes the distribution unit 26 of the data carrier 10 to change the transmission mode and to set a data path in the server area 50 to the desired application.
  • the end user then executes the intended application, step 336.
  • the end user ends access to the data carrier 10, step 338.
  • the end user changes back to the transparent mode 39 by ending the current application access by actively ending the SLIP / PPP session or by removing the data carrier 10, the data carrier 10 immediately afterwards again at the interface 122 of the terminal 100 presents, step 340, and starts communication with the data carrier again using the program routine provided for this purpose.
  • the latter first sets the transparent mode 39 again.
  • a UDP / IP protocol architecture can be set up in the communication area 20.
  • Further network servers 52 for example a TELNET server, with associated auxiliary programs and file systems can be set up in the server area 50.
  • TCP / IP itself allows a large number of variants and configurations within the framework of the associated RFCs.
  • applications with any other structures can also be created. These further applications may also require that in the communication area 20 a specially adapted further protocol layer architecture for communication with the applications is established.
  • activation mechanism and interpreter 44 can also occur in principle.
  • the functionality of the activation mechanism could be integrated into the distribution unit. Expedient modifications can also result from the aspect of security against manipulation when handling data on the portable data carrier and when exchanging data between the portable data carrier and a terminal device 100.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Telephone Function (AREA)
  • Stored Programmes (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Vorgeschlagen wird ein vorzugsweise in Gestalt einer Chipkarte ausgeführter tragbarer Datenträger (10) mit einem Interpreter (44) zum Laden und Ausführen von Anwendungsprogrammen, von denen wenigstens eines die Funktionalität eines Netzservers (52) realisiert. Das Laden von Anwendungsprogrammen und ihre Ausführung erfolgen unter Verwendung unterschiedlicher Übertragungsmodi (38, 39). Zur Einstellung des jeweils zu verwendenden Übertragungsmodus dient eine Verteileinheit (26), welche den eingehenden Datenstrom auf das Erscheinen bestimmter Steuerelemente beobachtet. Ein Übertragungsmodus (38) kann ein übliches Netzwerkprotokoll, insbesondere ein TCP/IP-Protokoll sein.

Description

Tragbarer Datenträger mit Netzserverfunktionalität
Die Erfindung geht aus von einem tragbaren Datenträger nach der Gattung des Hauptanspruchs. Ein solcher ist beispielsweise aus der EP 932 865 Bl bekannt. Darin ist eine IC-Karte beschrieben, die die Möglichkeit bietet, Applikationen zu laden, die in der Programmierhochsprache Java (s.a. http://java.sun.com) geschrieben wurden. Im Klartext in Java erstellte Applikationen werden zunächst in sogenannte „class files" compiliert, die nachfolgend einer Konvertierung unterworfen werden. Darin werden die class files in kompaktere „card class files" bzw. „card application files" bzw. „CAP-fil'es" überführt, die schließlich an die IC-Karte übertragen werden. Um auf eine IC-Karte transferierte card class files ausführen zu können, befindet sich auf der IC-Karte eine „virtuelle Maschine", d.h. ein in Softwareform nachgebildeter Prozessor. Die bekannte Lösung erlaubt die Einhaltung eines hohen Sicherheitsniveaus im Hinblick auf die Manipulation von ladbaren Applikationen. Allerdings beanspruchen bei vergleichbarem Funktionsumfang Lösungen auf Basis einer virtuellen Maschine mehr Speicherplatz als solche, die auf an den jeweiligen Einsatz angepaßten Betriebssystemen beruhen. Auf ressourcenbeschränkten Systemen wie IC-Karten hat dies zur Folge, daß der zur Aufnahme von Applikationen zur Verfügung stehende Speicherraum entsprechend reduziert wird. Für die Erstellung neuer Anwendungen für IC-Karten ist ferner die Bereitstellung von Mitteln zur Konvertierung erstellter class files Voraussetzung. Die Handhabung der Lösung ist insoweit eingeschränkt.
Aus der WO 01/60040 ist der Vorschlag bekannt, eine Chipkarte als Webserver, d.h. als Netzserver im Internet einzusetzen und die Karte mit einer Proxyfunktionalität zu versehen. Auf der Karte ist hierzu, angelehnt am OSI- Schichtenmodell, eine fünfschichtige Netzwerkstruktur eingerichtet, die eine physikalischen Übertragungsschicht, eine Datenübertragungsschicht, eine Vermittlungsschicht, eine Transportschicht sowie eine Anwendungsschicht umfaßt. Die Anwendungsschieht beinhaltet neben verschiedenen Applikationen Dienstprogramme, die zum einen die Funktionalität eines Web- Servers, zum anderen die Funktionalität eines Proxyservers realisieren. Die physikalische Übertragungsschicht und die Datenübertragungsschicht ent- sprechen den gängigen Chipkartennormen und unterstützen übliche Kartenbefehle, so daß die Karte in bekannter Weise angesprochen werden kann. Die vorgeschlagene Karte ermöglicht eine sichere Handhabung von Daten, die zwischen einem Terminal und einem Netzserver ausgetauscht werden. Die Schrift macht keine Angaben dazu, wie eine Applikation in die Karte geladen werden kann.
Aus der WO 01/60881 ist der Vorschlag bekannt, eine IC-Karte mit einer Standardschnittstelle zur Durchführung eines standardisierten Protokolls gemäß ISO-Norm mit einer Funktionalität zur Ausführung eines weiteren ProtokoUes, insbesondere eines USB-Protokolles, zu versehen. Auf der Karte befindet sich hierzu eine Umsetzungseinrichtung, die Kommandos gemä . dem standardisierten Kartenprotokoll in Kommandos gemäß dem zweiten Protokoll umsetzt. Zur Steuerung der Umsetzungseinrichtung durch ein Terminal ist die Karte zur Ausführung eines Satzes von speziellen Kom- mandos eingerichtet.
Aus dem „Handbuch der Chipkarten", W. Rankl, W. Effing, 2002, 4. Auflage, ist der physikalische Aufbau von Chipkarten, besonders die Beschaffenheit des Kartenmikrocontrollers, und ihren Schnittstellen zur Außenwelt ent- nehmbar. Beschrieben werden weiter Kartenbetriebssysteme, die das Nachladen von Programmcode auf eine Chipkarte erlauben. Hierbei wird auf die Möglichkeit eingegangen, auf Chipkarten einen vollständigen Interpreter vorzusehen, der zugeführten Programmcode auf der Karte interpretiert. Die Variante wird aber aus Gründen der Arbeitsgeschwindigkeit und des Spei- cherplatzbedarfes für einen solchen Interpreter als ungünstig eingestuft. Beschrieben wird in dem Buch ferner das Konzept der Multifunktionskarte.
Zur Realisierung einer Multiapplikationskarte ist weiter ein Betriebssystem bekannt („OSSCA": Operating System for Smart Cards, Prospekt der Firma KEYCORP Ltd., März 1999, abrufbar unter http://keycorp.net/smartcard/ ossca.pdf), welches zur Ausführung von in einer Variante der Prograrnrnier- hochsprache FORTH geschriebenen Anwendungsprogrammen eingerichtet ist und das Nachladen solcher Anwendungsprogramme erlaubt. Das Be- triebss stem erlaubt eine simultane Ausführung von bis zu vier Anwendungen. Die Kommunikation zwischen Chipkarte und Terminal erfolgt allerdings gemäß einem üblichen, standardisierten Chipkartenprotokoll über eine Standard-Chipkartenschnittstelle. Eine Kommunikation mit der Chipkarte setzt entsprechend spezielle, geeignete Terminals voraus.
Eine Beschreibung der wichtigsten Prinzipien der Programmiersprache FORTH gibt unter anderem der Artikel „The Forth Approach to Operating Systems" von E.D. Rather , C.H.Moore, 1976, Proceedings of the ACM, S. 233 bis 240.
Aufgabe der Erfindung ist es, einen tragbaren Datenträger anzugeben, der geeignet ist, als Netzserver eingesetzt zu werden und dabei für diese Nutzung möglichst geringe Anforderungen an die Nutzungsumgebung stellt.
Die Aufgabe wird gelöst durch einen tragbaren Datenträger mit den Merkmalen des Hauptanspruchs. Grundlage für den erfindungsgemäßen tragbaren Datenträger bildet der Ansatz, Elemente, die nur dazu dienen, den Datenträger zur Verwendung in speziell auf tragbare Datenträger zugeschnittenen Anwendungen einzurichten, zunächst gar nicht erst vorzusehen. Er- findungsgemäße tragbare Datenträger verfügen nur über eine aus dem Bereich der Computertechnik übernommene Standardschnittstelle sowie Mittel zur Durchführung zweier verschiedener Ubertragungsmodi, wobei ein erster Ubertragungsmodus zum Einrichten von Anwendungen dient, während der andere zur Nutzung der Anwendungen unter Verwendung eines bekannten Netzwerkprotokolles dient. Wesentliches Element dieser Mittel ist eine Verteileinheit, die die Einstellung des jeweils zu verwendenden Ubertragungsmodus vornirrimt.
Der erfindungsgemäße Datenträger hat den Vorteil, daß Anwendungen mittels eines üblichen Netzwerkrotokolls angesprochen werden können, das nicht datenträgerspezifisch ist und das zur Kommunikation zwischen über ein Netz verbundenen Teilnehmern verbreitet ist. Insbesondere kann es sich bei dem Netzwerkprotokoll um ein übliches TCP/IP-Protokoll handeln. Der Datenträger läßt sich hiermit in jeder TCP/IP-Umgebung einsetzen. Insbesondere eignet sich ein mit TCP/IP ausgestatteter Datenträger zur Verwendung in einem lokalen Netzwerk („LAN"), das über einen Adreßübersetzer mit dem Internet verbunden sei kann. Der Datenträger verhält sich dann wie ein regulärer Internet-Teilnehmer.
Ein weiterer besonderer Vorteil des erfindungsgemäßen Datenträgers besteht darin, daß Programme zur Realisierung neuer Anwendungen ohne Vorverarbeitung in einem Hochsprachenformat auf einen tragbaren Datenträger geladen werden können. Besonders geeignet zur Programmerstellung ist die Hochsprache FORTH.
Die auf einen tragbaren Datenträger gebrachten Anwendungen umfassen vorteilhaft einen kartenresidenten Netzserver, mittels dessen in den Anwendungen navigiert werden kann. Der Netzserver kann dabei insbesondere ein Webserver zur Anwendung im Internet sein.
Ohne weiteres können auf einem tragbaren Datenträger auch mehrere Netzserver zur Bearbeitung von unterschiedlichen Diensteanforderungen einge- richtet sein. Beispielsweise kann ein erster Netzserver eine HTTP-Server, ein zweiter Netzserver ein FTP-Server sein.
Die für einen erfindungsgemäßen Datenträger vorgesehene Struktur ermöglicht es, Datenträger bei der Herstellung zunächst nur mit einem Interpreter auszurüsten, jedoch noch keine Anwendungen aufzubringen. Dies kann durch die Abnehmer der Datenträger erfolgen.
Ein großer Vorteil ergibt sich weiter aus der vielfältigen Anwendbarkeit des erfindungsgemäßen Datenträgers, da er bei der Kommunikation zur Aus- senwelt hin auf datenträgerspezifische Lösungen verzichtet und wie ein frei konfigurierbarer Netzteilnehmer betreibbar ist.
Unter Bezugnahme auf die Zeichnung wird ein Ausführungsbeispiel der Erfindung nachfolgend näher erläutert.
Es zeigen:
Fig. 1 den grundlegenden Aufbau eines tragbaren Datenträgers,
Fig. 2 die Strukturen eines tragbaren Datenträgers mit Netzserver- Funktionalität sowie eines mit dem tragbaren Datenträger zusammenwirkenden Endgerätes,
Fig. 3 die Realisierung zweier Datenpfade über eine Verteileinheit, Fig. 4 die Funktionsweise einer Protokollstapelstruktur,
Fig. 5 eine Anordnung mehrerer Netzserver auf einem tragbaren Datenträ- ger,
Fig. 6 eine praktische Anwendung eines Datenträgers.
Im folgenden wird eine Reihe üblicher Abkürzungen und Fachbegrüf e ver- wendet, die vorab kurz erläutert werden; ausführlichere Erläuterungen finden sich unter anderem im „Computer-Lexikon", Deutscher Taschenbuchverlag, 4. Auflage, 2002, im „Lexikon der Datenkommunikation", Klaus Li- pinski, 4. Auflage, Verlag Thomson Publishing, 1996, oder in dem genannten „Handbuch der Chipkarten" sowie im Internet unter der Adresse „www.protocols.com/pbook/tcpip.htm".
USB: Universal Serial Bus.
Vereinheitlichte Schnittstelle für langsame und mittelschnelle Geräte.
Protokoll: Softwarekomponente, die bei einer Datenübertragung die Ver- mittlerrolle zwischen einer sendenden und einer empfangenden Instanz spielt.
SLIP: Seriel Line Internet Working Protocol.
Protokoll zur Übertragung von Datenpaketen über eine serielle Verbindung. PPP: Point to Point Protocol.
Serielles Protokoll zur Datenübertragung in Punkt-zu-Punkt- Verbindungen.
TCP: Transmission Control Protocol.
Protokoll zur Steuerung der Verbindungen zwischen Teilnehmern ei- nes Netzwerk. IP: Internet Working Protocol.
Protokoll zur Ermittlung der Netzadresse eines Netzwerkteilnehmers. UDP: User Datagramm Protocol. Besonders einfaches Protokoll ohne Overhead.
HTTP Hypertext Transfer Protocol.
Protokoll zur Übertragung von graphischen Informationselementen und Dateien. DHCP: Dynamic Host Contention Protocoll Automatische Adressenvergabe im Netz unter Windows.
CGI: Common Gateway Interface.
Protokoll zur Kopplung eines Web-Servers mit externen Programmen. HTML:Hypertext Markup Language.
Sprache zur Beschreibung von graphischen Informationen. XML: Extensible Markup Language.
Gegenüber HTML erweiterte Sprache zur Beschreibung von graphischen Informationen. OSI-Schichtenmodell: Open System Interconnection- Schichtenmodell.
Standardbeschreibung für die Architektur eines Netzwerkes. ASCII-Code: Zuordnungsregel, die einem definierten alphanumerischen
Zeichensatz binäre Zeichen zuordnet. RFC: Request for Comments
Dokumente zu Internet Standards. FORTH: Prograrrrmierhochsprache, in die sich besonders an den technischen Anforderungen der üblichen Prozessorkernstruktur orientiert, siehe auch ISO 15148. DFÜ: Datenfernübertragung, z.B. über Telefonleitung via Modem /ISDN- Adapter mittels KommLunikationsprogra rmes Stellvertretend für einen tragbaren Datenträger 10 wird nachfolgend eine Chipkarte zugrundegelegt. Die vorgeschlagene Lösung ist aber nicht auf diese Ausführungsform beschränkt sondern läßt sich mit gleichen Vorteilen auch auf in anderer Gestalt ausgebildete Datenträger 10 mit beschränktem Hard- und Softwarewareumfang übertragen. Beispiele für andere ressourcenbeschränkte Datenträgergestaltungen sind etwa die Integration eines Micrcontrollers in einen Schreibstift oder in Bekleidungsstücke.
Fig. 1 veranschaulicht den grundsätzlichen Aufbau einer Chipkarte 10, die als Multifunktionskarte zur Verwendung in unterschiedlichen Anwendungen geeignet ist und die im Rahmen einer Hochsprachenprogrammierum- gebung mit neuen Anwendungsprogrammen ladbar ist. Wesentliches Element der Chipkarte 10 ist ein integrierter Schaltkreis 1 in Gestalt eines Mi- krocontrollers, der auf einem einzelnen Halbleiterchip einen Prozessorkern 2 sowie ein Speichersystem mit drei Speicherfeldern 3, 4 und 5 aufweist. Der Mikrocontroller 1 ist weiter mit einer Datenträgerschnittstelle 24 zum Austausch von Daten mit einem externen Endgerät 100 verbunden.
Von den Speicherfeldern 3, 4, 5 ist das erste 3 typischerweise ein maskenpro- grarnmierter Festwertspeicher in Gestalt eines ROMs, das zweite ein elektrisch löschbarer und beschreibbarer Festwertspeicher in Gestalt eines EE- PROMs oder eines FLASH-Speichers, das dritte ein flüchtiger Schreib/ Lesespeicher, in der Regel in Gestalt eines RAMs.
Das erste Speicherfeld 3 enthält den Programmcode des Betriebssystems der Chipkarte 10. Desweiteren kann im ersten Speicherfeld 3 der Programmcode grundlegender Anwendungsprogramme abgelegt sein, die auf allen Chipkarten 10 vorhanden sein sollen. Der gesamte im ersten Speicherfeld 3 abgelegte Programmcode wird bei der Herstellung der Chipkarte 10 mittels einer Maske als Maschinencode fest auf die Karte gebracht.
Das zweite Speicherfeld 4 dient zur Aufnahme des Codes von nachträglich auf eine Chipkarte 10 gebrachten Anwendungsprogrammen. Zudem dient es in der Regel auch als Arbeitsspeicher.
Das dritte Speicherfeld 5 dient in bekannter Weise als schneller Arbeitsspeicher.
Die Schnittstelle 24 kann vom kontaktbehafteten Typ und insbesondere als übliches Chipkartenkontaktfeld ausgeführt sein. Alternativ kann die Schnittstelle 24 vom kontaktlosen Typ sein und beispielsweise die Gestalt einer Spule besitzen, welche eine Antenne bildet.
Der gesamte Aufbau der in Fig.l gezeigten Chipkarte ist an sich bekannt und unter anderem in dem genannten „Handbuch der Chipkarten" beschrieben.
Wesentliche Komponente des Endgerätes 100 ist ein Controller 101 mit allen Elementen und der grundsätzlichen Funktionalität eines üblichen Compu- ters. Der Controller 101 stellt insbesondere einen Netznavigator 150 bereit, d.h. ein Anwendungsprogramm zur Durchführung von Zugriffen auf Dateninhalte, die in einer Netzstruktur wie dem Internet abgelegt sind. Weiter ist der Controller 101 dazu eingerichtet, ein Terminalprogramm 102 zur Ausführung zu bringen, das es über eine geeignete Schnittstelle, z.B. eine serielle RS 232-Schnittstelle gestattet, durch Datenaustausch in Kommunikation mit einem tragbaren Datenträger 10 zu treten. Zur Durchführung des Datenaustausches besitzt das Endgerät 100 eine zu der Datenübertragungsschnittstelle 24 korrespondierende Schnittstelle 122. Zu der Schnittstelle 122 ist auf dem Endgerät 100 weiterhin eine Software installiert, welche die Schnittstelle 122 an die auf dem Endgerät 100 befindlichen Applikationen, insbesondere das Terminalprogramm 102,den Netznavigator 150 oder ein DFÜ-Netzwerk mit SLIP/PPP anpaßt. Beispielsweise stellt diese Software die Schnittstelle 122 als serielle Schnittstelle, z.B. als RS 232-Schnittstelle bereit.
Zweckmäßig bietet das Endgerät 100 weiter eine Programmierumgebung an, mittels derer es in Verbindung mit einem tragbaren Datenträger 10 möglich ist, neue Anwendungsprogramme für den tragbaren Datenträger 10 zu erstellen.
Teil des Endgerätes 100 ist weiterhin eine Nutzerschnittstelle 140, die Mittel 142 aufweist, um einem Nutzer Informationen des Endgerätes 100 zur Darstellung zu bringen; typischerweise haben diese Mittel 142 die Gestalt eines Bildschirmes. Weiter besitzt die Nutzerschnittstelle 140 Mittel 144, typi- scherweise in Gestalt einer Tatstatur, um einem Nutzer die Eingabe von Befehlen an das Terminalprogramm 102 zu ermöglichen.
Das Endgerät 100 kann ein im Zugriff eines einzelnen Nutzers stehende Einzelanordnung sein, etwa ein entsprechend eingerichteter üblicher Computer, aber auch z.B. ein Terminal, das einer Vielzahl von Nutzern zur Verfügung steht und beispielsweise Teil einer auf einem Netzwerk eingerichteten Anwendungslösung ist.
Über das Terminalprogramm 102 und den Netznavigator 150 erlaubt das Endgerät 100 unter Steuerung durch einen Nutzer Aktivierung und Nutzung einer auf einem tragbaren Datenträger 10 verfügbaren Funktionalität. Terminalprogramm 102 und Netznavigator 150 stellen die hierzu notwendigen Programmroutinen zur Verfügung. Beispielsweise bieten sie eine Programmroutine zur Aufnahme einer Kommunikation über die serielle Schnittstelle 122 oder ein Modem an. Das Terminalprogramm 102 ermöglicht weiterhin das Einbringen neuer Anwendungsprogramme auf einen tragbaren Datenträger 10.
Fig. 2 veranschaulicht die grundlegende logische Struktur der in Fig.l dargestellten Anordnung. Der rechte Teil der Fig. 2 zeigt dabei die Struktur des, nachfolgend nur noch Datenträger genannten, tragbaren Datenträgers 10, der linke Teil die Struktur eines Endgerätes 100.
Der Datenträger 10 gliedert sich in einen Kommunikationsbereich 20, einen Interaktionsbereich 40 sowie einen Serverbereich 50.
Das Endgerät 100 beinhaltet einen Kommunikationsbereich 120, eine Nutzerschnittstelle 140, eine Terminalprogramm 102 sowie einen Netznavigator 150.
Der Kommunikationsbereich 20 des Datenträgers 10 beinhaltet Mittel zur Durchführung eines Datenaustausches zwischen dem Datenträger 10 und einem externen Endgerät 100. Teil dieser Mittel ist insbesondere eine Vertei- leinheit 26, die in Abhängigkeit von von dem Endgerät 100 erhaltenen Daten einen Datenpfad zum Interaktionsbereich 40 oder zum Serverbereich 50 einrichtet und einen entsprechenden Ubertragungsmodus einstellt.
Im Interaktionsbereich 40 sowie im Serverbereich 50 befinden .sich in Form von Anwendungsprogrammen mit dem Datenträger 10 ausführbare Anwendungen und Funktionalitäten.
Den im Serverbereich 50 liegenden Anwendungsprogrammen werden unter Verwendung eines standardisierten Netzwerkprotokolles über die Datenträ- gerschnittstelle 24 eingehende Daten zugeführt. Der Datenpfad zwischen der Datenträgerschnittstelle 24 und dem Serverbereich 50 besitzt dazu eine an das OSI-Schichtenmodell angelehnte Architektur in Gestalt eines Protokollstapels. Bei dem standardisierten Netz Werkprotokoll handelt es sich insbe- sondere um das „TCP/IP" -Protokoll.
Der Interaktionsbereich 40 beinhaltet einen Interpreter 44 zur Einrichtung von Anwendungsprogrammen im Serverbereich 50 sowie zur Ausführung der Anwendungsprogramme. Weiter beinhaltet der Interaktionsbereich 40 einen Konfigurationsbereich 48 zur Aufnahme von Parametrisierungen und Einstellungen für den Interpreter 44 und den Serverbereich 50. Der Datenpfad in den Interaktionsbereich 40 ist als Transparentmodus 39 realisiert, in dem die über die Verteileinheit 26 eingehenden Daten unverändert weitergeleitet werden.
Der Kommunikationsbereich 20 des Datenträgers 10 besitzt eine aus mehreren übereinanderliegenden Protokollschichten aufgebaute Protokollstapelstruktur, die von ein- und ausgehenden Daten nacheinander durchlaufen wird. Jede Protokollschicht realisiert dabei definierte Dienste, in denen sie die ihr zugeführten Daten jeweils festgelegten Bearbeitungen unterwirft. Dabei baut sie jeweils auf den Diensten der darunterliegenden Schicht auf und bietet ihrerseits der darüberliegenden Schicht ihre Dienstleistungen an. Die Dienste sind im Rahmen von Protokollen definiert.
Grundelemente der Protokollstapelstruktur sind ein Zuführungsbereich 21 sowie ein Transportsystem 22.
Erste Komponente des Zuführungsbereichs 21 ist eine Übergabeschicht mit der Datenübertragungsschnittstelle 24 zur physischen Übergabe und Entge- gennahme von Daten an bzw. von einer korrespondierenden Schnittstelle 122 eines Endgerätes 100. Die Datenübertragungsschnittstelle 24 kann insbesondere als USB- als Firewire oder als Ethernet-Schnirtstelle ausgebildet sein.
Der Datenübertragungsschnittstelle 24 zugeordnet ist, als zweite Komponente des Zuführungsbereiches 21, eine Verteileinheit 26. Sie legt in Abhängigkeit von den über die Datenträgerschnittstelle 24 empfangenen Daten einen Datenpfad fest, auf dem die Daten weitergeleitet werden und stellt den für die Datenübertragung anzuwendenden Ubertragungsmodus ein. In Fig. 2 weist ein erster Datenpfad in den Interaktionsbereich 40, ein zweiter Datenpfad in den Serverbereich 50. Im ersten Fall erfolgt die Datenübertragung im Transparentmodus 39. Im zweiten Falls erfolgt die Datenübertragung in einem Netzprotokollmodus 38unter Verwendung eines Netzwerkprotokolles. Der eingestellte Datenpfad zeigt in letzterem Fall zu der auf der Datenüber- tragungsschnittstelle 24 aufbauenden ersten Schicht 28 des Transportsystems 22. Die Zahl der Datenpfade ist nicht auf zwei beschränkt sondern kann im Rahmen der auf dem Datenträger 10 zu Verfügung stehenden Hardwareressourcen beliebig erhöht werden.
Fig. 3 veranschaulicht eine Anordnung zur technischen Realisierung eines Übertragungsmoduswechsels bei Verwendung eines mit Namensraumum- schaltung arbeitenden Interpreters, insbesondere eines FORTH-Interpreters 44. Die Verteileinheit 26 ist dabei zum einen über eine direkte Verbindung 39, zum anderen über das Transportsystem 22 mit einem Aktivierungsme- chanismus 37 verbunden, dem ausgangsseitig der Interpreter 44 nachgeschaltet ist. Die Datenübertragung über das Transportsystem 22 erfolgt dabei im Netzprotokollmodus. Die direkte Datenübertragung von der Verteileinheit 26 zum Aktivierungsmechanismuns 37 realisiert den Transparentmodus. Desweiteren ist von der Verteileinheit 26 eine separate Aktivierungs- Signalverbindung 27 zu dem Aktivierungsmechanismus 37 geführt.
Der Interpreter 44 verfügt über zwei Namensräume 45, 46 in denen jeweils anwendbare Funktionen und Grundroutinen angelegt sind. Der erste Namensraum 45 enthält dabei Funktionen und Grundroutinen zur Realisierung des Transparentmodus 39. Im zweiten Namensraum 46 liegen Funktionen und Grundroutinen zur Realisierung des Netzprotokollmodus 38. Über die Aktivierungssignalverbindung 27 wird der jeweils gültige Namensraum eingestellt.
Zweckmäßig ist zu Beginn eines Datenaustausches zwischen einem Terminal 100 und einem Datenträger 10 stets der Transparentmodus 39 eingestellt. Der über die Datenträgerschnittstelle 24 fließende Datenstrom wird hierbei von der Verteileinheit 26 direkt zu dem Interpreter 44 geleitet und von die- sem bearbeitet.
Für den Wechsel des Ubertragungsmodus beobachtet die Verteileinheit 26 den Datenstrom kontinuierlich darauf, ob darin ein bestimmtes Steuerelement erscheint. Als Steuerelement dient zweckmäßig eine definierte Bytefol- ge, die in einem der Ubertragungsmodi eine Bedeutung hat, im anderen nicht vorgesehen ist.
Erscheint im beobachteten Datenstrom ein zuvor bestimmtes Steuerelement, wechselt die Verteileinheit 26 in den zweiten Ubertragungsmodus, d.h. in den Netzprotokollmodus 38 und stellt den Datenpfad zum Serverbereich 50 ein. Der Datenstrom wird darauf nicht mehr direkt zum Interpreter 44 sondern zu der Transportstrecke 22 geleitet. Zugleich erzeugt die Verteileinheit 26 ein Aktivierungssignal, das sie über die Aktivierungssignalverbindung 27 an den Aktivierungsmechanismus 37 übermittelt. Der Aktivierungsmecha- nismus 37 schaltet hierauf seinerseits den Interpreter 44 zur Ausführung von Anwendungsprogrammen aus dem Serverbereich 50 bereit. Hierzu fügt der Aktivierungsmechanismus 37 in den Datenstrom eine Anweisung ein, die einen bestimmten Netzserver 52 bezeichnet. Bezeichnet das von der Vertei- leinheit 26 erkannte Steuerelement etwa Daten im SLIP/PPP-Format, fügt der Aktivierungsmechanismuns 37 die Anweisung „4HTTP" in den Datenstrom ein, um einen HTTP-Server aufzurufen. Die Funktionalität eines solchen Netzservers 52 wird unter Verwendung des zweiten Namensraumes 46 hergestellt. Bei Erhalt der eingefügten Anweisung stellt der Interpreter 44 daher als zu nutzenden Namensraum den dem Netzprotokollmodus 45 zugeordneten Namensraum 46 ein und sperrt den anderen.
Zweckmäßig ist vorgesehen, daß während einer Kommunikation zwischen Datenträger 10. und Terminal 100 ein Übertragungsmo^duswechsel nur vom Transparentmodus 39 in den. Netzprotokollmodus 38 möglich ist. Ein Wechsel in umgekehrter Richtung erfordert hingegen jeweils eine erneute Präsentation des Datenträgers 10 an dem Endgerät 100. Grundsätzlich kann aber selbstverständlich auch vorgesehen sein, daß mittels geeigneter Befehle oder Steuerelemente jederzeit ein Wechsel des Ubertragungsmodus in beide Rich- tungen möglich und daß zu Beginn einer Kommunikation der zuletzt eingestellte Ubertragungsmodus eingestellt ist.
Auf die Verteileinheit 26 setzt das Transportsystem 22 auf, das seinerseits aus drei Protokollschichten 26, 28, 30 besteht. Die Protokollschichtfolge 26, 28, 30 ist dazu ausgelegt, das bekannte TCP/IP-Netzwerkprotokoll zu ermöglichen. TCP/IP ist durch RFCs quasistandardisiert und insbesondere im Internet verbreitet.
Erste Schicht des Transportsystems 22 ist eine Protokollschicht 28 zur Durch- f ührung der Übertragung von Datenpaketen. Die Übertragungsschicht 28 ist als SLIP- als PPP- oder als RNDIS-Protokollschicht ausgeführt.
Auf der Übertragungsschicht 28 liegt eine Vermittlungsschicht 30 zur Er- mittlung der Empfänger bzw. der Zieladressen von zu übertragenden Datenpaketen im Serverbereich 50. Die Vermittlungsschicht 30 ist als IP- Protokollschicht ausgeführt.
Über der Vermittlungsschicht liegt 30 eine Transportschicht 32 zur Steue- rung des Datenflusses zum Serverbereich 50. Die Transportschicht 32 ist als TCP-Protokollschicht ausgeführt.
Der Übergang zwischen Kommunikationsbereich 20 und Serverbereich 50 kann als I/O-Buffer ausgeführt sein. Darein werden von der Transport- schicht 32 Dienstanf orderungen bereitgestellt, die angeben, welche Anwendung im Serverbereich 50 jeweils aktiviert werden soll. In TCP/IP werden die Dienstanforderungen durch Portnummern gebildet, die jeweils einen Netzserver 52 bezeichnen.
Alle Schichten des Transportsystems 22 werden zweckmäßig durch Mas- kenprogrammierung fest im Speicher 2 des Prozessorkerns 1 angelegt und bilden einen statischen Bestandteil des tragbaren Datenträgers 10. Die Datenübertragungsschnittstelle 24 ist über vorhandene oder über eigens zu diesem Zweck eingerichtete Kontaktmittel ausgebildet. Beispielsweise nutzt sie eine auf dem Datenträger 10 vorhandene Spule oder arbeitet über bestimmte Kontakte eines Standardchipkartenkontaktfeldes.
Fig. 4 veranschaulicht die Arbeitsweise des Protokollstapels 24 bis 32 bei Verwendung von TCP/IP bei Ausbildung der Datenträgerschnittstelle als USB-Schnittstelle. Die von dem Endgerät 100 kommenden Daten werden dem Datenträger 10 hierbei in Paketen 410 von z.B. 64 Byte übergeben. Die Pakete 410 enthalten jeweils Teilpakete 400' von Nutzdaten 400. Anfang und Ende jedes Pakets 410 werden jeweils durch ein CO-Byte 420 d.h. die Zahl 192 dezimal, markiert.
Das CO-Byte 420 ist im Rahmen des ASCII-Codes keinem Zeichen zugeordnet. Es dient deshalb zugleich als Steuerelement für die Verteileinheit 26 zur Einstellung des Ubertragungsmodus. Bei Erkennen des ersten CO-Bytes wählt die Verteileinheit 26 entsprechend für die Weiterleitung der Datenpa- kete 410 den Netzprotokollübertragungsmodus 38 und übergibt die Datenpakete 410 der SLIP-Übertragungsschicht 28, welche sie zu einem zusammenhängenden Datenblock 430 packt. Desweiteren sendet die Verteileinheit 26 ein Aktivierungssignal an den Aktivierungsmechaηismus 37.
Den unfragmentierten Datenblock 430 reicht die SLIP-Übertragungsschicht 28 weiter an die IP-Vermittlungsschicht 30, die den in dem Datenblock 430 enthaltenen IP-Header 440 auswertet und die darin enthaltenen Zieladresse ermittelt. Nachfolgend wird der Dateriblock an die TCP-Transportschicht 32 übergeben, welche den in dem Datenblock 430 enthaltenen TCP-Header 450 auswertet, um die darin enthaltene Diensteanforderung 420 zu ermitteln. Die Diensteanforderung ist in TCP/IP eine Portnummer 460. Sie bezeichnet einen zur Ausführung des Dienstes zu nutzenden Netzserver 52; verbreitet sind etwa der HTTP-Server, dem die Portnummer 80 zugeordnet ist, oder der FTP-Server mit der Portnummer 20 bzw. 21. Die Portnummer 460 wird am Ausgang der Transportschicht 32 bereitgestellt, von wo der durch die Portnummer 460 bezeichnete Netzserver 52, also etwa der HTTP-Server oder der FTP-Server, auf die in dem Datenblock enthaltenen Nutzdaten 400 zugreift. Beim Durchlauf der Datenpakete 410 durch den Protokollstapel wer- den fehlerhafte Datenpakete 430 abgewiesen. Am Ausgang der Transportschicht bereitgestellt wird nur der Inhalt grundsätzlich sinnvoller Datenpakete 430, für einen HTTP-Server etwa die Anweisungen GET, HEAD oder POST mit zugehörigen Variablen, z.B. „host:", und Parametern, z.B. „/index/.html".
Abhängig von den Anwendungen, die mittels des Datenträgers 10 ausgeführt werden sollen, können die Protokollschichten 28, 30, 32 des Kommunikationsbereiches 20 mehrfach oder in verzweigender Form ausgeführt sein, um andere oder weitere Netzwerkprotokolle zu ermöglichen. Auf der Vermittlungsschicht 28, 30 kann etwa parallel zu einer ersten Transportschicht 32 eine weitere Transportschicht eingerichtet sein, die Daten für andere Dienste transportiert. Ein Beispiel für eine zweite Transportschicht ist eine UDP-Schicht.
Wesentlicher Bestandteil des Interaktionsbereichs 40 ist ein Interpreter 44. Er wird über die Datenübertragungsschnittstelle 24 im Transparentmodus 39 angesprochen. Im Transparentmodus 39 werden ihm typischerweise ASCII- Daten übertragen. Daneben kommen auch andere Datenformate in Betracht, im Bereich der Chipkarten etwa APDU-Kommandos.
Der Interpreter 44 realisiert zwei Grundfunktionalitäten. Zum einen bringt er auf Zugang entsprechender textueller Anweisungen als Maschinencode im Speichersystem des Datenträgers 10 abgelegte Anwendungsprogramme zur Ausführung und realisiert dadurch dem Datenträger 10 zugeordnete Funktionalitäten und Anwendungen. Diese erste Grundfunktionalität wird bei Verwendung des Netzprotokollmodus 38 ausgeführt.
Weiterhin ermöglicht der Interpreter 44 das Nachladen neuer Anwendungs- programme auf den Datenträger 10. Nachzuladenden Programmquelltext compiliert er beim Laden zu nativem Maschinencode und speichert ihn vorzugsweise im nichtflüchtigen Speicherfeld 3 des Datenträgers 10. Bei dem nachzuladenden Programmquelltext kann es sich um den Quelltext einer auf den Datenträger 10 zu bringenden Anwendung oder etwa um den HEX- Dump eines Patches zu einem bereits vorhandenen Anwendungsprogramm handeln. Die zweite Grundfunktionalität kommt im Transparentmodus 39 zur Ausführung.
Der zugeführte Programmquelltext liegt in einer Programmierhochsprache vor. Zweckmäßig ist er in der Programmierhochsprache FORTH abgefaßt.
In bevorzugter Ausführung ist der Interpreter 44 entsprechend ISO 15948 ein FORTH-Interpreter, der aus einem äußeren Interpreter 42 sowie einem inne- ren Interpreter 43 aufgebaut ist. Ein derartiger Interpreter 44 läßt sich bei einem Platzbedarf von typischerweise 8 kB im Speichersystem 3,4 realisieren.. Der äußere Interpreter 42 interpretiert dabei vom Zuführungsbereich 21 kommende textuelle Anweisungen - etwa HTTP-Kommandos im Netzprotokollmodus oder Konfigurationsanweisungen im Transparentmodus - und prüft den Text auf darin enthaltene Grundroutinen („words"). Dabei läuft der innere Interpreter 43 ab und bewirkt die Ausführung der Grundroutinen durch den Prozessorkern 1 des Datenträgers 10, indem er in Binärform vorliegende Speicheradressen interpretiert. Der innere Interpreter 43 bewirkt damit die eigentliche Ausführung von Anwendungsprogrammen. Parameter werden vom äußeren an den inneren Interpreter über einen Stapelspeicher („Stack") übergeben.
Neben FORTH kann der Interpreter 44 auch auf anderen Programmierumgebungen basieren, z.B., wenn die Speicherkapazität des Datenträgers 10 dies erlaubt, auf Java. Entsprechend der gewählten Programmierumgebung können Modifikationen der inneren Struktur des Interpreters 44 notwendig werden.
Der Funktionsumfang eines hier zugrundegelegten FORTH-Interpreters 44 wird durch die Grundroutinen bestimmt. Eine Grundausstattung an elementaren Grundroutinen wird bei der Herstellung des Datenträgers 10 als Maskencode fest im nichtfüchtigen Speicherbereich 3 angelegt. Durch Nachladen von auf diesen Elementarroutinen basierenden Grundroutinen kann der Funktionsumfang des FORTH-Interpreters 44 erweitert werden. Üblicherweise erfolgt eine Erweiterung im Zusammenhang mit dem Nachladen neuer Anwendungsprogramme. Neue Grundroutinen compiliert der Interpreter 44 beim Laden der Zeichenfolgen zu Speicheradressen von Elementarroutinen, die anschließend bei der Ausführung eines Anwendungsprogrammes jeweils vom inneren Interpreter 43 ausgeführt werden.
Die Grundroutinen sind in mehreren Namensräumen 45, 46 organisiert, wobei jeweils ein Namensraum 45, 46 einer Grundfunktionalität des Interpreters 44 zugeordnet ist. Grundfunktionalitäten des Interpreters 44 sind das Nachladen neuen Programmcodes sowie Ausführen vorhandener Anwendungsprogramme. Der ersten Grundfunktionalität entspricht der Transparentmodus 39, der zweiten der Netzprotokollmodus 38. Ein erster Namensraum 45 umfaßt entsprechend dem Transparentmodus 39 zugeordnete Grundroutinen. Dazu zählen u.a. die Kommandos SET-IP, NET STAT, HELP. Ein zweiter, dem Netzprotokollmodus 38 zugeordneter Namensraum 46 umfaßt entsprechend etwa die Kommandos GET, HEAD, POST.
Der Interaktionsbereich 40 enthält weiterhin einen Konfigurationsbereich 48, der zur Verwaltung von Konfigurationen und Parametrisierungen dient. Der Konfigurationsbereich 48 ermöglicht im Transparentmodus 39 die interaktive Konfiguration von Einstellungen des Kommunikationsbereiches 20 oder des Serverbereiches 50. Er kann im Transparentmodus 39 direkt durch ein Endgerät 100 angesprochen werden und stellt hierbei Bedienungshilfen zur Verfügung, z.B. Eingabemasken, die eine Nutzerführung realisieren. Im Konfigurationsbereich 48 festgelegt werden beispielsweise die für den tragbaren Datenträger 10 oder eine im Serverbereich 50 liegende Anwendung geltende IP- Adresse oder der Default-Gateway für unbekannte Adressen.
Teil des Konfigurationsbereiches 48 ist ferner ein Konfigurationsmanager 49, mit dem die Nutzbarkeit des Transparentmodus 39 einstellbar ist. Beispielsweise erlaubt der Konfigurationsmanager 49 eine Beschränkung des Transparentmodus derart, daß im Transparentmodus 39 nur noch Konfigurationsanweisungen eingegeben werden können, Änderungen am Funktion- sumf ang des Interpreters 44, etwa durch Laden neuer Grundroutinen, aber nicht mehr möglich sind. Realisiert wird der Konfigurationsmanager 49, indem die Ausführung bestimmter Grundroutinen des zugehörigen Namensraumes 45 gesperrt wird. Der Konfigurationsmanager 49 wird zweckmäßig eingerichtet, nachdem alle anderen Anwendungsprogramme geladen wur- den,
Eine Grundversion des Interpreters 44 mit Elementarroutinen sowie des Konfigurationsbereiches 48 sind zweckmäßig als Maskenprogramm in der nichtflüchtigen Speicherfeldern 3, 4 des tragbaren Datenträgers 10 hinterlegt.
Der Serverbereich 50 enthält die mit dem Datenträger 10 ausführbaren Anwendungsprogramme und die zu deren Funktion benötigten Dateien. Wenigstens eines der Anwendungsprogramme realisiert die Funktionalität eines Netzservers 52. Der Netzserver 52 kann beispielsweise ein HTTP-Server oder ein FTP-Server sein. Mit Hilfe eines Netzservers 52 wird der Datenträger 10 gegenüber dem Terminal 100 zu einem vollwertigen Netzserver. Beispielsweise bewirkt die Ausführung eines einen HTTP-Server realisierenden Anwendungsprogrammes durch den Interpreter 44 die Ausgabe einer HTML-Seite oder anderer Daten sowie eines Headers.
Anhang A zeigt als Beispiel für ein Anwendungsprogramm zur Realisierung eines Netzservers einen FORTH-Quelltext, der einen Basis-Netzserver realisiert. Der Quelltext kann mittels des Terrninalprograrnmes 102 im Transpa- rentmodus von einem Endgerät 100 auf einen Datenträger 10 übertragen werden und stellt dort die Netzserver-Funktionalität her.
Das die Funktionalität eines Netzservers 52 realisierende Anwendungsprogramm wird vom Interpreter 44 ausgeführt, wenn vom Transportsystem 22, nach Passage durch die Vermittlungs- und Transportschicht, eine sinnvolle Diensteanforderung am Ausgang des Transportsystems 22 vorliegt. Die Diensteanforderung kann etwa die Anforderung zur Ausführung eines HTTP-Kommandos wie GET, HEAD oder POST sein. Liegt eine solche Dien- steanforderuhg vor, ermittelt der Interpreter 44, ob im Serverbereich 50 ein den angeforderten Dienst realisierender Programmcode vorhanden ist. Ist das der Fall, übermittelt er dem Transportsystem 22 eine Bestätigungsmeldung und führt den gefundenen Programmcode aus.
Der angeforderte Dienst kann zum Beispiel in der Ausgabe einer einen Text enthaltenden HTML-Datei bestehen. Auslöser für die Anforderung kann eine von einem Nutzer über einen Netznavigator 150 angeforderte Adresse sein, etwa die Adresse „http://160.1.1.1/index/html". Der Netznavigator 150 erzeugt daraus eine http- Anweisung, die den HTTP-Befehl „GET" enthält, etwa „GET/ index.html http/1.1". Diese HTTP-Anweisung wird im Netzprotokollmodus 38 über das Transportsystem 22 an den Interpreter 44 geleitet. Der Interpreter 44 fungiert als HTTP-Netzserver 52 und führt entsprechend Grundroutinen aus, um dem Netznavigator 150 die angeforderte Datei zu liefern. Die erhaltene Datei bringt der Netznavigator 150 im Endge- rät 100 über die Nutzerschnittstelle 140 zur Anzeige.
Mit dem Netzserver 52 verbunden sind verschiedene Hilfsanwendungsprogramme, deren Art und Zahl dabei vom Typ des Netzservers und den jeweils gestellten Anforderungen abhängen. In Verbindung mit einem HTTP- Server 52 zweckmäßig sind ein Quelltextanalysator, etwa in Form eines
XML-Parsers 54, ein Compiler 56, etwa zur Compilierung von CGI-Scripten 66, sowie ein Block von Sicherheitskonfigurationsdateien 58, in denen Sicherheiteinstellungen für den Betrieb des Interpreters abgelegt sind. Weiter ist dem Netzserver 52 eine Dateisystem 68 mit Dateien zur Aufnahme von Nutzdaten zugeordnet, d.h. insbesondere Dateien 60 mit Applets, Dateien 62 mit Bildern, oder Dateien 64 mit graphisch darzustellenden Inhalten, etwa HTML-Dateien.
Im Serverbereich 50 zu speichernde Anwendungsprogramme und Dateien werden im Transparentmodus 39 über den Interpreter 44 oder im Netzprotokollmodus 38 mittels eines geeigneten Kommandos, etwa des HTTP- Kommandos POST, geladen.
Zweckmäßig sind bestimmte Grundstrukturen, etwa die Struktur des Da- teisystems 68 in dem zur Einrichtung des Serverbereichs 50 verwendeten Speicher 4 vorangelegt.
Neben einer Anwendung mit einem einzelnen Netzserver 52, etwa einem HTTP-Server 52, wie sie in Fig. 2 angedeutet ist, können im Serverbereich 50 auch mehrere Netzserver 52 eingerichtet sein, die unterschiedliche Dienste bereitstellen. Beispielsweise kann, wie in Fig. 6 veranschaulicht, neben einem HTTP-Server auch ein FTP-Server und/ oder einer Telnet-Server vorgesehen sein, der aktiv wird, wenn am Ausgang der TCP-Transportschicht der Port 20/21 für den FTP-Server bzw. 23 für den Telnet-Server angefordert wird. Allen Netzservern 52 können dabei eigene Dateisysteme zugeordnet sein. Sie können aber, wie in Fig. 6 veranschaulicht, auch auf dasselbe Dateisystem 68 zugreifen.
Der Kornrnunikationsbereich 120 des Endgerätes 100 bildet das Gegenstück zum Kommunikationsbereich 20 eines Datenträgers 10 und dient zur Durchführung eines Datenaustausches mit diesem. Wie jener weist der Kommunikationsbereich 120 des Endgerätes 100 eine Schichtstruktur auf. Zum Datenträger 10 hin besitzt er hierbei eine zu dessen Datenübertragungsschnittstelle 24 korrespondierende physikalische Schnittstelle 122, insbesondere eine
USB-, eine Firewire oder eine Ethernet-Schnittstelle. Darauf befindet sich eine Anpaßschicht 124, welche die über die Schnittstellen 122 übertragenen Daten aus dem auf der Schnittstelle 122 verwendeten Format in das vom Microcontroller 101 des Endgerätes 100 verlangte Format umsetzt. Ist bei- spielsweise die Schnittstelle 122 eine USB-Schnittstelle, der Microcontroller 101 aber nur zur Verarbeitung einfach serieller Signale ausgebildet, dann bildet die Anpaßschicht 26 eine virtuelle serielle Schnittstelle.
Über der Anpaßschicht 124 ist ein Transportsystem 130 zur Weiterleitung an bzw. Entgegennahme von über die Datenübertragungsschnittstelle 122 übertragenen Daten an den Netznavigator 150 ausgebildet. Typischerweise umfaßt das Transportsystem 130, wie in Fig. 1 angedeutet, eine SLIP- oder PPP- Schicht 132, eine IP-Schicht 134 sowie eine TCP-Schicht 136, d.h. ein an das OSI-Schichtenmodell angelehnte Protokollschichtenabfolge entsprechend den OSI-Schichten 2, 3 und 4 im Kommunikationsbereich des Datenträgers 10.
Zur Herstellung einer Transparentmodus-Datenverbindung zu einem Datenträger 10 dient das Terminalprogramm 102. Es wird über die Nutzerschnitt- stelle 140 bedient und realisiert den Datenaustausch im Transparentmodus 39. Unter Verwendung des Terminalprogramm.es 102 erfolgen unter anderem die Erstellung neuer Anwendungsprogramme für den Serverbereich und der Zugriff auf den Konfigurationsbereich 48.
Der Netznavigator 150 ist typischerweise ein üblicher Browser. Über die Schnittstelle 122 erlaubt er, sofern der Datenträger 10 über einen Netzserver 52 verfügt, insbesondere Auswahl und Aufruf einer bestimmten Anwendung aus dem Serverbereich 50 des tragbaren Datenträgers 10. Die Bedie- nung des Netznavigators 150 durch den Nutzer erfolgt ebenfalls über die Nutzer Schnittstelle 140.
Anhand der Fig. 6 wird nachfolgend eine praktische Nutzung eines Datenträgers 10 beschrieben. Die gezeigte Nutzung gliedert sich in drei Phasen, wobei die erste Phase z.B. beim Hersteller des Datenträgers 10 ausgeführt wird, die zweite Phase durch einen Anwender und die dritte Phase durch einen Endnutzer.
Die erste Phase setzt ein durch Bereitstellung eines Datenträgers 10 durch den Hersteller, Schritt 300. Auf dem Datenträger 10 sind durch Maskenprogrammierung der Interaktionsbereich 40 und der Kommunikationsbereich 20 mit einer Kommunikationseinrichtung zur Ausführung mindestens eines Netzwerkprotokolles angelegt. Auf den so vorbereiteten Datenträger 10 werden ferner die unmittelbar vom Hersteller aufzubringenden Anwendun- gen geladen, Schritt 302 und im Konfigurationsbereich 48 die zugehörigen Konfigurationen gesetzt, Schritt 304.
Anschließend wird der Datenträger 10 dem Anwendungsanbieter übergeben, Schritt 310. Bei dem Anwendungsanbieter handelt es sich insbesondere um eine Institution, die ein Netzwerk von Endgeräten 100 betreibt, an denen unter Verwendung eines Datenträgers 10 bestimmte Anwendungen durchgeführt werden können. Ein solcher Anwendungsanbieter kann beispielsweise eine Bank oder eine Behörde sein.
Der Anwendungsanbieter präsentiert den vom Hersteller erhaltenen Datenträger 10 an der Schnittstelle 122 eines geeigneten Endgerätes 100 und stellt unter Verwendung eines geeigneten Terminalprogramms 102 eine Verbindung zu dem Datenträger 10 her, Schritt 310. Als Ubertragungsmodus ist durch den Datenträger 10 zunächst der Transparentmodus 39 eingestellt, mithin ein Datenpfad zum Interaktionsbereich 40, Schritt 312. Der Anwendungsanbieter spielt nun eigene Anwendungen, Schritt 316, etwa spezielle Bank- oder Behördenanwendungen, auf den Datenträger 10 auf, wo sie in den Serverbereich 50 geladen werden.
Weiter nimmt der Anwendungsanbieter Anpassungen im Konfigurationsbereich 48 vor Schritt 320, und lädt sie auf den Datenträger 10. Beispielsweise kann es erforderlich sein, eine vom Hersteller zunächst angelegte, herstellerbezogene IP- Adresse des Datenträgers 10 in eine an den Endgeräten 100 des Anwenders gültige IP- Adresse zu ändern. Im Transparentmodus 39 tritt der Anwendungsanbieter daher in einen direkten Dialog mit dem Konfigurationsbereich 48 und stellt mittels des Endgerätes 100 die geänderte IP- Adresse ein. Sind alle beabsichtigten Zugriffe erfolgt, beendet der Anwendungsanbieter die Kommunikation mit dem Datenträger 10, indem er ihn von der endgerä- teseitigen Schnittstelle 122 entfernt, Schritt 322. Der Datenträger 10 wird nun dem Endnutzer übergeben.
Der Endnutzer präsentiert den Datenträger 10, Schritt 330, zur Ausführung einer Anwendung wiederum einem geeigneten Endgerät 100, beispielsweise dem Leser eines Heimcomputers, und stellt unter Verwendung eines geeigneten Ternrdnalprogrammes 102 eine Verbindung zu dem Datenträger 10 her. Der Datenträger 10 stellt sich darauf zunächst wiederum in den Transparentmodus 39, Schritt 332, und bietet über das Endgerät 100 einen Dialog mit dem Interaktionsbereich 40 an. In der Regel sind Änderungen im Aus- führungsbreich 40 durch einen Endnutzer aber nicht vorzunehmen.
Regelmäßig veranlaßt der Endnutzer vielmehr unmittelbar die Ausführung einer Anwendung. Hierzu wechselt er aus der zum Kommunikationsaufbau ' eingesetzten Programmroutine in eine für den Zugriff auf eine im Serverbereich 50 des Datenträgers 10 befindliche Anwendung geeignete Programmroutine, etwa einen üblichen Netzbrowser und fordert einen Zugriff auf die ' Anwendung an. Die Anforderung erfolgt unter Verwendung des Netzwerk- protokolles des Browsers, Schritt 334. Dies veranlaßt die Verteileinheit 26 des Datenträgers 10 zum Wechsel des Ubertragungsmodus und zur Einstellung eines Datenpfades in den Serverbereich 50 zu der gewünschten Anwendung.
Anschließend führt der Endnutzer die beabsichtigte Anwendung aus, Schritt 336. Durch Entfernen des Datenträgers 10 von der Schnittstelle 122 beendet der Endnutzer den Zugriff auf den Datenträger 10, Schritt 338.
Ergibt sich während der Ausführung einer Anwendung das Erfordernis zur Änderung einer Einstellung im Konfigurationsmanager 42, wechselt der Endnutzer zurück in den Transparentmodus 39, indem er den aktuellen Anwendungszugriff durch aktives Beenden der SLIP/PPP-Session bzw. durch Entfernen des Datenträgers 10 beendet, den Datenträger 10 unmittel- bar anschließend erneut an der Schnittstelle 122 des Endgerätes 100 präsentiert, Schritt 340, und unter neuerlicher Verwendung der dazu bereitgestellten Programmroutine eine Kommunikation zu dem Datenträger aufnimmt. Hierauf stellt jener zunächst wieder den Transparentmodus 39 ein.
Unter Beibehaltung des grundlegenden Gedankens, einen tragbaren Datenträger mit einem Interaktionsbereich zum Nachladen von zu interpretierendem Programmcode, vorzugsweise von in Hochsprache vorliegenden Programmquelltexten, einem Kommunikationsbereich zur Durchführung eines Transparent-Übertragungsmodus sowie mindestens eines weiteren zweiten Ubertragungsmodus, sowie einer Verteileinheit, welche in Abhängigkeit von den zugeführten Daten zwischen dem Transparentmodus und dem zweiten Ubertragungsmodus wechselt, zu versehen, gestattet die vorbeschriebene Erfindung eine Reihe von weiteren Ausgestaltungen.
So kann im Kommunikationsbereich 20 alternativ oder zusätzlich zu einer TCP/IP-Protkollarchitektur eine UDP/IP-Protokollarchitektur eingerichtet sein. Im Serverbereich 50 können weitere Netzserver 52, etwa ein TELNET- Server, mit zugehörige Hilfsprogrammen und Dateisystemen eingerichtet sein. TCP/IP selbst gestattet im Rahmen der zugehörigen RFCs eine Vielzahl von Varianten und Ausgestaltungen. Neben Anwendungen, die eine Netzserver 52 beinhalten können ferner Anwendungen mit beliebigen anderen Strukturen angelegt sein. Diese weiteren Anwendungen können zudem erfordern, daß im Kommunikationsbereich 20 eine speziell angepaßte weitere Protokollschichtarchitektur zur Kommunikation mit den Anwendungen eingerichtet wird. Anstelle einer Realisierung des Übertragungsmoduswechsel mittels einer Anordnung aus Verteileinheit 26, Aktivierungsmechanismus und Interpreter 44 mit Namensraumumschaltung kann weiterhin grundsätzlich eine gleichwirkende Lösung mit anderen Komponenten treten. Beispielsweise könnte die Funktionalität des Aktivierungsmechanismus in die Verteileinheit integriert werden. Zweckmäßige Abwandlungen können ferner aus dem Aspekt der Manipulationssicherheit bei der Handhabung von Daten auf dem tragbaren Datenträger sowie beim Austausch von Daten zwischen dem tragbaren Datenträger und einem Endgerät 100 resultieren.
Anhang A
0 constant FALSE
-1 constant TRUΕ 126 CONSTANT TIB-MAX
\ simulate modern for Windows 2000 SLIP : ATE1 . » OK" BEGIN key [char] C = UNTIL BEGIN key [char] T = UNTIL ." CLIENTSERVER"
: iplace 2dup ic! char+ swap d->i ;
: , ' [char] ' parse ihere over char+ iallot iplace align
I postpone (is" ) , ' postpone itype ; immediate
: html-header ( addr-c u -- ) . " <html><headxtitle>" 2dup type . " </titlex/head>" er
." <bodyxhl>" type ." </hl>" er
: line-rest ( -- addr len ) source >in @ /string dup >in + i
\ as accept, but without the echo : blind- ccept ( addr n -- n1 ) 2dup bounds DO key dup 10 = over 13 = OR F 2drop I swap - key drop unloop exit THEN I C I LOOP nip BEGIN key dup 10 = swap 13 = OR UNTIL key drop
wordlist constant http-words
\ dispatcher: run a text Interpreter loop \ in the http-words wordlist : 4HTTPd http-words 1 set-order BEGIN
TIB TIB- AX blind-ACCEPT 0 >IN ! ' TIB swap evaluate line-rest 2drop flush AGAIN \ endless loop, ter inates at power off forth-wordlist 1 set-order
http-words set-current
\ HTTP GET command, minimalistic : GET ( -- ) BEGIN \ ignore all input until end of HTTP request (double linefeed) FALSE key 13 = IF key dup 10 = swap 13 = or IF key 13 = IF key dup 10 = swap 13 = or IF drop true
THEN
THEN THEN
THEN
UNTIL line-rest 2drop HTTP/1.1 200 OK" er ." Server: XaMeLeon 1.0 (Forth) " er ' Accept-Ranges: bytes" er 1 Connection: close" er
Content-Type: text/html" er er s" G&D Internet Smart Card" html-header . " This is the default entry point to the Internet Smart Card" er . ' <olxlixa href="config_fS-html">Conf igure File System</a>' er
.' <lixa href="upload_file.html">Upload File</a>' er
.' <lixa href =" comp_cgi.html ">Compile CGI script</ax/ol>' er
. " </bodyx/html>" er er er er er er flush
4th \ for debugging only forth-wordlist 1 set-order 123 throw \ throw exception to exit "endless" loop
forth-wordlist set-current

Claims

P a t e n t a n s p r ü c h e
1.) Tragbarer Datenträger mit einem integrierten Schaltkreis mit Prozessorkern und zugeordnetem Speichersystem, in das wenigstens ein Anwen- dungsprogramm ladbar ist, sowie einer Datenübertragungsschnittstelle zum Austausch von Daten mit einem Endgerät, dadurch gekennzeichnet, daß der integrierte Schaltkreis (1) aufweist:
- einen Interaktionsbereich (40) zum Laden eines Anwendungsprogrammes, wobei die Datenübertragung zwischen der Datenübertiagungsschnittstelle
(24) und dem Interaktionsbereich (40) in einem ersten Ubertragungsmodus (39) erfolgt,
- eine Kornrnunikationseinrichtung (28, 30, 32), die zwischen der Datenübertragungsschnittstelle (24) und einem Anwendungsprogramm eine Daten- Übertragung in einem zweiten Ubertragungsmodus (38) ermöglicht,
- sowie eine der Datenübertragungsschnittstelle (24) zugeordnete Verteileinheit (26), die in Abhängigkeit von den über die Datenübertragungsschnittstelle (24) eingehenden Daten die Auswahl eines Ubertragungsmodus (38, 39) veranlaßt.
2. Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß wenigstens ein Anwendungsprogramm die Funktionalität eines Netzservers (52) herstellt
3. Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß im ersten Ubertragungsmodus (38) eine unveränderte Weiterleitung der eingehenden Daten an den Interaktionsbereich (40) erfolgt.
4. Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß der zweite Übertragungsmodus (38) einem standardisierten Netzwerkprotokoll entspricht.
5. Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß der Interak- tionsbereich (40) einen Interpreter (44) enthält.
6. Datenträger nach Anspruch 5, dadurch gekennzeichnet, daß der Funktionsumfang des Interpreters (44) durch Grundroutinen bestimmt wird, die in Namensräumen (45, 46) organisiert sind.
7. Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß der Verteileinheit (26) ein Aktivierungsmechanismus (37) zur Erzeugung einer ein bestimmtes Anwendungsprogramm bezeichnenden Anweisung nachgeschaltet ist.
8. Datenträger nach Anspruch 7, dadurch gekennzeichnet, daß der Aktivierungsmechanismus (37) die Erzeugung der Anweisung nach Erhalt eines Aktivierungssignales von der Verteileinheit (26) vornimmt.
9. Datenträger nach Anspruch 5 dadurch gekennzeichnet, daß der Interpreter (44) einen äußeren Interpreter (42) zur Ermittlung von in textuellen Anweisungen enthaltenen Grundroutinen sowie einen inneren Interpreter (43) zur Ausführung der Grundroutinen aufweist.
10. Datenträger nach Anspruch 5, dadurch gekennzeichnet, daß der Interpreter (44) den Programmcode eines heu geladenen Anwendungprogram- mes beim Laden in nativen Maschinencode des Prozessorkernes (2) überführt. - So ¬
ll . Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß der Interaktionsbereich (40) einen Konfigurationsbereich (48) enthält, in dem Parametrisierungen und Konfigurationseinstellungen zu den Anwendungsprogrammen bereitstellt sind.
12. Datenträger nach Anspruch 1, dadurch gekennzeichnet, daß die Verteileinheit (26) einen Wechsel des Ubertragungsmodus nur vom ersten (39) zum zweiten (38) vornimmt.
13. Datenträger nach Anspruch 11, dadurch gekennzeichnet, daß die Verteileinheit (26) den Ubertragungsmodus (38, 39) bei Erkennen eines speziellen Steuerelementes (420) wechselt.
14 Verfahren zum Einrichten eines Anwendungsprogramm.es auf einem tragbaren Datenträger mit den Schritten
Bereitstellen eines Speichersystems (3, 4, 5) zur Aufnahme eines An- wendungsprogrammes,
Einrichten eines Interpreters (44) zum Compilieren sowie zum Ausführen des Anwendungsprogrammes, - Erstellen des Quelltextes des einzurichtenden Anwendungsprogrammes in einer Programmierhochsprache,
Übertragen des in Hochsprache abgefaßten Quelltextes an den Interaktionsbereich (40), Überführen des in Hochsprache abgefaßten Quelltextes in einen für den Pro- zessorkern (2) des Datenträgers (10) ausführbaren Maschinencode durch den Interpreter (44),
Ausführen des Maschinencodes des Anwendungsprogrammes durch den Interpreter (44).
15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß in Hochsprache gefaßter Quelltext in einem ersten Ubertragungsmodus (39) an den Interpreter (44) übertragen wird.
16. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß zur Bearbeitung durch ein Anwendungsprogramm bestimmte Daten in einem zweiten Übertragungmodus (38) an das Anwendungsprogramm geleitet werden.
17. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß zu Beginn einer Kommunikation zwischen einem tragbaren Datenträger (10) und einem Endgerät (100) stets der erste Ubertragungsmodus (39) eingestellt wird.
18. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß der erste Ubertragungsmodus (39) eingestellt bleibt, bis in dem in dem tragbaren Da- tenträger (10) eingehenden Datenstrom ein bestimmtes Steuerelement (420) erkannt wird.
EP03785881A 2002-12-20 2003-12-18 Tragbarer datenträger mit netzserverfunktionalität Ceased EP1579318A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE2002161916 DE10261916A1 (de) 2002-12-20 2002-12-20 Tragbarer Datenträger mit Netzserverfunktionalität
DE10261916 2002-12-20
PCT/EP2003/014540 WO2004059562A2 (de) 2002-12-20 2003-12-18 Tragbarer datenträger mit netzserverfunktionalität

Publications (1)

Publication Number Publication Date
EP1579318A2 true EP1579318A2 (de) 2005-09-28

Family

ID=32404426

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03785881A Ceased EP1579318A2 (de) 2002-12-20 2003-12-18 Tragbarer datenträger mit netzserverfunktionalität

Country Status (4)

Country Link
EP (1) EP1579318A2 (de)
AU (1) AU2003294905A1 (de)
DE (1) DE10261916A1 (de)
WO (1) WO2004059562A2 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004052875A1 (de) * 2004-11-02 2006-05-04 Giesecke & Devrient Gmbh Tragbarer Datenträger mit einem integrierten Schaltkreis
DE102005028393A1 (de) * 2005-06-20 2006-12-28 Giesecke & Devrient Gmbh Tragbarer Datenträger
DE102007055653A1 (de) 2007-11-21 2009-05-28 Giesecke & Devrient Gmbh Portabler Datenträger mit Web-Server
DE102008004693A1 (de) 2008-01-16 2009-08-13 Giesecke & Devrient Gmbh Portabler Datenträger mit CAT-Interpreter
CN101826967B (zh) * 2009-11-25 2012-07-04 华为终端有限公司 数据卡及拨号上网方法
DE102010033995A1 (de) * 2010-08-11 2012-02-16 Giesecke & Devrient Gmbh Tragbarer Datenträger mit einem Web-Server
DE102012008147A1 (de) * 2012-04-24 2013-10-24 Tobias Volk Anordnung zur Organisation von Daten auf einem RFID- Transponder

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SI0819287T1 (en) 1995-02-17 2000-06-30 Europay International S.A. Integrated circuit controlled transaction management system
DE19926081A1 (de) * 1999-06-08 2000-12-21 Giesecke & Devrient Gmbh Chipkarte mit mehreren Anwendungsprogrammen
FR2805059A1 (fr) 2000-02-10 2001-08-17 Bull Cp8 Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
KR20000063142A (ko) 2000-02-17 2000-11-06 이응찬 폴리오르가노실세스키옥산 제조용 출발물질,폴리오르가노실세스키옥산 및 폴리오르가노실세스키옥산제조방법
EP1290536A2 (de) * 2000-06-15 2003-03-12 Rainbow Technologies B.V. Usb-kompatibler persönlicher schlüssel, der einen chipkartenprozessor und einen chipkartenlese-emulator verwendet

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HUSEMANN D: "Standards in the smart card world", 16 July 2001, COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, PAGE(S) 473 - 487, ISSN: 1389-1286, XP004304910 *
See also references of WO2004059562A3 *

Also Published As

Publication number Publication date
AU2003294905A8 (en) 2004-07-22
DE10261916A1 (de) 2004-07-01
AU2003294905A1 (en) 2004-07-22
WO2004059562A3 (de) 2005-01-06
WO2004059562A2 (de) 2004-07-15

Similar Documents

Publication Publication Date Title
DE69230199T2 (de) Kompensation von nicht richtig angepassten Transportprotokollen in einem Datenkommunikationsnetzwerk
DE69933883T2 (de) Verfahren zur verwendung von lokalen ressourcen in einem kommunikationssystem
EP0466969B1 (de) Verfahren zur Verhinderung unzulässiger Abweichungen vom Ablaufprotokoll einer Anwendung bei einem Datenaustauschsystem
DE69925806T2 (de) Verfahren zur kommunikation zwischen einer benutzerstation und einem netzwerk insbesondere das internet und architektur dafür
DE60207155T2 (de) Objektorientiertes Internetschnittstellensystem für eine industrielle Steuereinrichtung
DE60200210T2 (de) Über das World-Wide-Web zugängliche, eingebettete Programmier-Software
DE69400549T3 (de) IC-Karten-Übertragungssystem
DE10297269T5 (de) Kennzeichnung von Paketen mit einem Nachschlageschlüssel zur leichteren Verwendung eines gemeinsamen Paketweiterleitungs-Cache
WO1997001147A2 (de) Verfahren zur vereinfachung der kommunikation mit chipkarten
DE60036782T2 (de) Verfahren und architektur zur fernsteuerung von einer benutzerstation über internet
DE10236189A1 (de) Verfahren zum Zugreifen auf Bilderzeugungsinformationen auf einer Bedarfsbasis unter Verwendung einer Web-basierten Bilderzeugung
EP1579318A2 (de) Tragbarer datenträger mit netzserverfunktionalität
WO2003036401A2 (de) Verfahren zum erfassen von mehreren feldgeräten in einer gerätekonfiguration
DE102018128502A1 (de) Verfahren und Vorrichtung zur Bedienung und Steuerung einer maschinentechnischen Anlage mit Hilfe einer grafischen Entwicklungsoberfläche und Erzeugung einer Feldbus-Konfiguration
EP1527425B1 (de) Verfahren zum einrichten eines dateisystems in einem datenträger
DE10151735B4 (de) System und Verfahren zum Verbinden eines Webservers in einem Peripheriegerät mit einem Netzwerk durch einen Host
EP1230779B1 (de) Verfahren, chipkarte, und vorrichtung für eine logische schnittstelle zwischen zwei anwendungen
EP1845440A2 (de) Verfahren und Anordnung zum Drucken aus Web-Anwendungen heraus sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium
DE10244459A1 (de) Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik
EP2225647A2 (de) Portabler datenträger mit web-server
EP1177667B1 (de) Netzwerk, interpreter für ein derartiges netzwerk und verfahren zum betreiben eines netzwerkes
EP1435026B1 (de) System und verfahren zur datenausgabe eines geräts, insbesondere eines automatisierungsgerät über eine standardisierte schnittstelle mit variablenersetzung über einen echoserver
EP2740070B1 (de) Mechanismus zur kommunikation zwischen zwei applikationen auf einem sicherheitsmodul
EP2219115B1 (de) Verfahren zum Einsatz einer Multifunktionsspeicherkarte auf Endgeräten
EP1015972B1 (de) Verfahren zur vermittlung von transaktionsschritten

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

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 HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20060818

RIN1 Information on inventor provided before grant (corrected)

Inventor name: CIESINGER, DANIEL

Inventor name: GOETZE, FRANK

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20170419