WO2004059562A2

WO2004059562A2 - Portable data carrier with network server functionality

Info

Publication number: WO2004059562A2
Application number: PCT/EP2003/014540
Authority: WO
Inventors: Daniel Ciesinger; Frank GÖTZE
Original assignee: Giesecke & Devrient Gmbh
Priority date: 2002-12-20
Filing date: 2003-12-18
Publication date: 2004-07-15
Also published as: WO2004059562A3; AU2003294905A8; AU2003294905A1; DE10261916A1; EP1579318A2

Abstract

The invention relates to a portable data carrier (10), which is preferably embodied in the form of a chip card, comprising an interpreter (44) for loading and executing application programs, at least one of which carries out the functionality of a network server (52). Application programs are loaded and executed using various modes of transmission (38, 39). A distribution unit which monitors the incoming data flow for the presence of specific control elements, is used to adjust the respective transmission mode to be used. A transmission mode (38) can be a standard network protocol, especially a TCP/IP protocol.

Description

Portable data carrier with network server functionality

The invention is based on a portable data carrier according to the preamble of the main claim. 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). 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. In order to be able to execute card class files transferred to an IC card, there is a “virtual machine” on the IC card, that is to say a processor simulated in software form. The known solution allows a high level of security to be maintained with regard to the manipulation of loadable ones However, with a comparable range of functions, solutions based on a virtual machine take up more storage space than those based on operating systems that are adapted to the respective application, which means that resource-limited systems such as IC cards have the space available to accommodate applications The creation of new applications for IC cards also requires the provision of means for converting created class files, so the handling of the solution is restricted.

From WO 01/60040 the proposal is known to use a chip card as a web server, ie as a network server on the Internet and to provide the card with a proxy functionality. For this purpose, based on the OSI layer model, 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. In addition to various applications, 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.

From WO 01/60881 the proposal is known to provide an IC card with a standard interface for carrying out a standardized protocol according to the ISO standard with a functionality for executing a further protocol, in particular a USB protocol. For this purpose, there is an implementation device on the map which commands according to. implements the standardized card protocol in commands according to the second protocol. To control the implementation device through a terminal, the card is set up to execute a set of special commands.

From the "Handbuch der Chipkarten", W. Rankl, W. Effing, 2002, 4th edition, the physical structure of chip cards, especially the nature of the card microcontroller, and their interfaces to the outside world can be found Allow the reloading of program code onto a chip card. This deals with the possibility of providing a complete interpreter on chip cards and interprets the supplied program code on the card. However, the variant is chosen for reasons of working speed and storage. Space requirements for such an interpreter classified as unfavorable. The concept of the multifunction card is also described in the book.

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. However, 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.

A description of the most important principles of the programming language FORTH is given, inter alia, by the article "The Forth Approach to Operating Systems" by E.D. Rather, C.H. Moore, 1976, Proceedings of the ACM, pp. 233 to 240.

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. In particular, the network protocol can be a conventional TCP / IP protocol. The data carrier can thus be used in any TCP / IP environment. In particular, 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.

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.

Several network servers can also be set up on a portable data carrier to process different service requests. For example, 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.

Another great advantage arises from the versatility of the data carrier according to the invention, since it dispenses with data carrier-specific solutions when communicating with the outside world and can be operated like a freely configurable network subscriber.

With reference to the drawing, an embodiment of the invention is explained in more detail below.

Show it:

1 shows the basic structure of a portable data carrier,

2 shows the structures of a portable data carrier with network server functionality and of a terminal device interacting with the portable data carrier,

3 the realization of two data paths via a distribution unit, 4 shows the functioning of a protocol stack structure,

5 shows an arrangement of several network servers on a portable data carrier,

Fig. 6 shows a practical application of a data carrier.

In the following, a number of common abbreviations and technical terms are used, which are briefly explained in advance; More detailed explanations can be found, inter alia, in the "Computer Lexicon", Deutscher Taschenbuchverlag, 4th edition, 2002, in the "Lexikon der Datenkommunikation", Klaus Lipinski, 4th edition, Verlag Thomson Publishing, 1996, or in the "Handbuch" the chip cards "and on the Internet at" www.protocols.com/pbook/tcpip.htm ".

USB: Universal Serial Bus.

Unified interface for slow and medium-speed devices.

Protocol: Software component that acts as an intermediary between a sending and a receiving entity during data transmission.

SLIP: Serial Line Internet Working Protocol.

Protocol for the transmission of data packets over a serial connection. PPP: Point to Point Protocol.

Serial protocol for data transmission in point-to-point connections.

TCP: Transmission Control Protocol.

Protocol for controlling the connections between participants network. IP: Internet Working Protocol.

Protocol for determining the network address of a network participant. UDP: User Datagram Protocol. Particularly simple protocol without overhead.

HTTP Hypertext Transfer Protocol.

Protocol for the transfer of graphic information elements and files. DHCP: Dynamic Host Contention Protocol Automatic address assignment in the network under Windows.

CGI: Common Gateway Interface.

Protocol for coupling a web server with external programs. HTML: Hypertext Markup Language.

Language for the description of graphic information. XML: Extensible Markup Language.

Language extended to HTML to describe graphic information. OSI layer model: Open System Interconnection layer model.

Standard description for the architecture of a network. ASCII code: assignment rule that corresponds to a defined alphanumeric

Character set maps binary characters. RFC: Request for Comments

Internet standards documents. FORTH: High level programming language, in which the technical requirements of the usual processor core structure are based, see also ISO 15148. EDI: Remote data transmission, eg via telephone line via modem / ISDN adapter using communication programs A chip card is used below as a representative of a portable data carrier 10. However, the proposed solution is not limited to this embodiment, but can also be transferred with the same advantages to data carriers 10 in a different form with a limited amount of hardware and software. Examples of other resource-limited data carrier designs are the integration of a microcontroller in a pen or in clothing.

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.

Of the memory fields 3, 4, 5, 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. Alternatively, 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. In particular, 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. Furthermore, 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. To carry out the data exchange, 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. For example, 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.

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.

In the interaction area 40 and in the server area 50, there are applications and functionalities which can be executed in the form of application programs with the data carrier 10.

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. For this purpose, 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.

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.

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.

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. Furthermore, 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.

For the change in the transmission mode, 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.

If a previously determined control element appears in the observed data stream, 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. At the same time, 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. If the control element recognized by the distribution unit 26 designates data in SLIP / PPP format, for example, 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. When the inserted instruction is received, the interpreter 44 therefore sets the namespace 46 assigned to the network protocol mode 45 as the namespace to be used and blocks the other.

Appropriately it is provided that 10 during a communication between the data carrier and the terminal 100, a Übertragungsmo _^ duswechsel only from the transparent mode 39 in the. Network protocol mode 38 is possible. A change in the opposite direction, however, requires a renewed presentation of the data carrier 10 on the terminal 100. In principle, however, it can of course also be provided that the transmission mode can be changed in both directions at any time by means of suitable commands or control elements and that at the beginning of a communication the last transmission mode set is set.

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.

On 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. In TCP / IP, 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. When the first CO byte is recognized, 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. When the data packets 410 pass through the protocol stack, the faulty data packet 430 is rejected. At the exit of the transport layer, only 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”.

Depending on the applications that are to be executed by means of the data carrier 10, 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. On the network layer 28, 30, 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.

In a preferred embodiment, 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”).

In addition to FORTH, the 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. In 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. For example, 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.

Various 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. In conjunction with an HTTP server 52, a source code analyzer, for example in the form of a

XML parsers 54, a compiler 56, for example for compiling CGI scripts 66, and a block of security configuration files 58 in which security settings for the operation of the interpreter are stored. Furthermore, 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.

In addition to an application with a single network server 52, for example an HTTP server 52, as indicated in FIG. 2, in the server area 50 several network servers 52 can also be set up, which provide different services. For example, as illustrated in FIG. 6, in addition to an HTTP server, 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. There is an 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. Typically, 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. On the data carrier 10 prepared in this way, 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.

Instead, 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. By removing the data carrier 10 from the interface 122, the end user ends access to the data carrier 10, step 338.

If there is a need to run while an application is running If a setting is changed in the configuration manager 42, 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.

While maintaining the basic idea of a portable data carrier with an interaction area for reloading program code to be interpreted, preferably program source texts in high language, a communication area for carrying out a transparent transmission mode and at least one further second transmission mode, as well as a distribution unit which depends on the supplied data between the transparent mode and the second transmission mode, the above-described invention permits a number of further configurations.

For example, as an alternative or in addition to a TCP / IP protocol architecture, 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. In addition to applications that include a network server 52, 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. Instead of realizing the transmission mode change by means of an arrangement of distribution unit 26, activation mechanism and interpreter 44 with name space switchover, a solution with other components acting in principle can also occur in principle. For example, 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.

Appendix 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 their over char + iallot iplace align

I postpone (is "), 'postpone itype; immediate

: html-header (addr-c u -). "<html> <headxtitle>" 2dup type. "</ titlex / head>" he

. "<bodyxhl>" type. "</hl>" er

: line-rest (- addr len) source> in @ / string dup> in + i

\ as accept, but without the echo: blind- ccept (addr n - n ¹ ) 2dup bounds DO key dup 10 = over 13 = OR F 2drop I swap - key drop unloop exit THEN ICI 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 ¹ 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>" he he he he he flush

4th \ for debugging only forth-wordlist 1 set-order 123 throw \ throw exception to exit "endless" loop

forth-wordlist set-current

Claims

Patent claims

1.) Portable data carrier with an integrated circuit with processor core and associated memory system, into which at least one application program can be loaded, and a data transmission interface for exchanging data with a terminal, characterized in that the integrated circuit (1) has:

- an interaction area (40) for loading an application program, the data transfer between the data transfer interface

(24) and the interaction area (40) takes place in a first transmission mode (39),

- A Kornrnunikationseinrichtung (28, 30, 32) which enables data transmission between the data transmission interface (24) and an application program in a second transmission mode (38),

- And a distribution unit (26) assigned to the data transmission interface (24), which, depending on the data coming in via the data transmission interface (24), causes the selection of a transmission mode (38, 39).

2. Data carrier according to claim 1, characterized in that at least one application program produces the functionality of a network server (52)

3. Data carrier according to claim 1, characterized in that in the first transmission mode (38) there is an unchanged forwarding of the incoming data to the interaction area (40).

4. Data carrier according to claim 1, characterized in that the second Transmission mode (38) corresponds to a standardized network protocol.

5. Data carrier according to claim 1, characterized in that the interaction area (40) contains an interpreter (44).

6. Data carrier according to claim 5, characterized in that the functional scope of the interpreter (44) is determined by basic routines which are organized in namespaces (45, 46).

7. A data carrier according to claim 1, characterized in that the distribution unit (26) is followed by an activation mechanism (37) for generating an instruction designating a specific application program.

8. A data carrier according to claim 7, characterized in that the activation mechanism (37) carries out the generation of the instruction after receipt of an activation signal from the distribution unit (26).

9. A data carrier according to claim 5, characterized in that the interpreter (44) has an outer interpreter (42) for determining basic routines contained in textual instructions and an inner interpreter (43) for executing the basic routines.

10. A data carrier according to claim 5, characterized in that the interpreter (44) transfers the program code of a hay-loaded application program when loaded into native machine code of the processor core (2). - So ¬

ll. Data carrier according to claim 1, characterized in that the interaction area (40) contains a configuration area (48) in which parameterizations and configuration settings for the application programs are provided.

12. Data carrier according to claim 1, characterized in that the distribution unit (26) only changes the transmission mode from the first (39) to the second (38).

13. Data carrier according to claim 11, characterized in that the distribution unit (26) changes the transmission mode (38, 39) upon detection of a special control element (420).

14 Procedure for setting up an application program on a portable data carrier with the steps

Provision of a storage system (3, 4, 5) for receiving an application program,

Setting up an interpreter (44) for compiling and executing the application program, - creating the source text of the application program to be set up in a high-level programming language,

Transferring the source text written in high level language to the interaction area (40), transferring the source text written in high level language into a machine code that can be executed by the interpreter (44) for the processor core (2) of the data carrier (10),

Execution of the machine code of the application program by the interpreter (44).

15. The method according to claim 14, characterized in that in high language source text is transmitted in a first transmission mode (39) to the interpreter (44).

16. The method according to claim 14, characterized in that for processing by an application program certain data are passed to the application program in a second transmission mode (38).

17. The method according to claim 14, characterized in that at the start of communication between a portable data carrier (10) and a terminal (100), the first transmission mode (39) is always set.

18. The method according to claim 14, characterized in that the first transmission mode (39) remains set until a certain control element (420) is recognized in the data stream incoming in the portable data carrier (10).