NO985803L

NO985803L - Portable, secure transaction system for programmable, intelligent equipment devices

Info

Publication number: NO985803L
Application number: NO985803A
Authority: NO
Inventors: Guido Heyns; Peter Johannes
Original assignee: Europay Int Nv
Priority date: 1996-06-27
Filing date: 1998-12-11
Publication date: 1999-02-24
Also published as: CA2257641A1; YU60798A; SK176698A3; PL330930A1; SI9720049A; EA199900060A1; EP0907936A2; BR9710009A; NZ333384A; GB9613450D0; EA001598B1; JP2000514215A; TR199802675T2; CZ423598A3; AU716558B2; HUP0001822A3; WO1997050063A2; IL127533A0; ZA975748B; TW355776B

Abstract

Oppfinnelsen tilveiebringer et transaksjonshåndteringssystem til utførelse av transaksjoner mellom en første utstyrsenhet (1) og en andre utstyrsenhet, hvor nevnte første og andre ut- styrsenhet er tilpasset til å kommunisere med hverandre, og i det minste en av nevnte første og andre utstyrsenhet er et integrert-krets-kort, hvor nevnte system omfatter: i det minste en inn/ut-enhet (25); en bærbar virtuell datamaskin (20) til tolking av et dataprogram i nevnte første utstyrsen- het, hvor nevnte virtuelle datamaskin omfatter en virtuell mikroprosessor og en driver for nevnte i det minste ene inn/ ut-enhet (25); og utførelsesmiddel som reagerer på nevnte tolkede program til utførelse av nevnte program. Den gene- relle gjennomgående tekniske idé bak den herværende oppfin- nelse er bærbarhet kombinert med sikkerhet for data og kjøre- tidspunktgarantier i et transaksjonssystem, hvilke er uavhen- gige av den endelige implementering forutsatt at kontrollene på kompileringstidspunktet er gjennomgått vellykket. Denne idé oppfylles ved: bruk av en virtuell datamaskin (20) som en tolk, innbefattende en driver for inn/ut-enhetene i den vir- tuelle maskin, slik at brukerprogrammer har et felles grense- snitt med inn/ut-enheter og derfor er bærbare over vidt for- skjellige omgivelser, idet tildeling og fraordning av minne innbefatter en angivelse av mengden minne i brukerprogrammet hvilket innebærer at programmet bare blir kjørt vellykket, eller det blir ikke kjørt i det hele tatt, og sikkerhetshånd- teringsfunksjoner er redusert til et minimum, hvilket forbed- rer arbeidshastighet og tilveiebringer en sikker måte for im- portering og eksportering av data inn i og ut av brukerprogrammer og databaser.The invention provides a transaction management system for performing transactions between a first equipment unit (1) and a second equipment unit, wherein said first and second equipment units are adapted to communicate with each other, and at least one of said first and second equipment units is an integrated circuit board, wherein said system comprises: at least one input / output device (25); a virtual computer laptop (20) for interpreting a computer program in said first device, wherein said virtual computer comprises a virtual microprocessor and a driver for said at least one input / output device (25); and embodiment responsive to said interpreted program for executing said program. The general overall technical idea behind the present invention is portability combined with data security and runtime guarantees in a transaction system, which are independent of the final implementation provided that the checks at the time of compilation have been successfully completed. This idea is met by: using a virtual computer (20) as an interpreter, including a driver for the I / O devices in the virtual machine, so that user programs have a common interface with I / O devices and therefore are portable over a wide variety of environments, with allocation and allocation of memory including an indication of the amount of memory in the user program which means that the program is only run successfully or it is not run at all, and security management functions are reduced to a minimum, which improves working speed and provides a secure way for importing and exporting data into and out of user programs and databases.

Description

BÆRBART, SIKKERT TRANSAKSJONSSYSTEM FOR PROGRAMMERBARE, INTELLIGENTE UTSTYRSENHETER PORTABLE, SECURE TRANSACTION SYSTEM FOR PROGRAMMABLE, INTELLIGENT DEVICES

Den herværende oppfinnelse vedrører et system som innbefatter programmerbare, intelligente utstyrsenheter slik som terminaler og integrert-krets-kort så vel som en fremgangsmåte for betjening av slike kort og terminaler innbefattet automatiske kassaapparater, personlige datamaskiner (PC), betal-tv-enheter, salgsstedsterminaler, helsekort og lignende. Det er særlig egnet til bruk ved utføring av finansielle transaksjoner . The present invention relates to a system including programmable, intelligent equipment units such as terminals and integrated circuit cards as well as a method for operating such cards and terminals including automatic cash registers, personal computers (PC), pay TV units, point of sale terminals , health card and the like. It is particularly suitable for use when carrying out financial transactions.

Ulike typer terminaler er kjent til utførelse av transaksjoner, f.eks. finansielle transaksjoner som innebærer overfø-ring eller veksling av verdier, eller transaksjoner som er av kommersiell natur, slik som transaksjoner med helsekort eller for å få tilgang til data generelt, f.eks. SIM-kortet i en GSM-mobiltelefon. Terminaler slik som salgssteds(POS)-utstyrsenheter, automatiske kassaapparater (ATM) eller GSM-mobiltelefoner er kjent. Faktiske produkter varierer fra små, håndholdte enheter med enkle 8-bits mikroprosessorer slik som serien Intel 8031/8051 levert av Intel Corp., USA, eller Integrated Circuit Cards (ICC) til 32-bits datamaskiner som kjører operativsystemer slik som UNIX™, eller Windows NT levert av Microsoft Corp., USA. Noen av disse maskiner virker med et personlig brukerkort som kan være et kort med magnetstripe, smartkort eller ICC som lagrer spesifikk brukeriden-tifikasjons- og valideringsinformasjon som er nødvendig, før kommunikasjon mellom bruker og terminal kan innledes. Brukeren plasserer kortet i en kortleser som er tilknyttet terminalen, et terminalresident program i terminalen utføres og undersøker kortet, kontrollerer brukerinformasjonen med hensyn til dens gyldighet, og ber om nødvendig om et passord eller privat nummer slik som PIN (personlig identifikasjonsnum-mer) . Etter gyldighetsvurdering lar programmet vanligvis brukeren velge de ønskede tjenester som skal utføres, f.eks. kontantuttak, saldoforespørsel. Terminalen kan være selvstendig, eller den kan være tilkoplet en større datamaskin enten lokalt eller via et telekommunikasjonsnettverk. Slike terminaler er ofte tilgjengelige 24 timer i døgnet og må fungere med et minimum av vedlikehold og med en høy grad av sikkerhet. Different types of terminals are known for carrying out transactions, e.g. financial transactions that involve the transfer or exchange of values, or transactions that are of a commercial nature, such as transactions with health cards or to gain access to data in general, e.g. The SIM card in a GSM mobile phone. Terminals such as point of sale (POS) equipment units, automatic teller machines (ATM) or GSM mobile phones are known. Actual products range from small handheld devices with simple 8-bit microprocessors such as the Intel 8031/8051 series supplied by Intel Corp., USA, or Integrated Circuit Cards (ICC) to 32-bit computers running operating systems such as UNIX™, or Windows NT provided by Microsoft Corp., USA. Some of these machines work with a personal user card which can be a card with a magnetic stripe, smart card or ICC that stores specific user identification and validation information that is necessary before communication between user and terminal can be initiated. The user places the card in a card reader connected to the terminal, a terminal resident program in the terminal is executed and examines the card, checks the user information with regard to its validity, and if necessary asks for a password or private number such as PIN (personal identification number). After validity assessment, the program usually allows the user to select the desired services to be performed, e.g. cash withdrawal, balance request. The terminal can be independent, or it can be connected to a larger computer either locally or via a telecommunications network. Such terminals are often available 24 hours a day and must operate with a minimum of maintenance and with a high degree of security.

Slike terminaler representerer en betydelig investering i ma-skinvare, og de blir normalt ikke skiftet ut med korte mellomrom. Oppdatering av programvaren og programmer som kjøres på slike terminaler, blir nødvendig når nye tjenester tilbys, og må utføres på en sikker måte. Generelt krever organisasjonene, slik som banker, som driver terminalene, at hver oppdatering skal sertifiseres. Slik oppdatering kan skje manuelt eller fra et fjerntliggende sted via private eller offentlige kommunikasjonsnettverk slik det er kjent fra amerikansk patent nr. 5,434,999. Slike kjente opplegg krever at terminalens type og modell er kjent for nyutviklinger, da programvaren for hver terminal må lages spesielt for den terminaltype og derfor er meget kostbar. For å kunne tilby tjenester fra alle mulige organisasjoner som tilbyr lignende tjenester, f.eks. alle banker eller kredittinstitusjoner, må terminalen videre være i stand til å håndtere alle programmene for alle organisasjonene. På grunn av at både privatpersoner og for-retningsfolk forflytter seg mye, ville det være fordelaktig om alle tjenester som tilbys i ett land, var tilgjengelige på hver terminal. Dette ville føre til unødvendig stor behand-lingskapasitet og minnestørrelse for hver terminal. Videre må hvert av disse programmer oppdateres etter behov. En løsning kunne være å benytte en liten arbeidsstasjon for hver terminal, muligens tilkoplet et telekommunikasjonssystem. Et slikt system ville være i stand til å kjøre behandling frakoplet og kunne bytte til direktelinjebehandling for uvanlige transaksjoner eller for automatisk oppdatering av residente programmer. Arbeidsstasjoner ville være nødvendig for eksempel for å utføre den innviklede gyldighetsvurdering og de krypterings-opplegg som er nødvendig for å beholde sikkerheten i et system som er åpent for angrep via offentlige telefonnettverk. Med økende størrelse og kompleksitet ville problemet med å opprettholde sikkerheten også øke. Such terminals represent a significant investment in hardware, and they are not normally replaced at short intervals. Updating the software and programs running on such terminals becomes necessary when new services are offered, and must be carried out in a secure manner. In general, the organizations, such as banks, that operate the terminals require each update to be certified. Such updating may be done manually or from a remote location via private or public communication networks as known from US Patent No. 5,434,999. Such known systems require that the type and model of the terminal be known for new developments, as the software for each terminal must be made especially for that type of terminal and is therefore very expensive. To be able to offer services from all possible organizations that offer similar services, e.g. all banks or credit institutions, the terminal must also be able to handle all the programs for all the organisations. Due to the fact that both private individuals and business people move a lot, it would be advantageous if all services offered in one country were available at each terminal. This would lead to an unnecessarily large processing capacity and memory size for each terminal. Furthermore, each of these programs must be updated as needed. A solution could be to use a small workstation for each terminal, possibly connected to a telecommunications system. Such a system would be able to run processing offline and could switch to direct line processing for unusual transactions or for automatic updating of resident programs. Workstations would be required, for example, to perform the complex validation and encryption schemes necessary to maintain the security of a system open to attack via public telephone networks. With increasing size and complexity, the problem of maintaining security would also increase.

Selv med et slikt system kan det være problemer med versjons-kontroll. Kanskje har ikke alle brukere av tjenestene fra samme organisasjon kort som egner seg for den nyeste versjon av en tjeneste. Dette kan skje når flernasjonale organisasjoner innfører eller oppdaterer tjenester på ulike tidspunkter i ulike land. Det er blitt foreslått i WO 96/18979 å opp-datere terminaler bare for den berørte kjøring fra brukerens personlige ICC. Programinstruksjoner som representerer underrutiner, blir lagret i kortet og kan eksporteres til terminalen hvor de blir tolket. Bruken av et tolkeprogram i terminalen tillater samme kort å bli benyttet med enhver terminal Even with such a system, there can be problems with version control. Perhaps not all users of the services from the same organization have cards that are suitable for the latest version of a service. This can happen when multinational organizations introduce or update services at different times in different countries. It has been proposed in WO 96/18979 to update terminals only for the affected run from the user's personal ICC. Program instructions representing subroutines are stored in the card and can be exported to the terminal where they are interpreted. The use of an interpreter program in the terminal allows the same card to be used with any terminal

som inneholder tolkeprogrammet, og gjør derfor transaksjonen which contains the interpreter, and therefore does the transaction

uavhengig av vertsprosessoren i terminalen. Det er imidlertid ikke beskrevet noen fremgangsmåte for sikkerhetskontroll for å utelukke potensielt farlige underrutiner. independent of the host processor in the terminal. However, no security control procedure is described to exclude potentially dangerous subroutines.

Terminaler av den ovenfor beskrevne type har også en proses-sor som innbefatter en eller annen form for minne, vanligvis ett eller annet arbeidsminne (RAM) til kjøring av programmer, ett eller annet leseminne (ROM) til lagring av data som bare skal leses, hvilke kan innbefatte programmet for terminalens operativsystem og ikke-flyktig lese-skrive-minne til lagring av generelle data som kan endres. Brukerens personlige data skal holdes fortrolig, og det skal derfor ikke være noen mulighet for én bruker å få tilgang til andres data, verken tilfeldig eller med vilje fra en ondsinnet person. Videre skal terminalens forskjellige skriveminner ikke gå i oppløs-ning med tiden. At et minne går i oppløsning kan føre til at blokker av tilstøtende minne blir redusert i størrelse, slik at visse programmer ikke kan kjøres. For å unngå dette pro-blem benytter noen programmeringsspråk slik som Java™ renovasjonsprogram. Renovasjonsprogram er en rutine som forsøker å identifisere data i minnet som ikke lenger er nødvendige, og fraordner disse. Det er en faglig oppfatning i dag at renovasjonsprogram er en mer pålitelig måte å håndtere minne på enn å la et program uttrykkelig fraordne sine egne lagrede data. Bestemt minnetildeling og fraordning blir av noen holdt for å være den største enkeltkilde til programmeringsfeil i vanlige høynivå-programmeringsspråk, slik som C eller C++. Terminals of the type described above also have a processor which includes some form of memory, usually some work memory (RAM) for running programs, some read-only memory (ROM) for storing read-only data, which may include the terminal's operating system program and non-volatile read-write memory for storing general data that can be changed. The user's personal data must be kept confidential, and there must therefore be no possibility for one user to gain access to another's data, either accidentally or intentionally by a malicious person. Furthermore, the terminal's various write memories must not dissolve over time. Memory corruption can cause blocks of adjacent memory to be reduced in size, so that certain programs cannot be run. To avoid this problem, some use programming languages such as Java™ recycling programs. Renovation program is a routine that attempts to identify data in memory that is no longer needed, and disposes of these. It is a scientific opinion today that garbage collection programs are a more reliable way of managing memory than having a program explicitly deallocate its own stored data. Deterministic memory allocation and deallocation is considered by some to be the single largest source of programming errors in common high-level programming languages such as C or C++.

Renovasjonsprogram har flere ulemper. For det første er reno-vasjon snarere en operativsystemfunksjon enn en bruksspesifikk funksjon. Derfor garanterer renovasjonsprogram ikke at dataene for hver applikasjon blir fraordnet ved slutten av applikasjonen, men slike data kan snarere bli værende i noen tid inntil mangelen på inngang utløser renovasjonen. En sik-rere fremgangsmåte for å utelukke muligheten for adressering av private brukerdata kreves ved finansielle transaksjoner. For det andre øker det størrelsen på minne som kreves for operativsystemet. I ICC-er og noen terminaler kan lagerplas-sen være begrenset, og bruken av renovasjonsprogram kan være en alvorlig ulempe. Som forklart ovenfor, blir terminaler skiftet meget sjelden, slik at et vidt spekter av terminaler innbefattende ulike prosessorkapasiteter og minnestørrelser normalt er i virksomhet samtidig i systemet. Eldre terminaler er ofte sterkt begrenset i sin kapasitet. Selv om de eldste typer kan skiftes ut, innebærer kravet om mer raffinerte og innviklede tjenester at eldre terminaler sannsynligvis aldri vil bli skiftet ut så ofte at ikke noen av dem blir hengende etter i kapasitet. Videre vil kravet om kompakte operativsystemer som kan virke i et vidt spekter av prosessortyper, fortsatt bestå som et krav. Endelig frigjør renovasjonsprogram ikke minne så snart som dette ville bli frigjort ved bestemt fraordning. Dette kan også øke behovet for minne, da minnet er opptatt når det kunne vært frigjort. Renovation programs have several disadvantages. First, reno-vation is an operating system function rather than an application-specific function. Therefore, the sanitation program does not guarantee that the data for each application will be disposed of at the end of the application, but rather such data may remain for some time until the lack of input triggers the sanitation. A more secure method to exclude the possibility of addressing private user data is required for financial transactions. Second, it increases the amount of memory required for the operating system. In ICCs and some terminals, storage space can be limited, and the use of recycling programs can be a serious disadvantage. As explained above, terminals are changed very rarely, so that a wide range of terminals including different processor capacities and memory sizes are normally in operation at the same time in the system. Older terminals are often severely limited in their capacity. Although the oldest types can be replaced, the demand for more refined and complex services means that older terminals will probably never be replaced so often that some of them are left behind in capacity. Furthermore, the requirement for compact operating systems that can work in a wide range of processor types will continue to be a requirement. Finally, the cleanup program does not free memory as soon as it would be freed by certain deallocation. This can also increase the need for memory, as the memory is occupied when it could have been freed.

En sikker fremgangsmåte for håndtering av minne på kjøretids-punkt er beskrevet i amerikansk patent nr. 5,434,999. For eksempel, i overensstemmelse med denne kjente fremgangsmåte foretar et tolkeprogram i terminalen en systematisk kontroll av enhver instruksjon som manipulerer en lageradresse, for å verifisere om det område i minnet som det er bedt om adgang til, tillates. Dette system har den ulempe at hver instruksjon må kontrolleres på denne måte, noe som forsinker prosessen betydelig. Kontroll i programkjøretiden er kostbart å ut-føre . A secure method for handling memory at runtime is described in US Patent No. 5,434,999. For example, in accordance with this known method, an interpreter program in the terminal makes a systematic check of any instruction that manipulates a storage address, to verify whether the area of memory to which access is requested is permitted. This system has the disadvantage that each instruction must be checked in this way, which significantly delays the process. Control in the program runtime is expensive to carry out.

Det er behov for et system som tilveiebringer programmerbare terminaler som tillater brukerprogrammereren å generere programvare som er bærbar og nøytral over heterogene terminaler, dvs. uavhengig av prosessoren som er benyttet i terminalen, og ikke behøver bli typegodkjent for hver terminaltype eller -merke. Det terminalresidente operativsystem og brukerprogrammene er fortrinnsvis kompakte, hurtigarbeidende og opp-fyller sikkerhetskrav. Videre er det å foretrekke dersom brukerprogrammene lett kan oppdateres, i det minste at hver bruker kan oppnå de forventede tjenester uavhengig av terminalens geografiske plassering. There is a need for a system that provides programmable terminals that allow the user programmer to generate software that is portable and neutral across heterogeneous terminals, i.e. independent of the processor used in the terminal, and does not need to be type-approved for each terminal type or brand. The terminal-resident operating system and user programs are preferably compact, fast-working and meet security requirements. Furthermore, it is preferable if the user programs can be easily updated, at least so that each user can obtain the expected services regardless of the terminal's geographical location.

Et formål med den herværende oppfinnelse er å tilveiebringe et sikkert transaksjonshåndteringssystem for transaksjoner og en fremgangsmåte for å kjøre et slikt system. An object of the present invention is to provide a secure transaction management system for transactions and a method for running such a system.

Det er et ytterligere formål med den herværende oppfinnelse å tilveiebringe sikre terminaler og ICC-er for transaksjoner samt fremgangsmåter for kjøring av slike enheter. It is a further object of the present invention to provide secure terminals and ICCs for transactions as well as methods for running such devices.

Det er enda et ytterligere formål med oppfinnelsen å tilveiebringe en anordning som kan benyttes i en transaksjon som kan utføres i små håndholdte utstyrsenheter slik som et ICC. It is yet another object of the invention to provide a device which can be used in a transaction which can be carried out in small handheld equipment units such as an ICC.

Det er enda et annet formål med den herværende oppfinnelse å tilveiebringe transaksjonssystem hvor terminalene eller ICC-ene kan oppdateres ved bruk av terminalene eller ICC-ene som kilder for oppdateringsinformasjonen. It is yet another object of the present invention to provide a transaction system where the terminals or ICCs can be updated using the terminals or ICCs as sources for the update information.

Det er et videre formål med den herværende oppfinnelse å tilveiebringe et transaksjonshåndteringssystem og en fremgangsmåte for kjøring av systemet som tilveiebringer stor sikkerhet med god operasjonshastighet. It is a further object of the present invention to provide a transaction management system and a method for running the system which provides high security with good operational speed.

Den herværende oppfinnelse vedrører et transaksjonshåndteringssystem til utførelse av transaksjoner mellom en første utstyrsenhet og en andre utstyrsenhet, hvor nevnte første og andre utstyrsenheter er tilpasset til å kommunisere med hverandre, og hvor i det minste én av nevnte første og andre utstyrsenheter er et integrert-krets-kort, og hvor nevnte system omfatter: i det minste én inn/ut-enhet; en bærbar virtuell datamaskin til tolking av et datamaskinprogram i nevnte første utstyrsenhet, hvor nevnte virtuelle datamaskin omfatter en virtuell mikroprosessor og en driver for nevnte i det minste ene inn/ut-enhet, og utførelsesmiddel som svarer på nevnte tolkede program til utførelse av nevnte program. The present invention relates to a transaction management system for carrying out transactions between a first equipment unit and a second equipment unit, where said first and second equipment units are adapted to communicate with each other, and where at least one of said first and second equipment units is an integrated circuit card, and where said system comprises: at least one input/output unit; a portable virtual computer for interpreting a computer program in said first equipment unit, where said virtual computer comprises a virtual microprocessor and a driver for said at least one input/output unit, and execution means that respond to said interpreted program for executing said program .

Det er å foretrekke dersom den bærbare virtuelle datamaskin er en stakkmaskin, da dette gir kjørehastighet og kompakthet. It is preferable if the portable virtual computer is a stack machine, as this provides running speed and compactness.

Den herværende oppfinnelse tilveiebringer også en terminal som omfatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, hvor i det minste én av nevnte første og nevnte andre utstyrsenheter er et integrert-krets-kort som omfatter: en bærbar virtuell datamaskin som tolker et dataprogram i nevnte første utstyrsenhet, hvor nevnte bærbare virtuelle datamaskin omfatter en virtuell mikroprosessor og en driver for i det minste én inn/ut-enhet, og utførelsesmiddel som svarer på nevnte tolkede program til utførelse av nevnte program. The present invention also provides a terminal comprising a first equipment unit for performing a transaction with a second equipment unit, where at least one of said first and said second equipment units is an integrated circuit card comprising: a portable virtual computer that interprets a computer program in said first equipment unit, where said portable virtual computer comprises a virtual microprocessor and a driver for at least one input/output device, and execution means that respond to said interpreted program for executing said program.

Den herværende oppfinnelse tilveiebringer også et selvstendig, bærbart intelligent kort som innbefatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, hvor nevnte intelligente kort omfatter: en bærbar virtuell datamaskin som omfatter en virtuell mikroprosessor og en driver for minst én inn/ut-enhet. The present invention also provides a self-contained portable intelligent card comprising a first equipment unit for performing a transaction with a second equipment unit, said intelligent card comprising: a portable virtual computer comprising a virtual microprocessor and a driver for at least one I/O -unit.

Den herværende oppfinnelse tilveiebringer også et transaksjonshåndteringssystem som omfatter en første utstyrsenhet og en andre utstyrsenhet, hvor nevnte første og andre utstyrsenheter er tilpasset til å kommunisere med hverandre, idet i det minste én av nevnte første og andre utstyrsenheter er et integrert-krets-kort,; nevnte andre utstyrsenhet innbefatter middel for å tilveiebringe i det minste én programinstruksjon som er i stand til i det minste å modifisere oppførselen på kjøretidspunktet for et dataprogram i første utstyrsenhet; nevnte første utstyrsenhet innbefatter en virtuell datamaskin, hvor nevnte virtuelle datamaskin omfatter middel til innlasting og tolking av nevnte dataprogram, hvor nevnte middel til innlasting og tolking videre er tilpasset til å laste inn og tolke nevnte i det minste ene programinstruksjon avhengig av en forhåndsbestemt sikkerhetsbetingelse etter at nevnte middel til innlasting og tolking har lastet inn nevnte dataprogram, og mens nevnte dataprogram kjøres; og utførel-sesmiddel til utførelse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon. The present invention also provides a transaction management system comprising a first equipment unit and a second equipment unit, where said first and second equipment units are adapted to communicate with each other, at least one of said first and second equipment units being an integrated circuit card, ; said second equipment unit includes means for providing at least one program instruction capable of at least modifying the run-time behavior of a computer program in the first equipment unit; said first equipment unit includes a virtual computer, where said virtual computer comprises means for loading and interpreting said computer program, where said means for loading and interpreting is further adapted to load and interpret said at least one program instruction depending on a predetermined security condition according to that said means for loading and interpreting has loaded said computer program, and while said computer program is running; and execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

Videre tilveiebringer den herværende oppfinnelse en terminal som omfatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, og i det minste én av nevnte første og andre utstyrsenheter er et integrert-krets-kort, nevnte andre utstyrsenhet innbefatter middel til å tilveiebringe i det minste én programinstruksjon som er i stand til i det minste å modifisere oppførselen på utførelsestids-punktet for et dataprogram i nevnte første utstyrsenhet; hvor nevnte terminal omfatter: nevnte første utstyrsenhet innbefattende en virtuell datamaskin, hvor nevnte virtuelle datamaskin omfatter middel til innlasting og tolking av nevnte dataprogram, nevnte middel til innlasting og tolking videre er i stand til å laste inn og tolke nevnte i det minste ene programinstruksjon avhengig av en forhåndsbestemt sikkerhetsbetingelse etter at nevnte middel til innlasting og tolking har lastet inn nevnte dataprogram, og mens nevnte dataprogram kjøres; og utførelsesmiddel til utførelse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon. Furthermore, the present invention provides a terminal comprising a first equipment unit for carrying out a transaction with a second equipment unit, and at least one of said first and second equipment units is an integrated circuit card, said second equipment unit includes means for providing in at least one program instruction capable of at least modifying the execution-time behavior of a computer program in said first equipment unit; where said terminal comprises: said first equipment unit including a virtual computer, where said virtual computer comprises means for loading and interpreting said computer program, said means for loading and interpreting further is capable of loading and interpreting said at least one program instruction depending of a predetermined security condition after said loading and interpreting means has loaded said computer program, and while said computer program is running; and execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

Den herværende oppfinnelse tilveiebringer et selvstendig, bærbart intelligent kort som innbefatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, hvor nevnte andre utstyrsenhet innbefatter middel for tilveiebringelse av i det minste én programinstruksjon som er i stand til i det minste å endre oppførselen på utførelses-tidspunktet for et dataprogram i nevnte første utstyrsenhet, hvor nevnte intelligente kort omfatter: nevnte første utstyrsenhet innbefattet en virtuell datamaskin, hvor nevnte virtuelle datamaskin omfatter middel til innlasting og tolking av nevnte dataprogram, og nevnte middel for innlasting og tolking videre er tilpasset til å laste inn og tolke nevnte i det minste ene programinstruksjon avhengig av en forhåndsdefinert sikkerhetsbetingelse etter at nevnte middel til innlasting og tolking har lastet inn nevnte dataprogram, og mens nevnte dataprogram kjøres; og utførelsesmiddel til utfø-relse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon. The present invention provides a self-contained, portable intelligent card comprising a first equipment unit for performing a transaction with a second equipment unit, said second equipment unit comprising means for providing at least one program instruction capable of at least changing the behavior at the time of execution of a computer program in said first equipment unit, where said intelligent card includes: said first equipment unit including a virtual computer, where said virtual computer includes means for loading and interpreting said computer program, and said means for loading and interpreting is further adapted to load and interpret said at least one program instruction subject to a predefined security condition after said means for loading and interpreting has loaded said computer program, and while said computer program is running; and execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

Den herværende oppfinnelse tilveiebringer også et transaksjonssystem til utførelse av transaksjoner mellom en første utstyrsenhet og en andre utstyrsenhet, hvor nevnte system omfatter: en virtuell datamaskin til tolking av et sett av brukertilpassede bytekodesymboler benyttet i denne; nevnte vir tuelle datamaskin innbefatter en virtuell prosessenhet og lesbart/skrivbart logisk-adresse-område; hvor i det minste ett første brukerprogram innbefatter en angivelse av hvor stort lesbart/skrivbart logisk-adresse-område som trengs for dets utførelse, hvor nevnte i det minste ene første brukerprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett og motsvarende innebygde data; nevnte virtuelle datamaskin omfatter også: en innlaster til innlasting av nevnte i det minste ene første brukerprogram; og middel for tildeling av en første mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene første brukerprogram i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser. Den første utstyrsenhet i overensstemmelse med den herværende oppfinnelse kan være en personlig datamaskin (PC) som er tilkoplet Internet, og som kjører en skumleser (browser), hvor kravet om at hver modul som mottas av skumleseren, må inneholde en angivelse av min-nebehov, forbedrer skumleserens sikkerhet og begrenser den skade som ville kunne gjøres av eventuell virus inneholdt i den importerte modul-. The present invention also provides a transaction system for carrying out transactions between a first equipment unit and a second equipment unit, said system comprising: a virtual computer for interpreting a set of user-customized byte code symbols used therein; said virtual computer includes a virtual processing unit and readable/writable logical address space; where at least one first user program includes an indication of how large a readable/writable logical address area is needed for its execution, where said at least one first user program is written as a stream of symbols selected from said symbol set and corresponding embedded data ; said virtual computer also comprises: a loader for loading said at least one first user program; and means for assigning a first amount of readable/writable logical address area specifically for said at least one first user program in accordance with said indication, where said allocated readable/writable logical address area has defined and protected boundaries. The first equipment unit in accordance with the present invention can be a personal computer (PC) which is connected to the Internet, and which runs a skimmer (browser), where the requirement that each module received by the skimmer must contain an indication of memory requirements , improves the skimmer's security and limits the damage that could be done by any virus contained in the imported module.

Den herværende oppfinnelse tilveiebringer en terminal som omfatter en første utstyrsenhet til utførelse av transaksjoner med en andre utstyrsenhet, hvor nevnte første utstyrsenhet omfatter: en virtuell datamaskin til tolking av et sett av brukertilpassede bytekodesymboler anvendt på den; nevnte virtuelle datamaskin innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste ett første brukerprogram som innbefatter en angivelse av hvor stort lesebart/skrivebart logisk-adresse-område som trengs for dets utførelse, og en første eksklusiv liste over i det minste én funksjon som kan eksporteres til andre brukerpro grammer, idet nevnte i det minste ene første brukerprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett og motsvarende innebygde data; nevnte virtuelle datamaskin innbefatter også: en innlaster til innlasting av nevnte i det minste ene første brukerprogram; og middel for tildeling av en første mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene første brukerprogram i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser. The present invention provides a terminal comprising a first equipment unit for performing transactions with a second equipment unit, said first equipment unit comprising: a virtual computer for interpreting a set of user-customized bytecode symbols applied thereto; said virtual computer includes a virtual processor unit and readable/writable logical address space; at least one first user program that includes an indication of how large a readable/writable logical address area is needed for its execution, and a first exclusive list of at least one function that can be exported to other user programs, as mentioned in the at least one first user program is written as a stream of symbols selected from said symbol set and corresponding embedded data; said virtual computer also includes: a loader for loading said at least one first user program; and means for assigning a first amount of readable/writable logical address area specifically for said at least one first user program in accordance with said indication, where said allocated readable/writable logical address area has defined and protected boundaries.

Den herværende oppfinnelse kan også tilveiebringe et selvstendig, bærbart intelligent kort som innbefatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, hvor nevnte første utstyrsenhet omfatter: en virtuell datamaskin til tolking av et sett brukertilpassede bytekodesymboler benyttet på den; nevnte virtuelle datamaskin innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste ett første brukerprogram som innbefatter en angivelse av den mengde lesbart/skrivbart logisk-adresse-område som er nødvendig for dets utførelse, hvor nevnte i det minste ene første brukerprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett og motsvarende innebygde data; nevnte virtuelle datamaskin innbefatter også: en innlaster til innlasting av nevnte i det minste ene første brukerprogram; og middel til tildeling av en første mengde lesebart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene første brukerprogram i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser. The present invention may also provide a self-contained, portable intelligent card that includes a first equipment unit for performing a transaction with a second equipment unit, said first equipment unit comprising: a virtual computer for interpreting a set of user-customized byte code symbols used thereon; said virtual computer includes a virtual processor unit and readable/writable logical address space; at least one first user program which includes an indication of the amount of readable/writable logical address area that is necessary for its execution, where said at least one first user program is written as a stream of symbols selected from said symbol set and corresponding built-in data; said virtual computer also includes: a loader for loading said at least one first user program; and means for allocating a first amount of readable/writable logical address area specifically for said at least one first user program in accordance with said indication, where said allocated readable/writable logical address area has defined and protected boundaries.

Den herværende oppfinnelse kan også tilveiebringe et transaksjonssystem til utførelse av transaksjoner mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenheter er et integrert-krets-kort, og nevnte system omfatter: en virtuell datamaskin til tolking av et sett brukertilpassede bytekodesymboler benyttet på den; nevnte virtuelle datamaskin innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste én database som innbefatter i det minste én post, og i det minste ett dataprogram til utførelse via nevnte virtuelle datamaskin, hvor nevnte dataprogram er en modul skrevet i form av en strøm av nevnte symboler valgt fra nevnte sett og innbefattende en angivelse av mengden ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig til utførelse av nevnte modul; en innlaster til innlasting av nevnte modul og for tildeling av den nødvendige mengde ikke-initialisert logisk adresse/plass i overensstemmelse med nevnte angivelse; samt middel til tilgang til en post i nevnte database, idet poster i nevnte database bare er tilgjengelige via nevnte modul, og nevnte tilgangsmiddel tilveiebringer et vindu inn til en eksisterende post i nevnte database og kopierer nevnte post inn i et parti i nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område, hvilket kan adresseres av nevnte brukerprogram. The present invention can also provide a transaction system for carrying out transactions between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card, and said system comprises: a virtual computer for interpretation of a set of custom bytecode symbols used thereon; said virtual computer includes a virtual processor unit and readable/writable logical address space; at least one database including at least one record, and at least one computer program for execution via said virtual computer, where said computer program is a module written in the form of a stream of said symbols selected from said set and including an indication of the amount of uninitialized readable/writable logical address space required for execution of said module; a loader for loading said module and for allocating the required amount of uninitialized logical address/space in accordance with said specification; as well as a means of accessing a record in said database, as records in said database are only accessible via said module, and said access means provides a window into an existing record in said database and copies said record into a lot in said non-initialized readable/writable logical address area, which can be addressed by said user program.

Videre kan den herværende oppfinnelse også tilveiebringe en Furthermore, the present invention can also provide a

terminal som omfatter'en første utstyrsenhet til utførelse av transaksjoner med en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort, og nevnte første utstyrsenhet omfatter: en virtuell datamaskin til tolking av et sett brukertilpassede bytekodesymboler benyttet på den; nevnte virtuelle datamaskin innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk- terminal comprising a first equipment unit for carrying out transactions with a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card, and said first equipment unit comprises: a virtual computer for interpreting a set of user-adapted byte code symbols used thereon; said virtual computer includes a virtual processor unit and readable/writable logical

adresse-område: i det minste én database som innbefatter i det minste én post, og i det minste ett dataprogram til utfø-relse via nevnte virtuelle datamaskin, hvor nevnte dataprogram er en modul skrevet i form av en strøm av symboler valgt fra nevnte sett og innbefatter en angivelse av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul; en innlaster til address area: at least one database that includes at least one record, and at least one computer program for execution via said virtual computer, where said computer program is a module written in the form of a stream of symbols selected from said set and includes an indication of the amount of uninitialized readable/writable logical-address space necessary for execution of said module; one more loader

innlasting av nevnte modul og til tildeling av den nødvendige mengde ikke-initialisert logiske adresse/plass i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, idet poster i nevnte database bare er tilgjengelige via nevnte modul, og nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres av nevnte brukerprogram. loading said module and allocating the required amount of uninitialized logical address/space in accordance with said specification; and means for accessing a record in said database, records in said database being only accessible via said module, and said means of access providing a window to a current record in said database and copying said record into a batch of said uninitialized readable/writable logical address area that can be addressed by said user program.

Den herværende oppfinnelse kan tilveiebringe et selvstendig, bærbart intelligent kort som innbefatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, hvor nevnte første utstyrsenhet omfatter: en virtuell datamaskin til tolking av et sett brukertilpassede bytekodesymboler anvendt på den; hvor nevnte virtuelle datamaskin innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste én database som innbefatter i det minste én post, og i det minste ett dataprogram til utførelse via nevnte virtuelle datamaskin, idet nevnte dataprogram er en modul skrevet i form av en strøm av symboler valgt fra nevnte sett og innbefattende en angivelse av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul; en innlaster til innlasting av nevnte modul og til tildeling av den nødvendige mengde ikke-initialisert logisk adresse/område i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, idet poster i nevnte database bare er tilgjengelige via nevnte modul, hvor nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres av nevnte brukerprogram. The present invention may provide a self-contained portable intelligent card that includes a first equipment unit for performing a transaction with a second equipment unit, said first equipment unit comprising: a virtual computer for interpreting a set of user-customized byte code symbols applied thereto; wherein said virtual computer includes a virtual processor unit and readable/writable logical address space; at least one database containing at least one record, and at least one computer program for execution via said virtual computer, said computer program being a module written in the form of a stream of symbols selected from said set and including an indication of the amount of uninitialized readable/writable logical-address space required for execution of said module; a loader for loading said module and for allocating the required amount of uninitialized logical address/area in accordance with said specification; and means for accessing a record in said database, records in said database being only accessible via said module, where said means of access provides a window into a current record in said database and copies said record into a batch of said uninitialized readable/writable logical address area that can be addressed by said user program.

Den herværende oppfinnelse tilveiebringer også en fremgangsmåte for utførelse av en transaksjon mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenheter er et integrert-krets-kort; omfattende: tilveiebringelse av i det minste én programinstruksjon i nevnte andre utstyrsenhet som er i stand til i det minste å modifisere oppførselen på utførelsestids-punktet for et dataprogram i nevnte første utstyrsenhet; innlasting og tolking av nevnte dataprogram, innlasting og tolking av nevnte i det minste ene programinstruksjon avhengig av en forhåndsdefinert sikkerhetsbetingelse mens nevnte dataprogram kjøres; og utførelse av nevnte og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon. The present invention also provides a method for carrying out a transaction between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card; comprising: providing at least one program instruction in said second equipment unit capable of at least modifying the execution-time behavior of a computer program in said first equipment unit; loading and interpreting said computer program, loading and interpreting said at least one program instruction subject to a predefined security condition while running said computer program; and executing said and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

Den herværende oppfinnelse tilveiebringer også en fremgangsmåte for utførelse av en transaksjon mellom en første utstyrsenhet og en andre utstyrsenhet, omfattende: tolking av i det minste ett brukerprogram skrevet som en strøm av bytekodesymboler valgt fra et sett av symboler og motsvarende innebygde data; innlasting av nevnte i det minste ene brukerprogram; tildeling av en første mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene brukerprogram i overensstemmelse med en angivelse inneholdt i nevnte brukerprogram av den mengde lesbart/skrivbart logisk- adresse-område som er nødvendig for dets utførelse, og defi-nering og beskyttelse av grensene for nevnte tildelte lesbare/skrivbare logisk-adresse-område. Denne fremgangsmåte kombinerer bruken av et tolkeprogram med tildeling og valgfri bestemt fraordning av minne. Dette gir en blanding av fleksi-bilitet og bærbarhet mens det gir kjøretidspunkt-garantier etter at brukerprogrammet er blitt ordentlig kontrollert i kompileringstrinnet. Det reduserer skaden som kan forårsakes av virus i importerte brukermoduler. The present invention also provides a method for performing a transaction between a first device and a second device, comprising: interpreting at least one user program written as a stream of bytecode symbols selected from a set of symbols and corresponding embedded data; loading said at least one user program; allocation of a first amount of readable/writable logical address area specifically for said at least one user program in accordance with an indication contained in said user program of the amount of readable/writable logical address area that is necessary for its execution, and defi -neration and protection of the boundaries of said allocated readable/writable logical-address area. This method combines the use of an interpreter program with the allocation and optional specific deallocation of memory. This provides a mix of flexibility and portability while providing run-time guarantees after the user program has been properly checked at the compile stage. It reduces the damage that can be caused by viruses in imported user modules.

Den herværende oppfinnelse innbefatter også en fremgangsmåte for utførelse av et transaksjonssystem mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenheter er et integrert-krets-kort, hvilken fremgangsmåte omfatter: tolking av symbolene i en modul skrevet i form av en strøm av nevnte symboler valgt fra et sett av symboler; tildeling av en mengde ikke-initialisert logisk adresse/plass i overensstemmelse med en angivelse i nevnte modul av mengden ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for ut-førelsen av nevnte modul; tilgang til en post i en database ved å tilveiebringe et vindu inn til en aktuell post i nevnte database, idet poster i en database bare er tilgjengelige gjennom nevnte modul; og kopiering av nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område, som kan adresseres av nevnte modul. The present invention also includes a method for implementing a transaction system between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card, which method comprises: interpreting the symbols in a module written in the form of a stream of said symbols selected from a set of symbols; allocating an amount of uninitialized logical address/space in accordance with an indication in said module of the amount of uninitialized readable/writable logical address area necessary for the execution of said module; access to a record in a database by providing a window into a current record in said database, records in a database being only accessible through said module; and copying said record into a portion of said uninitialized readable/writable logical address area, which can be addressed by said module.

Den herværende oppfinnelse innbefatter også en fremgangsmåte for utførelse av en transaksjon mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte før-ste og andre utstyrsenheter er et integrert-krets-kort, omfattende: tilveiebringelse av en bærbar virtuell datamaskin som omfatter en virtuell mikroprosessor og en driver for i det minste én inn/ut-enhet; tolking av et dataprogram i nevnte første utstyrsenhet ved bruk av nevnte bærbare virtuelle datamaskin; og utførelse av nevnte program som svar på nevnte tolkede program. The present invention also includes a method for performing a transaction between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card, comprising: providing a portable virtual computer comprising a virtual microprocessor and a driver for at least one input/output device; interpreting a computer program in said first equipment unit using said portable virtual computer; and executing said program in response to said interpreted program.

I overensstemmelse med den herværende oppfinnelse er det tilveiebrakt et sikkert transaksjonshåndteringssystem som fortrinnsvis innbefatter en bærbar virtuell mikroprosessor. Fortrinnsvis innehar hver modul et sett virtuelle adresseområder som garanteres å være atskilt fra hvilket som helst annet virtuelt adresseområde. Den bærbare virtuelle mikroprosessor beskytter fortrinnsvis også tilgang til delte ressurser slik som de ulike stakklagre eller databasene. Fortrinnsvis er mi-nimumsbeskyttelsen minnekontroll av grensene for dataområde-tilgang for lesing og skriving og absolutt forbud mot skriving til kodeområder. Videre foretrekkes kontroll med hensyn til aritmetisk underflyt og aritmetisk overflyt på data og returstakklagre. Fortrinnsvis kan en modul bare ha tilgang til det som en annen modul uttrykkelig eksporterer. Fortrinnsvis finnes det ikke noen måte som ikke-eksporterte data kan bli tilgjengelig på (den virtuelle mikroprosessor lekker ikke) , bortsett fra gjennom funksjoner tilveiebrakt ved en modul. Moduler kan fortrinnsvis ikke eksportere data i vanlig forstand; moduler kan fortrinnsvis bare eksportere funksjoner. Fortrinnsvis forbyr de logiske grenser dataområdelekka-sje. Med andre ord er alle data som innehas av en modul/fortrinnsvis strengt fortrolige. Denne begrensning er fortrinnsvis gjeldende både på kompilerings- og kjøretids-punktet, siden moduler har separate adresseområder, hvilket betyr at adressen til noen data inne i en eller annen modul er helt meningsløs utenfor dens egen modul. Fortrinnsvis kan en modul bare eksportere et sett håndtak til igangsetting eller stenging av en spesiell oppførsel. Fortrinnsvis vil vel- oppdragne moduler virke uten feil, mens ikke fullt så velopp-dragne moduler vil bli avbrutt gjennom unntakssituasjoner fremsatt direkte av den bærbare virtuelle mikroprosessor når en ulovlig operasjon blir forsøkt. In accordance with the present invention, there is provided a secure transaction management system which preferably includes a portable virtual microprocessor. Preferably, each module holds a set of virtual address ranges that are guaranteed to be separate from any other virtual address range. The portable virtual microprocessor also preferably protects access to shared resources such as the various stack stores or databases. Preferably, the minimum protection is memory control of data area access limits for reading and writing and absolute prohibition of writing to code areas. Furthermore, control with respect to arithmetic underflow and arithmetic overflow on data and return stack stores is preferred. Preferably, a module can only access what another module explicitly exports. Preferably, there is no way that non-exported data can become available (the virtual microprocessor does not leak), except through functions provided by a module. Modules preferably cannot export data in the usual sense; modules can preferably only export functions. Preferably, the logical boundaries prohibit data area leakage. In other words, all data held by a module is/preferably strictly confidential. This limitation is preferably applied at both compile-time and runtime, since modules have separate address ranges, meaning that the address of some data inside one or another module is completely meaningless outside of its own module. Preferably, a module can only export a set of handles for initiating or terminating a particular behavior. Preferably, well-behaved modules will operate without error, while not-so-well-behaved modules will be interrupted through exceptions raised directly by the portable virtual microprocessor when an illegal operation is attempted.

De avhengige krav beskriver individuelle utførelser av den herværende oppfinnelse. Den herværende oppfinnelse, dens ut-førelser og fordeler vil nå bli beskrevet under henvisning til de medfølgende tegninger. Fig. 1 er en skjematisk fremstilling av en terminal i overensstemmelse med den herværende oppfinnelse. Fig. 2 er en skjematisk fremstilling av et ICC i overensstemmelse med den herværende oppfinnelse. Fig. 3 er et skjematisk flytdiagram for prosessen ved utvik-ling og utføring av en modul i overensstemmelse med den herværende oppfinnelse. Fig. 4 er en skjematisk fremstilling av en bærbar virtuell mikroprosessor i overensstemmelse med den herværende oppfinnelse slik den er tatt i bruk i en terminal. Fig. 5 er en skjematisk fremstilling av den bærbare virtuell mikroprosessor i overensstemmelse med den herværende oppfinnelse . Fig. 6 er en skjematisk fremstilling av en modul lastet inn i minnet i overensstemmelse med den herværende oppfinnelse. Fig. 7 er en skjematisk fremstilling av fremgangsmåten for å oppnå tilgang til en databasepost i overensstemmelse med den herværende oppfinnelse. Fig. 8 er en skjematisk fremstilling av støpsel- og kontakt-prosedyren i overensstemmelse med den herværende oppfinnelse. Fig. 9 er et flytdiagram over modulinnlastingsprosedyren i-følge den herværende oppfinnelse. Fig. 10 er et flytdiagram over modulutførelsesprosedyren i-følge den herværende oppfinnelse. Fig. 11 er et flytdiagram over kontaktpluggingsprosedyren i-følge den herværende oppfinnelse. Fig. 12 er et flytdiagram over kortmodulinnlastingsprosedyren i overensstemmelse med den herværende oppfinnelse. The dependent claims describe individual embodiments of the present invention. The present invention, its embodiments and advantages will now be described with reference to the accompanying drawings. Fig. 1 is a schematic representation of a terminal in accordance with the present invention. Fig. 2 is a schematic representation of an ICC in accordance with the present invention. Fig. 3 is a schematic flow diagram for the process of developing and executing a module in accordance with the present invention. Fig. 4 is a schematic representation of a portable virtual microprocessor in accordance with the present invention as used in a terminal. Fig. 5 is a schematic representation of the portable virtual microprocessor in accordance with the present invention. Fig. 6 is a schematic representation of a module loaded into the memory in accordance with the present invention. Fig. 7 is a schematic representation of the method for gaining access to a database record in accordance with the present invention. Fig. 8 is a schematic representation of the plug and contact procedure in accordance with the present invention. Fig. 9 is a flow diagram of the module loading procedure according to the present invention. Fig. 10 is a flow diagram of the module execution procedure according to the present invention. Fig. 11 is a flowchart of the contact plugging procedure according to the present invention. Fig. 12 is a flowchart of the card module loading procedure in accordance with the present invention.

Vedlegg gir symbolkodene og standardunntakssituasjonene.Appendix provides the symbol codes and standard exception situations.

Den herværende oppfinnelse vil bli beskrevet i nedenstående under henvisning til enkelttegninger og visse utførelser, men oppfinnelsen er ikke begrenset til disse, men kun av kravene. Tegningene er bare skjematiske og er ikke begrensende. Den herværende oppfinnelse vil bli beskrevet under henvisning til finansielle transaksjoner, men oppfinnelsen er ikke begrenset til disse. Videre vil den herværende oppfinnelse bli beskrevet hovedsakelig med henvisning til en terminal, men den herværende oppfinnelse innbefatter også tilveiebringelse av den bærbare virtuelle mikroprosessor i overensstemmelse med den herværende oppfinnelse i hvilken som helst annen utstyrsen het, f.eks. en personlig datamaskin (PC), et ICC eller et kombinert ICC og grensesnitt som beskrevet i WO94/10657 som er innbefattet i dette skrift gjennom henvisning. The present invention will be described below with reference to individual drawings and certain embodiments, but the invention is not limited to these, but only by the claims. The drawings are schematic only and are not limiting. The present invention will be described with reference to financial transactions, but the invention is not limited to these. Further, the present invention will be described mainly with reference to a terminal, but the present invention also includes providing the portable virtual microprocessor in accordance with the present invention in any other equipment, e.g. a personal computer (PC), an ICC or a combined ICC and interface as described in WO94/10657 which is incorporated herein by reference.

Den generelle gjennomgående tekniske idé bak den herværende oppfinnelse er bærbarhet kombinert med datasikkerhet og kjø-retidsgarantier i et transaksjonssystem hvilke er uavhengige av den endelige bruk forutsatt at kontrollene på kompileringstidspunktet er gjennomgått vellykket. Denne idé blir fullført gjennom ett eller flere av følgende trekk: bruk av en virtuell datamaskin som en tolkeinnretning, innbefatning av en driver for inn/ut-enhetene i den virtuelle datamaskin, slik at brukerprogrammer har et felles grensesnitt med inn/ut-enhetene og derfor er bærbare over høyst forskjellige omgivelser, innbefattende en angivelse av minnemengden i brukerprogrammet og tildeling av minne i overensstemmelse med angivelsen, bestemt fraordning av minne og tilveiebringelse av en sikker måte for importering og eksportering av data til og fra brukerprogrammer og/eller databaser. The general technical idea behind the present invention is portability combined with data security and runtime guarantees in a transaction system which are independent of the final use provided that the checks at the time of compilation have been passed successfully. This idea is accomplished through one or more of the following features: using a virtual computer as an interpreter device, including a driver for the I/O devices in the virtual computer so that user programs have a common interface with the I/O devices, and therefore, are portable across widely varying environments, including specifying the amount of memory in the user program and allocating memory in accordance with the specification, determining the allocation of memory and providing a secure means of importing and exporting data to and from user programs and/or databases.

Fig. 1 er en skjematisk fremstilling av en terminal 1 i overensstemmelse med den herværende oppfinnelse. Typisk innbefatter terminalen 1 en prosessorenhet (CPU) 2 som er forbundet med et minne 4 og inn/ut-enheter 6 via en buss 3 for toveis kommunikasjon. Inn/ut-enheter 6 kan være et tastatur til inn-tasting av data og en skjerm slik som en dataskjermterminal, f.eks. en skjerm med flytende krystaller (LCD) eller med ly-semitterende dioder (LED), til visning av transaksjonens for-løp og/eller visning av meldinger eller til å be om opplysninger. En av inn/ut-enhetene 6 kan være en kortleser 7 som et ICC 5 kan leses med, når dette blir ført inn i leserens 7 mottaksspalte. Terminalens faktiske form kan variere meget, f.eks. kan det være en salgsstedsterminal (POS) og kan innbe fatte prosessorer fra en Intel 8051 til en Pentium™. Videre er det ikke nødvendig at hele terminalen 1 er plassert på ett sted, de forskjellige deler av terminalen slik som kortleseren 7, inn/ut-enhetene slik som tastaturet og displayet og prosessoren kan være plassert på forskjellige steder og være forbundet via kabler, trådløs overføring eller lignende eller være en del av et lokalt nettverk eller sammenkoplet via te-le kommuni kas j onsnet tverk . Fig. 1 is a schematic representation of a terminal 1 in accordance with the present invention. Typically, the terminal 1 includes a processor unit (CPU) 2 which is connected to a memory 4 and input/output units 6 via a bus 3 for two-way communication. Input/output devices 6 can be a keyboard for entering data and a screen such as a computer display terminal, e.g. a screen with liquid crystals (LCD) or with light-emitting diodes (LED), for displaying the progress of the transaction and/or displaying messages or for requesting information. One of the input/output units 6 can be a card reader 7 with which an ICC 5 can be read, when this is introduced into the reader's 7 receiving slot. The actual shape of the terminal can vary greatly, e.g. it can be a point of sale (POS) terminal and can include processors from an Intel 8051 to a Pentium™. Furthermore, it is not necessary that the whole terminal 1 is located in one place, the different parts of the terminal such as the card reader 7, the input/output devices such as the keyboard and the display and the processor can be located in different places and be connected via cables, wireless transmission or the like or be part of a local network or interconnected via a telecommunications network.

Fig. 2 er en skjematisk fremstilling av et ICC 5 i overensstemmelse med den herværende oppfinnelse. Den herværende oppfinnelse er imidlertid ikke begrenset til dette. ICC-et 5 innbefatter i det minste en inn/ut-port 10 og noe permanent lager, f.eks. et ikke-flyktig minne som kan være tilveiebrakt, for eksempel, gjennom et EEPROM 15 koplet til inn/ut-porten 10 via en buss 17 eller via batteridrevet arbeidsminne (RAM). Inn/ut-porten 10 kan benyttes til kommunikasjon med terminalen 1 via kortleseren 7. Et integrert-krets-kort er et kort i hvilket det er satt inn én eller flere integrerte kretser for å utføre i det minste minnefunksjoner. Valgfritt kan ICC-et 5 være et selvstendig, bærbart, intelligent kort og kan innbefatte et lese/skrive-arbeidslager, f.eks. flyktig minne tilveiebrakt ved et RAM 14 og en prosessorenhet 12 så vel som alle nødvendige kretser, slik at kortet ICC 5 kan virke som en mikroprosessor, f.eks. leseminne 13 til lagring av kode, en sekvensinndeler 16 og forbindelser med kortleseren 7 til mottak av spenningskildene Vss og VDD, en tilbake-stillingsenhet for prosessorenheten 12 og klokke til se-kvensinndeleren 16. I overensstemmelse med den herværende oppfinnelse kan ICC-et 5 benyttes som bankkort, kredittkort, debetkort, elektronisk pengepung, helsekort, SIM-kort eller lignende. Fig. 2 is a schematic representation of an ICC 5 in accordance with the present invention. However, the present invention is not limited to this. The ICC 5 includes at least one input/output port 10 and some permanent storage, e.g. a non-volatile memory which can be provided, for example, through an EEPROM 15 connected to the input/output port 10 via a bus 17 or via battery-operated working memory (RAM). The input/output port 10 can be used for communication with the terminal 1 via the card reader 7. An integrated circuit card is a card in which one or more integrated circuits have been inserted to perform at least memory functions. Optionally, the ICC 5 may be a self-contained, portable, intelligent card and may include a read/write work store, e.g. volatile memory provided by a RAM 14 and a processor unit 12 as well as all necessary circuitry so that the card ICC 5 can act as a microprocessor, e.g. read memory 13 for storing code, a sequence divider 16 and connections with the card reader 7 for receiving the voltage sources Vss and VDD, a reset unit for the processor unit 12 and clock for the sequence divider 16. In accordance with the present invention, the ICC 5 can be used such as bank cards, credit cards, debit cards, electronic wallets, health cards, SIM cards or the like.

Den herværende oppfinnelse tilveiebringer et transaksjonshåndteringssystem styrt av integrerte kretser, hvilket er ment å utføre, mellom et ICC 5 og en terminal 1 tilkoplet eller ikke tilkoplet en sentral enhet, en transaksjon bestående av i det minste én utførelse av følgende sekvens: 1. opprettelse av en kommunikasjonslenke mellom ICC-et 5 og terminalen 1; 2. utførelse av en kompatibilitetskontroll for å sikre at ICC-et 5 og terminalen 1 er mekanisk og elektrisk kom patible; 3. valg av anvendelse innbefattet valg av et dataprogram og det tilknyttede datasett som definerer transaksjonen når det gjelder den involverte spesifikke kombinasjon av ICC 5 og terminal 1; 4. utførelse av anvendelsen; 5. avslutning av transaksjonen som valgfritt omfatter bry ting av kommunikasjonslenken mellom ICC-et 5 og termina len 1; idet et tolkeprogram benyttes til å utføre anvendelsen, enten på ICC-et 5 eller på terminalen eller på begge. En transaksjon er en utveksling av i det minste data mellom to eller flere utstyrsenheter og er ifølge den herværende oppfinnelse ikke spesifikk for en kommersiell finansiell transaksjon. Et slikt system er kjent fra PCT/BE 95/00017. ICC-et 5 kan være et rent minne-ICC, dvs. ikke innbefattende prosessorenhet 12, og ICC-et 5 gjennomgår transaksjonen som bestemt gjennom terminalen 1. Alternativt kan ICC-et 5 være et selvstendig, bærbart intelligent kort, og transaksjonen kan bestemmes av terminalen 1, av ICC-et 5 eller av begge. I overensstemmelse med den herværende oppfinnelse kan ICC-et 5 innbefatte programkode for sikkert å forbedre en terminals behandling. Særlig kan ICC-et 5 The present invention provides a transaction management system controlled by integrated circuits, which is intended to perform, between an ICC 5 and a terminal 1 connected or not connected to a central unit, a transaction consisting of at least one execution of the following sequence: 1. creation of a communication link between the ICC 5 and the terminal 1; 2. performing a compatibility check to ensure that the ICC 5 and the terminal 1 are mechanically and electrically compatible; 3. selection of application including selection of a computer program and the associated data set defining the transaction in terms of the specific combination of ICC 5 and terminal 1 involved; 4. execution of the application; 5. termination of the transaction which optionally includes breaking the communication link between the ICC 5 and terminal 1; in that an interpreter program is used to carry out the application, either on the ICC 5 or on the terminal or on both. A transaction is an exchange of at least data between two or more equipment units and according to the present invention is not specific to a commercial financial transaction. Such a system is known from PCT/BE 95/00017. The ICC 5 may be a pure memory ICC, i.e. not including the processing unit 12, and the ICC 5 reviews the transaction as determined through the terminal 1. Alternatively, the ICC 5 may be a self-contained, portable intelligent card, and the transaction may be determined by the terminal 1, by the ICC 5 or by both. In accordance with the present invention, the ICC 5 may include program code to reliably improve a terminal's processing. In particular, the ICC can 5

være ett eller flere vedlikeholdskort som kan benyttes til oppdatering av anvendelsene lagret i terminalen 5. be one or more maintenance cards that can be used to update the applications stored in the terminal 5.

I overensstemmelse med den herværende oppfinnelse blir programvare kjørt i terminalen 1 og valgfritt i ICC-et 5 i form av en "virtuell datamaskin". Den virtuelle datamaskin (VM) i overensstemmelse med den herværende oppfinnelse gjør uttrykkelig tilgjengelig en teoretisk eller virtuell mikroprosessor med standardtrekk som bestemmer adresseringsmodus, stakkbruk, registerbruk, adresseområde, inn/ut-enheters adressering osv. på en generisk måte. Kjernen for hver spesiell CPU-type som benyttes i en terminal 1 eller et ICC 5, er skrevet slik at den respektive prosessorenhet 2, 12 emulerer VM-en. Det er et spesifikt aspekt ved den herværende oppfinnelse at kjernen for VM-en tilveiebringer drivere for inn/ut-enheter og alle logiske og aritmetiske lavnivå-CPU-funksjoner, strømningskon-troll, tidsbehandling. Tilveiebringelsen av inn/ut-drivere i VM-en har den fordel at hvilket som helst program som er skrevet for VM-en i overensstemmelse med den herværende oppfinnelse, adresserer standard virtuelle inn/ut-enheter. At VM-en tas i bruk på en spesiell CPU, legger da til rette for at de fysiske inn/ut-enheter tilkoplet terminalen 1 eller ICC-et 5 skal oppføre seg slik som de adresserte virtuelle inn/ut-enheter. VM-en i overensstemmelse med den herværende oppfinnelse er meget kompakt og har blitt anvendt med hell på en Siemens SLC044CR-brikke (chip) (avledning av familien INTEL 8051) som kan innbefattes i et ICC 5. VM-en i overensstemmelse med den herværende oppfinnelse muliggjør en høy grad av standardisering over vidt forskjellige CPU og I/O-typer, og gjør programbærbarhet, testing og sertifisering enklere. I overensstemmelse med den herværende anvendelse vil en slik VM bli beskrevet som en bærbar virtuell datamaskin 20. Den bærbare VM 20 innbefatter en virtuell mikroprosessor og en driver for en inn/ut-enhet. VM-en 20 tilveiebringer logiske og aritmetiske funksjoner og adressering av minne og den i det minste ene inn/ut-enhet. Den bærbare VM 20 i overensstemmelse med den herværende oppfinnelse sørger for programbærbarhet over heterogene terminaler 1 og kort 5 ved å behandle terminal- og/eller kortprogrammer som en kompilators mellomkode. Denne kode består av strømmer av bytekoder, kalt symboler. Terminaler 1 eller ICC-er 5 behandler da denne kode ved å tolke den eller ved andre midler slik som naturlig ko-dekompilering. Virtuell-datamaskin-tolking av symbolene kan fortrinnsvis gjennomføres ved én av tre fremgangsmåter: direkte tolking av virtuell-datamaskin-instruksjoner, overset-telse av den virtuelle datamaskins språk til en direkte ut-førbar mellomform, eller akkurat tidsnok kompilering av det til faktisk kode for den CPU som er målet. De to sistnevnte fremgangsmåter gir forbedret ytelse til en beskjeden kostnad når det gjelder kompleksitet. Symboler tilveiebringes i et sett som kan betraktes som maskininstruksjonssettet for VM-en 20. In accordance with the present invention, software is run in the terminal 1 and optionally in the ICC 5 in the form of a "virtual computer". The virtual computer (VM) in accordance with the present invention expressly makes available a theoretical or virtual microprocessor with standard features that determine addressing mode, stack usage, register usage, address range, I/O device addressing, etc. in a generic manner. The kernel for each particular CPU type used in a terminal 1 or an ICC 5 is written so that the respective processor unit 2, 12 emulates the VM. It is a specific aspect of the present invention that the kernel for the VM provides drivers for I/O devices and all low-level CPU logic and arithmetic functions, flow control, timing management. The provision of I/O drivers in the VM has the advantage that any program written for the VM in accordance with the present invention addresses standard virtual I/O devices. The fact that the VM is put into use on a special CPU then makes it possible for the physical I/O units connected to the terminal 1 or the ICC 5 to behave like the addressed virtual I/O units. The VM according to the present invention is very compact and has been successfully applied to a Siemens SLC044CR chip (derivative of the INTEL 8051 family) which can be included in an ICC 5. The VM according to the present invention invention enables a high degree of standardization across widely different CPU and I/O types, and makes program portability, testing and certification easier. In accordance with the present application, such a VM will be described as a portable virtual computer 20. The portable VM 20 includes a virtual microprocessor and an I/O device driver. The VM 20 provides logic and arithmetic functions and addressing of memory and the at least one I/O unit. The portable VM 20 in accordance with the present invention provides for program portability across heterogeneous terminals 1 and cards 5 by treating terminal and/or card programs as a compiler's intermediate code. This code consists of streams of byte codes, called symbols. Terminals 1 or ICCs 5 then process this code by interpreting it or by other means such as natural code decompilation. Virtual computer interpretation of the symbols can preferably be accomplished by one of three methods: direct interpretation of virtual computer instructions, translation of the virtual computer's language into a directly executable intermediate form, or just-in-time compilation of it into actual code for the CPU that is the target. The latter two approaches provide improved performance at a modest cost in terms of complexity. Symbols are provided in a set that can be considered the machine instruction set for the VM 20.

Brukerprogrammer i overensstemmelse med den herværende oppfinnelse er utformet som moduler som kan innbefatte en liste av symboler som utførbar kode. I overensstemmelse med den herværende oppfinnelse finnes det to grunntyper av moduler: utførbare moduler, som har et inngangspunkt som kalles opp direkte av VM-en 20 når modulen er innlastet, og bibliotekmo-duler som virker som ressurser for andre moduler ved å tilveiebringe eksporterbare prosedyrer som kan utføres individuelt ved oppkallinger moduler imellom. User programs in accordance with the present invention are designed as modules which can include a list of symbols as executable code. In accordance with the present invention, there are two basic types of modules: executable modules, which have an entry point that is called directly by the VM 20 when the module is loaded, and library modules that act as resources for other modules by providing exportable procedures which can be executed individually by calls between modules.

Symbolsettet i overensstemmelse med den herværende oppfinnelse innbefatter for det første VM-ens 20 instruksjonssett som tilveiebringer de ventede instruksjoner til et generelt pro- sesspråk og er nødvendige for effektiv utførelse av programmer, og for det andre symboler som tilveiebringer det som vanligvis kalles "operativsystemfunksjoner". I terminaler 1 eller kort 5 innbefatter operativsystemfunksjoner i overensstemmelse med den herværende oppfinnelse spesifikke funksjoner slik som I/O-drivere, f.eks. for displayer og tastaturer, og i terminaler 1 og kort 5 kan systemfunksjoner også innbefatte håndtering av dataobjektkommunikasjon og overføring via I/O-porter, samt tilgang moduler imellom og tilgangskontroll-mekanismer. Symboler er fortrinnsvis tilveiebrakt for VM-ens operativsystem, for stakkmanipuleringer, for kontakthåndte-ring, for styring, f.eks. unntakshåndtering, for selve kontaktene innbefattet deres tilgangsrettigheter, for inn/utenhet-tilgang, for tidshåndtering, for språk- og meldingshåndtering, for håndtering av inn/ut-lesere, f.eks. ICC, magnetstripekort og modemhåndtering, for svartelistestyring, for sikkerhetsalgoritmer, for terminaltjenester, for databasetjenester, for dataobjekthåndtering, f.eks. TLV-håndtering, for modulhåndtering og for behandling av utvidbart minne. The symbol set in accordance with the present invention includes firstly the VM's 20 instruction set which provides the expected instructions to a general process language and are necessary for efficient execution of programs, and secondly symbols which provide what are commonly called "operating system functions" . In terminals 1 or card 5, operating system functions in accordance with the present invention include specific functions such as I/O drivers, e.g. for displays and keyboards, and in terminals 1 and card 5, system functions can also include handling of data object communication and transfer via I/O ports, as well as access between modules and access control mechanisms. Symbols are preferably provided for the VM's operating system, for stack manipulations, for contact handling, for control, e.g. exception handling, for the contacts themselves including their access rights, for in/out device access, for time management, for language and message handling, for handling in/out readers, e.g. ICC, magnetic stripe card and modem management, for blacklist management, for security algorithms, for terminal services, for database services, for data object management, e.g. TLV handling, for module handling and for handling expandable memory.

En-bytes symboler blir kalt primæsymboler; disse vedrører primitive instruksjoner slik som er vanlig å finne i ethvert instruksjonssett. Flerbytes symboler blir kalt sekundærsymbo-ler og blir brukt for sjeldnere benyttede tjenester. Det kom-plette symbolsett for VM-en 20 er å finne i vedlegget. Som vist skjematisk på fig. 3, er et brukerprogram skrevet i et PC-vertutviklingssystem 70 og avluset og typegodkjent i et egnet høynivåspråk slik som Forth, C, Pascal osv. Deretter blir programmets kildekode kompilert i en symbolkompilator 71 til en strøm av symboler. Denne symbolstrøm blir kombinert separat med andre data (de motsvarende innebygde data) som trengs av programmet og et hode, og blir innkapslet i en mo-dulleveringsfil for å opprette en modul 72 fortrinnsvis i et standardisert modulleveringsformat. Dersom modulen inneholder utførbare symboler, blir den levert i det utførbare program-format. Det er et spesielt aspekt ved den herværende oppfinnelse at de utførbare moduler ikke bare inneholder symbol-strømmen, men også alle motsvarende innebygde data (innkapsling). Det er et spesielt videre og separat aspekt ved den herværende oppfinnelse at modulene i overensstemmelse med den herværende oppfinnelse inneholder en angivelse av hvor mye lese/skriveminne som VM-en 20 skal tildele modulen for utførelse. One-byte symbols are called prime symbols; these relate to primitive instructions such as are commonly found in any instruction set. Multibyte symbols are called secondary symbols and are used for less frequently used services. The complete set of symbols for the WC 20 can be found in the appendix. As shown schematically in fig. 3, a user program is written in a PC host development system 70 and debugged and type-approved in a suitable high-level language such as Forth, C, Pascal, etc. The program's source code is then compiled in a symbol compiler 71 into a stream of symbols. This symbol stream is combined separately with other data (the corresponding embedded data) needed by the program and a header, and is encapsulated in a module delivery file to create a module 72 preferably in a standardized module delivery format. If the module contains executable symbols, it is delivered in the executable program format. It is a special aspect of the present invention that the executable modules not only contain the symbol stream, but also all corresponding embedded data (encapsulation). It is a particularly further and separate aspect of the present invention that the modules in accordance with the present invention contain an indication of how much read/write memory the VM 20 should allocate to the module for execution.

Modulen 72 leveres til terminalen 1 gjennom hvilket som helst egnet middel, f.eks. i et ICC 5, via et telekommunikasjonsnettverk. Etter at en modul er lastet ned, lagres den på et "modul-oppbevaringssted". Når dens funksjon behøves, benytter terminalen 1 eller kortet 5 en symbolinnlaster/et tolkeprogram 73 til å behandle symbolene for utførelse i terminalens CPU 2. Denne prosess består i å utføre funksjonen tilknyttet hvert symbol. Symbolinnlaster/tolkeprogrammet 72 er tilveiebrakt gjennom VM-en 20 i overensstemmelse med den herværende oppfinnelse. The module 72 is delivered to the terminal 1 through any suitable means, e.g. in an ICC 5, via a telecommunications network. After a module is downloaded, it is stored in a "module repository". When its function is needed, the terminal 1 or the card 5 uses a symbol loader/interpreter program 73 to process the symbols for execution in the terminal's CPU 2. This process consists in executing the function associated with each symbol. The symbol loader/interpreter program 72 is provided through the VM 20 in accordance with the present invention.

Den VM-relaterte programvare i en terminal 1 kan deles inn i fire hovedkategorier: Kjernen, som innbefatter terminalavhengig ibruktakelse av I/O-drivere og alle de funksjoner som er nødvendige i denne spesifikasjon til støtte for VM-en 20. Enhver annen programvare relatert til VM-en 20 er skrevet med maskin-uavhengige symboler. The VM-related software in a terminal 1 can be divided into four main categories: The core, which includes terminal-dependent deployment of I/O drivers and all the functions required in this specification to support the VM 20. Any other software related to VM-en 20 is written with machine-independent symbols.

Terminalresidente tjenester (TRS) er i det minste én modul som kjøres på VM-en 20 som en brukshåndterer, og innbefatter alle ikke-bruker-funksjoner, biblioteker som støtter disse funksjoner, modulinnlastingsfunksjoner, og hovedsløyfen som bestemmer terminalens oppførsel. Spesielle symboler (f.eks. Terminal Resident Services (TRS) is at least one module that runs on the VM 20 as a user handler, and includes all non-user functions, libraries that support these functions, module loading functions, and the main loop that determines the behavior of the terminal. Special symbols (e.g.

(DIOCTL) tillater terminal-avhengige aspekter ved I/O-enheter å defineres som innebygde funksjoner. (DIOCTL) allows terminal-dependent aspects of I/O devices to be defined as built-in functions.

Terminal valgte tjenester (TSS) innbefatter anvendelser slik som betalingstjenestefunksjoner og biblioteker som støtter Terminal Selected Services (TSS) includes applications such as payment service functions and libraries that support them

disse funksjoner. TSS inneholder bare terminaluavhengige symboler og er residente i terminalen 1. TRS-hovedprogramsløyfen vil velge og kalle opp TSS-funksjoner etter behov ved en spesiell transaksjon. these functions. TSS contains only terminal-independent symbols and is resident in terminal 1. The TRS main program loop will select and call TSS functions as needed by a particular transaction.

Kortvalgte tjenester (CSS) innbefatter funksjoner som støtter terminaltransaksjoner, slik som betalingstjenestefunksjoner som blir benyttet som en del av en TSS-anvendelse. CSS er residente i et ICC 5 og lastes ned til en terminal 1 på fore-spørsel. For terminaler 1 med to ICC-lesere 8 (f.eks. én for vanlige transaksjoner og én for vedlikehold) kan det være to uavhengige sett av CSS (CSS1 og CSS2). Card Selected Services (CSS) include functions that support terminal transactions, such as payment service functions that are used as part of a TSS application. CSS is resident in an ICC 5 and is downloaded to a terminal 1 on request. For terminals 1 with two ICC readers 8 (eg one for normal transactions and one for maintenance) there may be two independent sets of CSS (CSS1 and CSS2).

I overensstemmelse med den herværende oppfinnelse er all programvare i en terminal 1 over kjernen ordnet som et sett av separate moduler. Det grunnleggende trekk ved en modul er at den er en samling av definisjoner eller programfunksjoner som er blitt ført gjennom en symbolkompilator 71 og innkapslet som en enkeltpakke for levering til et målmiljø, f.eks. en terminal 1 eller et ICC 5. Hoved-terminalprogrammet (TRS), hver anvendelse, hvert bibliotek, og hver CSS-nedlasting er eksempler på moduler. Fortrinnsvis benytter alle moduler et standardformat. Kjernen i et system ifølge den herværende oppfinnelse definerer VM-en 20 som tilveiebringer forskjellige høynivåtjenester til disse moduler, slik som -universal-CPU og instruksjonssett, representert ved symboler; - universal-I/O-støtte for vanlige utstyrsenheter, med til-rettelegging for generisk I/O til støtte for tilleggsenheter In accordance with the present invention, all software in a terminal 1 above the core is arranged as a set of separate modules. The basic feature of a module is that it is a collection of definitions or program functions that have been passed through a symbol compiler 71 and encapsulated as a single package for delivery to a target environment, e.g. a terminal 1 or an ICC 5. The main terminal program (TRS), each application, each library, and each CSS download are examples of modules. Preferably, all modules use a standard format. The core of a system according to the present invention defines the VM 20 which provides various high-level services to these modules, such as -universal-CPU and instruction set, represented by symbols; - universal I/O support for common hardware devices, with provision for generic I/O to support additional devices

som kan bli tilføyd; - databasehåndteringsfunksjoner; - dataobjektoverføringshåndtering, innbefattet formatkonver-teringer og andre funksjoner; - håndtering av symbolmoduler, innbefattet bevaring av disse i lager (oppdatering etter behov) og utførelse av dem på forespørsel. I en foretrukket utførelse av den herværende oppfinnelse forblir utførelsen av moduler under VM-ens 20 styring til enhver tid. Videre tar moduler aldri styringen over vertsprosessoren, men er bare passive i forhold til VM-en 20. Fortrinnsvis er VM-en 20 alltid virksom i privilegert modus og kan bare utføre instruksjoner definert i form av dens symbolsett, og ingen modul kan operere i brukermodus, dvs. ta kontroll over VM-en 20. Ved en implementering av VM-en 20 hvor det benyttes minneliste, opprettes bare én minneliste, nemlig den overordnede liste. which may be added; - database management functions; - data object transfer handling, including format conversions and other functions; - handling of symbol modules, including keeping them in stock (updating as needed) and executing them on request. In a preferred embodiment of the present invention, the execution of modules remains under the control of the VM 20 at all times. Furthermore, modules never take control of the host processor, but are only passive with respect to the VM 20. Preferably, the VM 20 always operates in privileged mode and can only execute instructions defined in terms of its symbol set, and no module can operate in user mode. , i.e. take control of the VM 20. In an implementation of the VM 20 where a memory list is used, only one memory list is created, namely the parent list.

Ingen modul kan kompromittere operativsystemet definert gjennom VM-en 20. Dette garanteres fordi en modul bare kan inneholde symboler fra VM-symbolsettet, og ingen av disse symboler muliggjør tilgang til kodeområdet hvor kjernen er lagret. Dersom VM-en 20 støter på et symbol som ligger utenfor det definerte sett, fremsettes et unntak (ILLOP). No module can compromise the operating system defined through the VM 20. This is guaranteed because a module can only contain symbols from the VM symbol set, and none of these symbols enable access to the code area where the kernel is stored. If the VM 20 encounters a symbol that is outside the defined set, an exception (ILLOP) is raised.

Som vist skjematisk på fig. 4, innbefatter terminal 1 det terminalspesifikke operativsystem 80 som er ansvarlig for innlasting av VM-ens 20 TRS-modul (innlastingsprosedyre blir beskrevet senere). Kode for VM-en 20 lagres i terminalens ikke-flyktige leseminne 11. Før innlasting av TRS er et flyktig terminalminne 19 i terminalen 1 tomt for alle transak-sjonsrelaterte data, terminalens ikke-flyktige lese/skrive-minne 18 inneholder de anvendelser som skal utføres av VM-en 20 i form av moduler 72 på et moduloppbevaringssted, hvor de ikke-flyktige databaser inneholder brukerspesifikke data og biblioteker slik som pluggbiblioteket som vil bli beskrevet senere. Dersom VM-en 20 også anvendes på et ICC 5, gjelder de samme prinsipper som beskrevet ovenfor, med hensyn til ICC-ets 5 ikke-flyktige leseminne 13, flyktige minne 14 og ikke-flyktige lese/skrive-minne 15. As shown schematically in fig. 4, terminal 1 includes the terminal-specific operating system 80 which is responsible for loading the VM's 20 TRS module (loading procedure is described later). Code for the VM 20 is stored in the terminal's non-volatile read memory 11. Before loading the TRS, a volatile terminal memory 19 in the terminal 1 is empty of all transaction-related data, the terminal's non-volatile read/write memory 18 contains the applications to is performed by the VM 20 in the form of modules 72 in a module storage location, where the non-volatile databases contain user-specific data and libraries such as the plug-in library which will be described later. If the VM 20 is also used on an ICC 5, the same principles as described above apply, with regard to the ICC's 5 non-volatile read memory 13, volatile memory 14 and non-volatile read/write memory 15.

Siden VM 20 er en virtuell datamaskin, adresserer den alle former for terminal- eller ICC-minne 11, 18, 19, 13, 14, 15 som virtuelt minne, dvs. de blir alle adressert i logisk-adresse-område slik det sees fra VM-en 20. Ved en faktisk implementering av VM-en 20 blir disse logisk-adresse-områder listet inn i faktiske adresseområder i minnet i terminalen 1 eller ICC-et 5 via en lagerliste eller lignende. I nedenstående vil det bli vist til flyktig, ikke-flyktig lese/skrive-og ikke-flyktig leseminne som at det er en del av VM-en 20. Det skal forstås at dette gjelder logisk adressert minneområde med mindre det spesielt er nevnt faktiske adresser ved ibruktakelse av VM-en 20 på en terminal 1 eller ICC 5. Flyktig minne overlever ikke programinnlasting eller strømutkopling og/eller gjenoppstarting. Fortrinnsvis overlever ikke flyktig minne strømutkopling av sikkerhetsmessige grunner. Ikke-flyktig minne overlever programinnlasting eller strømutkop-ling eller gjenoppstarting. Since VM 20 is a virtual computer, it addresses all forms of terminal or ICC memory 11, 18, 19, 13, 14, 15 as virtual memory, i.e. they are all addressed in logical-address space as seen from The VM 20. In an actual implementation of the VM 20, these logical address areas are listed into actual address areas in the memory of the terminal 1 or the ICC 5 via a storage list or the like. In the following, volatile, non-volatile read/write and non-volatile read memory will be shown as being part of the VM 20. It should be understood that this applies to logically addressed memory areas unless actual addresses are specifically mentioned when commissioning the VM 20 on a terminal 1 or ICC 5. Volatile memory does not survive program loading or power disconnection and/or restart. Preferably, volatile memory does not survive power failure for security reasons. Non-volatile memory survives program loading or power-off or reboot.

En skjematisk fremstilling av VM-en 20 i overensstemmelse med den herværende oppfinnelse er vist på fig. 5. Fortrinnsvis er VM-en 20 en stakkmaskin og har en datastakkpeker (lagret i et datastakkpekerregister 32) som peker på en magasindatastakk A schematic representation of the VM 20 in accordance with the present invention is shown in fig. 5. Preferably, the VM 20 is a stack machine and has a data stack pointer (stored in a data stack pointer register 32) that points to a magazine data stack

27 fortrinnsvis i minne på brikke (chip). Alle operasjoner blir utført på denne stakk 27. Datastakken 27 blir benyttet til å inneholde parametere for prosedyrer og midlertidige re-sultater fra uttrykksvurdering. Data blir skjøvet inn på el ler hentet ut fra datastakken 27. VM-en 20 innbefatter også en returstakk 28. Returstakken 28 kan benyttes av VM-en 20 til å inneholde returadresser og kan også benyttes til midlertidig lagring. Denne flerstakksarkitektur er kjent fra programmeringsspråket Forth (ANSI X3.215-1994) . Arkitekturen er blitt modifisert ytterligere for bærbarhet, kodetetthet, sikkerhet, kompileringsvennlighet, og for bruk sammen med andre programmeringsspråk. For eksempel inneholder den tiltak for lokale variable rammer benyttet i høynivåprogrammerings-språk, slik som C. Symbolkompilatorer 71 i overensstemmelse med den herværende oppfinnelse kan således bli skrevet ikke bare for Forth, men også for C og andre programmeringsspråk. 27 preferably in memory on a chip. All operations are performed on this stack 27. The data stack 27 is used to contain parameters for procedures and temporary results from expression evaluation. Data is pushed onto or extracted from the data stack 27. The VM 20 also includes a return stack 28. The return stack 28 can be used by the VM 20 to contain return addresses and can also be used for temporary storage. This multi-stack architecture is known from the programming language Forth (ANSI X3.215-1994). The architecture has been further modified for portability, code density, security, compilability, and for use with other programming languages. For example, it contains measures for local variable frames used in high-level programming languages, such as C. Symbol compilers 71 in accordance with the present invention can thus be written not only for Forth, but also for C and other programming languages.

I overensstemmelse med den herværende oppfinnelse er det bare én data- og returstakk 27, 28 tilknyttet VM-en 20. Data- og In accordance with the present invention, there is only one data and return stack 27, 28 associated with the VM 20. Data and

returstakkene 27, 28 er ikke opprettet for hver prosesskjede. I overensstemmelse med den herværende oppfinnelse kan brukerprogrammer bare hente fra returstakken 28 det de uttrykkelig har lagt til stakken innenfor den pågående prosedyre, og de the return stacks 27, 28 are not created for each process chain. In accordance with the present invention, user programs can only retrieve from the return stack 28 what they have explicitly added to the stack within the current procedure, and they

må fjerne data plassert i returstakken 28 under den pågående prosedyre før de avslutter prosedyren. Valgfritt innbefatter VM-en 20 en sikkerhetsbehandler for å sørge for sikkerhet på kjøretidspunktet, hvilken overvåker enhver aktivitet i returstakken og kontrollerer at alle data er fjernet under den pågående prosedyre. I tillegg til data som er plassert der uttrykkelig for midlertidig lagring, kan VM-en 20 holde informasjon om unntaksutførelsestilstand, rammer for lokale variabler, sløyfekontrollparametere og databasesammenheng i returstakken 28. must remove data placed on the return stack 28 during the current procedure before terminating the procedure. Optionally, the VM 20 includes a security handler to provide security at run time, which monitors any activity in the return stack and checks that all data has been removed during the current procedure. In addition to data placed there expressly for temporary storage, the VM 20 may hold information about exception execution state, local variable frames, loop control parameters, and database context in the return stack 28 .

I overensstemmelse med den herværende oppfinnelse, kan VM-en 20 innbefatte en flerhet av stakker. Snarere enn bare å bruke returstakken 28, kan, for eksempel, valgfritt ytterligere stakker 29 tilveiebringes, slik som unntaks- og rammestakker. En unntaksstakk brukes til å lagre utførelsestilstand under en unntaksbehandling. En rammestakk benyttes til å holde på informasjon om lokale variabler, så vel som C-språk-lignende aktiveringsposter. Som nevnt ovenfor, kan unntaks- og ramme-stakkene 29 implementeres på returstakken 28. In accordance with the present invention, the VM 20 may include a plurality of stacks. Rather than just using the return stack 28, for example, optionally additional stacks 29 may be provided, such as exception and frame stacks. An exception stack is used to store execution state during an exception handling. A frame stack is used to hold information about local variables, as well as C language-like activation records. As mentioned above, the exception and frame stacks 29 can be implemented on the return stack 28.

Data-, returstakkene 27, 28 og andre stakker 29 slik som unn-taksstakken er ikke i et minneområde som et brukerprogram har direkte tilgang til. Data- eller returstakkene 27, 28 kan ikke adresseres direkte, de er bare tilgjengelige via stakkeoperasjoner. Av sikkerhetsmessige grunner er det ingen begrensning på hvordan dataene blir lagret ved en faktisk implementering, slik at en ondsinnet person ikke kan anta hvordan dataene blir lagret fysisk. VM-en 20 innbefatter en virtuell prosessorenhet 22 som innbefatter en virtuell aritmetisk logisk enhet 23. VM-en 20 adresserer et virtuelt eller logisk dataområde 24 som av VM-en 20 blir behandlet som et arbeidsminne (RAM), og ville normalt bli implementert som en del av det flyktige minne 19, f.eks. i RAM i en faktisk terminal 1 eller et kort 5. Det logiske dataområde 24 er tilgjengelig kun til lagring av data. En moduls symbolstrøm'lagres av VM-en 20 i kodeminne 26 som behandles som et leseminne (ROM) av VM-en 20. Bare VM-en 20 kan lese symbolene. Kodeminnet 26 er verken tilgjengelig for brukerprogrammer eller gjennom noe som helst symbol. VM-en 20 kan innbefatte virtuelle registre 30. VM-ens 20 registre 30 kan innbefatte symbolpekerregister 31 som har pekeren som peker på det neste symbol som skal utføres, datastakkpekerregister 32 som har pekeren som peker på den gjeldende topp av datastakken 27 (TOS), returstakkpekerregis- ter 33 som har pekeren som peker på den gjeldende topp av re-turstakkstedet, rammepekerregister 34 som har pekeren som peker på rammestarten i dataområde 24, rammeendepekerregister 35 som har pekeren som peker på rammeenden i dataområde 24. Det er ikke tilveiebrakt noen direkte tilgang til registrene 31 til 36 gjennom symbolsettet, men bare via registertil-gangsymbolene. The data, return stacks 27, 28 and other stacks 29 such as the exception stack are not in a memory area to which a user program has direct access. The data or return stacks 27, 28 are not directly addressable, they are only accessible via stack operations. For security reasons, there is no restriction on how the data is stored in an actual implementation, so that a malicious person cannot guess how the data is physically stored. The VM 20 includes a virtual processor unit 22 which includes a virtual arithmetic logic unit 23. The VM 20 addresses a virtual or logical data area 24 which is treated by the VM 20 as a random access memory (RAM), and would normally be implemented as part of the volatile memory 19, e.g. in RAM in an actual terminal 1 or a card 5. The logical data area 24 is available only for storing data. A module's symbol stream is stored by the VM 20 in code memory 26 which is treated as a read-only memory (ROM) by the VM 20. Only the VM 20 can read the symbols. The code memory 26 is neither accessible to user programs nor through any symbol whatsoever. The VM 20 may include virtual registers 30. The VM 20 registers 30 may include symbol pointer register 31 which has the pointer pointing to the next symbol to be executed, data stack pointer register 32 which has the pointer pointing to the current top of the data stack 27 (TOS) , return stack pointer register 33 having the pointer pointing to the current top of the return stack location, frame pointer register 34 having the pointer pointing to the frame start in data area 24, frame end pointer register 35 having the pointer pointing to the frame end in data area 24. There are no provided direct access to registers 31 to 36 through the symbol set, but only via the register access symbols.

Endelig er de virtuelle inn/ut-enheter 25 lenket til CPU-en 22 gjennom et virtuell-buss-system 21 som også forbinder stakkene 27-29, ALU 23, registrene 30, kodeminnet 26 og dataområdet 24. Finally, the virtual I/O units 25 are linked to the CPU 22 through a virtual bus system 21 which also connects the stacks 27-29, the ALU 23, the registers 30, the code memory 26 and the data area 24.

VM 20 i overensstemmelse med den herværende oppfinnelse er definert fortrinnsvis■som en byteadressert, toerkomplement 32-bits maskin, med 32-bits registre og stakkelementer, men oppfinnelsen er ikke begrenset til disse. Register/stakk-størrelsen blir kalt cellestørrelsen for VM-en 20, hvor en celle er grunnenheten for manipulering i stakkene, og gjennom VM-registrene 31 til 36. Størrelsen på cellen benyttet av VM-en 20 blir ikke ansett for å ha avgjørende virkning på den herværende oppfinnelse. VM 20 in accordance with the present invention is preferably defined as a byte-addressed, two's complement 32-bit machine, with 32-bit registers and stack elements, but the invention is not limited to these. The register/stack size is called the cell size for the VM 20, where a cell is the basic unit of manipulation in the stacks, and through the VM registers 31 to 36. The size of the cell used by the VM 20 is not considered to have a decisive effect on the present invention.

Alle programmer som kjøres fra moduler, må overholde følgende regler: - Programmer kan ikke anta at dataene i noen av de ovennevnte kategorier garanteres holdt i returstakken 28, og kan derfor bare bruke den uthentingsmekanisme som uttrykkelig er angitt for en gitt kategori, da sikkerhetsbehandleren kan slette eventuelle slike data. - Programmer som overfører data i én av disse kategorier til VM-en 20, må fatte tiltak for å gjenvinne datalageret fra VM- en 20 før de avslutter prosedyren som dataene overføres i, ellers vil VM-en 20 fraordne den relevante del av minnet. - Programmer må anta at hvilke som helst data som tidligere ble plassert i returstakken 28, gjøres utilgjengelige ved overføring av data i én av disse kategorier til VM-en 20. - Programmer må anta at hvilke som helst data i én av disse kategorier overført til VM-en 20, gjøres utilgjengelige gjennom utførelseskode som plasserer verdier på returstakken 28, inntil den tid når disse verdier blir fjernet, fordi returstakken bare er tilgjengelig gjennom de angitte symbolprose-dyrer. All programs executed from modules must adhere to the following rules: - Programs cannot assume that the data in any of the above categories is guaranteed to be held on the return stack 28, and therefore can only use the retrieval mechanism explicitly specified for a given category, as the security handler can delete any such data. - Programs that transfer data in one of these categories to the VM 20 must take steps to reclaim the data store from the VM 20 before terminating the procedure in which the data is transferred, otherwise the VM 20 will deallocate the relevant part of memory. - Programs must assume that any data that was previously placed in the return stack 28 is made unavailable by transferring data in one of these categories to the VM 20. - Programs must assume that any data in one of these categories transferred to The VM 20 is made unavailable through execution code that places values on the return stack 28, until the time when these values are removed, because the return stack is only accessible through the indicated symbol procedures.

I overensstemmelse med den herværende oppfinnelse definerer VM-ens 20 operativsystem et enkelt adresseområde 24 tilgjengelig for hver modul. Dette adresseområde 24 skal være tilgjengelig kun for lagring av data og vil derfor bli kalt "dataområde" 24. In accordance with the present invention, the VM's 20 operating system defines a single address range 24 available for each module. This address area 24 shall be available only for storing data and will therefore be called "data area" 24.

Dataområdet 24 er delt inn i tre og ett valgfrie logiske felter, som hver er individuelt tilstøtende: 1. Initialisert dataområde 41, som inneholder initialverdier angitt på kompileringstidspunktet og fastsatt når VM-kjernen aktiveres og deretter når en modul som inneholder initialiserte data, blir lastet inn. 2. Ikke initialisert dataområde 42, som inneholder variabler og statiske buffere som er tildelt under programkompile-ring. Dette dataområde 42 er initialisert til null av VM-en 20. The data area 24 is divided into three and one optional logical fields, each of which is individually contiguous: 1. Initialized data area 41, which contains initial values set at compile time and determined when the VM kernel is activated and then when a module containing initialized data is loaded in. 2. Uninitialized data area 42, which contains variables and static buffers allocated during program compilation. This data area 42 is initialized to zero by the VM 20.

3. Rammeminne 4 6 som håndteres av rammesymbolene.3. Frame memory 4 6 which is handled by the frame symbols.

4. Valgfritt: utvidbart minne 45, som inneholder én eller flere buffere som er tildelt dynamisk under programutfø-relse. 4. Optional: expandable memory 45, containing one or more buffers dynamically allocated during program execution.

Det finnes to dataområder i tillegg, som ikke kan adresseres direkte: 5. Utvidet minne 43, typisk masselager som benyttes til å inneholde dataobjekter og flyktige databaser; 6. Ikke-flyktig minne 44 blir benyttet til å inneholde data som av VM-en 20 garanteres å overleve modulinnlasting eller strømutkopling og gjenoppstarting (innenfor terminal-maskinvarens begrensninger), innbefattet moduloppbevaringsstedet og de ikke-flyktige databaser. Dette kan implementeres med batteristøttet RAM, disk, eller annet varig lager. Ikke-flyktig minne 44 kan implementeres som en del av det permanente lese/skriveminne 18. There are two data areas in addition, which cannot be directly addressed: 5. Extended memory 43, typically mass storage used to contain data objects and volatile databases; 6. Non-volatile memory 44 is used to contain data guaranteed by the VM 20 to survive module loading or power-off and reboot (within the limitations of the terminal hardware), including the module storage location and the non-volatile databases. This can be implemented with battery-backed RAM, disk, or other permanent storage. Non-volatile memory 44 may be implemented as part of the permanent read/write memory 18.

For å øke datasikkerheten, er det utvidede og ikke-flyktige minne 43, 44 tilgjengelig bare gjennom symboler som tilveiebringer "vinduer" til valgte data i form av buffere i ikke-initialisert dataområde 42. Videre kan en programmerer bare be om en post og får ikke vite den nøyaktige plassering av data slik at han kan gå inn i disse. Fortrinnsvis finnes det ikke noen fil- eller trestruktur som tillater programmereren å lokalisere personlige filer eller databaser. To increase data security, the extended and non-volatile memory 43, 44 is accessible only through symbols that provide "windows" to selected data in the form of buffers in uninitialized data area 42. Further, a programmer can only request a record and receive not knowing the exact location of data so that he can enter them. Preferably, there is no file or tree structure that allows the programmer to locate personal files or databases.

Innenfor hvert dataområde 24 benyttet av en modul, blir minne tildelt gjennom relativ adressering og bare på kjøretidspunk-tet. Dette betyr at en adresse bare har mening innenfor hver modul når den er lastet inn. Siden absolutt adressering ikke benyttes, er det ikke mulig for en modul å få tilgang til en annen moduls data, bortsett fra gjennom de sikre modultil-gangsmekanismer som blir beskrevet senere. Within each data area 24 used by a module, memory is allocated through relative addressing and only at runtime. This means that an address only has meaning within each module when it is loaded. Since absolute addressing is not used, it is not possible for a module to gain access to another module's data, except through the secure module access mechanisms that will be described later.

Rammemekanismen tillater VM-en 20 å oppfylle kravene om språk slik som C som tillater lokale variabler å defineres på kjø-retidspunktet. En ramme holder prosedyreparametere overført i datastakken 27 så vel som "lokale" variabler (midlertidig da-talagring som skal frigjøres automatisk når rammen utløses, vanligvis ved slutten av en prosedyreutførelse). Rammestart-og rammeendepekere blir bevart automatisk av VM-en 20 innenfor rammen. Rammepekerregisteret 34 peker på den logiske bunn av rammen, og rammeendepekeren 35 peker på rammens logiske ende i dataområde 24. Parametere kan hentes fra rammen ved bruk av rammetilgangssymbolene. The framework mechanism allows the VM 20 to meet the requirements of languages such as C that allow local variables to be defined at runtime. A frame holds procedure parameters transferred in the data stack 27 as well as "local" variables (temporary data storage to be freed automatically when the frame is triggered, usually at the end of a procedure execution). Frame start and frame end pointers are preserved automatically by the VM 20 within the frame. The frame pointer register 34 points to the logical bottom of the frame, and the frame end pointer 35 points to the logical end of the frame in data area 24. Parameters can be retrieved from the frame using the frame access symbols.

VM-en 20 kan valgfritt tilveiebringe en dynamisk tildelt samling av utvidbart minne 45 som en enkel utvidbar buffer håndtert av VM-en 20, hvilken forekommer utenfor programmets The VM 20 may optionally provide a dynamically allocated pool of expandable memory 45 as a single expandable buffer managed by the VM 20, which occurs outside of the program's

ikke-initialiserte dataområde 42. Programmer kan be om tildeling av en spesifisert mengde utvidbart minne 45, og får tilbake en peker mot en basisadresse for minnet 45. Deretter kan programmer frigjøre minne 45 fra en gitt adresse, f.eks. ved avslutning av programmet, hvorved aile tildelinger ut over den adresse frigjøres. uninitialized data area 42. Programs can request allocation of a specified amount of expandable memory 45, and receive back a pointer to a base address of the memory 45. Then, programs can release memory 45 from a given address, e.g. at the end of the program, whereby all allocations beyond that address are released.

Det foretrekkes dersom moduler blir utført i et enkelt-kjede, men oppfinnelsen er ikke begrenset til dette. Dette betyr at dersom én modul kaller opp en annen modul, avslutter den andre modul, og alle ressurser i den andre modul fraordnes før VM-en 20 returnerer til den første modul og fortsetter behandling. Fig. 6 viser en skjematisk fremstilling av logisk minne slik det sees av VM-en 20. Som vist skjematisk på fig. 6, er en første modul (til venstre) med initialisert minne 41, ikke-initialisert minne 42 og rammeminne 46 og symbolko-deminne 26 blitt lastet inn i lese/skriveminnet som begynner ved adresse 1. Den første modul har også kallet opp og blitt tildelt et parti 45 av den utvidbare buffer. Når den andre modul (til høyre) blir kalt opp av den første modul (f.eks. for å importere funksjonen fgh som finnes i den eksklusive liste i modulens 1 hode med funksjoner som kan importeres), blir dataområde 24' innbefattet initialisert minne 41', ikke-initialisert minne 42' og rammeminne 46' tildelt som nødven-dig, idet de begynner ved adresse 2. Modulens 2 symboler blir lest direkte av VM-en 20 fra moduloppbevaringsstedet som er en mulighet som tillates i overensstemmelse med den herværende oppfinnelse. Dersom det utvidbare minne 45' for den andre modul kalles opp av modul 2, blir det tildelt av VM-en 20 høyere oppe i minnet enn det utvidbare minne 45 for den før-ste modul. Når den andre modul er fullført, blir alt minne ovenfor adresse 4 fraordnet ("strikkeffekt"). Fortrinnsvis blir alle midlertidig lagrede data slettet ved fraordning. Om nødvendig ville deretter mer utvidbart minne 45 kunne kalles opp ved retur til den første modul. Dersom den andre modul deretter kalles opp igjen, vil den bli tildelt en annerledes startadresse for det utvidbare minne 45' enn første gang den ble oppkalt.- It is preferred if modules are carried out in a single chain, but the invention is not limited to this. This means that if one module calls up another module, the second module terminates, and all resources in the second module are allocated before the VM 20 returns to the first module and continues processing. Fig. 6 shows a schematic representation of logical memory as seen by the VM 20. As shown schematically in fig. 6, a first module (left) with initialized memory 41, uninitialized memory 42 and frame memory 46 and symbol code memory 26 has been loaded into the read/write memory starting at address 1. The first module has also called up and been allocated to a lot 45 of the expandable buffer. When the second module (on the right) is called by the first module (e.g. to import the function fgh found in the exclusive list in the module 1 head of functions that can be imported), data area 24' includes initialized memory 41 ', uninitialized memory 42' and frame memory 46' allocated as necessary, starting at address 2. The symbols of the module 2 are read directly by the VM 20 from the module storage location which is a possibility permitted in accordance with the present invention . If the expandable memory 45' for the second module is called up by module 2, it is allocated by the VM 20 higher up in the memory than the expandable memory 45 for the first module. When the second module is completed, all memory above address 4 is allocated ("knitting effect"). Preferably, all temporarily stored data is deleted upon opt-out. If necessary, more expandable memory 45 could then be called upon returning to the first module. If the second module is then called up again, it will be assigned a different start address for the expandable memory 45' than the first time it was called up.-

Alle symboler bortsett fra symbolene EXTEND, CEXTEND og RELEASE til håndtering av det utvidbare minne samt unntaks-håndteringssymbolene THROW og QTHROW skal ikke ha noen netto-innvirkning på pekeren for det utvidbare minne. Dersom et symbol tildeler utvidbart minne 45, må det også frigjøre det, innbefattet eventuell virkning av celleinnretting. Suksessive tildelinger av utvidbart minne 45 er fortrinnsvis tilstøtende innenfor en modul, men behøver ikke være tilstøtende moduler imellom, bortsett fra at anrop mellom moduler, hvor symbolene IMCALL eller DOSOCKET benyttes, skal bevare tilstøting. En automatisk frigjøring av dynamisk tildelt utvidbart minne 45 skal skje når en moduls utførelse er fullført, hvilket begrenser virkningen av en programsvikt i fullstendig frigjø-ring av minne. Dersom en THROW-unntakssituasjon oppstår, kan i tillegg tildelingen av dynamisk tildelt utvidbart minne 45 gjenopprettes til dettes tilstand på tidspunktet for den rå-dende CATCH-unntakssituasjon. All symbols except the EXTEND, CEXTEND, and RELEASE symbols for handling the extensible memory and the exception handling symbols THROW and QTHROW shall have no net effect on the extensible memory pointer. If a symbol allocates expandable memory 45, it must also free it, including any effect of cell alignment. Successive allocations of expandable memory 45 are preferably contiguous within a module, but need not be contiguous between modules, except that calls between modules, where the symbols IMCALL or DOSOCKET are used, must preserve contiguity. An automatic freeing of dynamically allocated expandable memory 45 should occur when a module's execution is complete, limiting the impact of a program failure in completely freeing memory. If a THROW exception situation occurs, the allocation of dynamically allocated expandable memory 45 can additionally be restored to its state at the time of the prevailing CATCH exception situation.

Brukervariabler er variabler av cellestørrelsevariabler hvor VM-en 20 holder informasjon som har sammenheng med kunde-programmer. Lager for brukervariabler er forhåndstildelt av VM-en 20. Et begrenset antall variabler kan være tilveiebrakt, f.eks. seksten variabler (henvises til som 0 til 15). En implementering av VM 20 som støtter fleroppgavekjøring, kan tilveiebringe ett sett brukervariabler for hver oppgave. User variables are variables of cell size variables where the VM 20 holds information related to customer programs. Storage for user variables is pre-allocated by the VM 20. A limited number of variables may be provided, e.g. sixteen variables (referred to as 0 to 15). An implementation of VM 20 that supports multitasking may provide one set of user variables for each task.

VM-en 20 tilveiebringer en enkelt unntakshåndteringsmekanisme via symbolene CATCH, THROW og QTHROW. Disse symboler er avle-det fra Lisp-unntakshåndteringsmekanismen og fremkommer i ANS Forth som CATCH og THROW. Formålet med denne mekanisme er å The VM 20 provides a single exception handling mechanism via the symbols CATCH, THROW, and QTHROW. These symbols are derived from the Lisp exception handling mechanism and appear in ANS Forth as CATCH and THROW. The purpose of this mechanism is to

legge til rette for lokal håndtering av unntakssituasjoner under programstyring på ulike nivåer i programvaren. Tanken er at programmet fører en funksjons utførelsespeker til symbolet CATCH, hvilket vil utføre den funksjon og returnere en kode som angir hvilken, i tilfelle noen, unntakssituasjon som dukket opp under utførelsen. CATCH registrerer tilstrekkelig implementeringsavhengig informasjon til å gjenopprette sin nåværende utførelsestilstand dersom en THROW skulle dukke opp i den funksjon som overføres til CATCH for utførelse. Dette innbefatter (men er ikke begrenset til) data og returstakk-dybder, rammepekeren og, i noen tilfeller, pekeren for det utvidbare minne. Samlingen av opplysninger som representerer facilitate local handling of exceptional situations during program management at various levels in the software. The idea is that the program moves a function's execution pointer to the symbol CATCH, which will execute that function and return a code indicating which, if any, exception occurred during execution. CATCH records sufficient implementation-dependent information to restore its current state of execution should a THROW occur in the function passed to CATCH for execution. This includes (but is not limited to) data and return stack depths, the frame pointer and, in some cases, the expandable memory pointer. The collection of information that represents

en utførelsestilstand, kalles en "unntakssituasjonsramme" . Unntakssituasjonsrammer blir oppbevart i unntakssitua-sjonsstakken. Etter en CATCH kan programmet undersøke enhver unntakssituasjonskode som måtte være blitt returnert, og velge å behandle den lokalt eller THROW den til et høyere nivå for behandling. VM-en 20 sørger for et standard-ytternivå hvor unntakssituasjoner vil bli avsperret. Dette ytternivå vil bli aktivert når det ikke er blitt opprettet noe innerni-vå for CATCH. Standard-unntakssituasjon-behandleren avbryter enhver pågående terminaltransaksjon og forsøker å laste inn igjen TRS-moduler og gå inn i TRS-hovedsløyfen igjen. VM-en 20 fremsetter ANS-Forth-unntakssituasjon -10 (deling på null) dersom den situasjon skulle oppstå. VM-en 20 kan fremsette andre generelle unntakssituasjoner støttet av ANS Forth, f.eks. som oppgitt i det vedføyde vedlegg. an execution state, is called an "exception frame". Exception frames are stored in the exception stack. After a CATCH, the program can examine any exception condition code that may have been returned and choose to process it locally or THROW it to a higher level for processing. VM-en 20 provides a standard outer level where exceptional situations will be blocked off. This outer level will be activated when no inner level has been created for CATCH. The standard exception handler aborts any terminal transaction in progress and attempts to reload TRS modules and re-enter the main TRS loop. The VM 20 presents the ANS-Forth exception situation -10 (division by zero) should that situation occur. VM-en 20 can present other general exception situations supported by ANS Forth, e.g. as stated in the attached appendix.

For håndteringsenheter og inn/ut-tjenester, er hver utstyrsenhet, innbefattet de utstyrsenheter hvis operasjon på lavere nivå er skjult av VM-en 20 bak enhetsspesifikke funksjoner, tilordnet en enhetstype (benyttet til å kategorisere resul-tatkoder) og et unikt enhetsnummer. Enhetsnumre er vilkårli-ge; men henvisninger til enhetsnumre -1 til og med 15 (4 biter) kan gjøres med bare ett enkelt symbol, og derfor er disse tildelt de vanligste tjenester slik som tastaturer, ICC-lesere, lesere for magnetstripekort, displayer, skrivere, strømstyringsinnretninger eller salgsautomater. Generelle I/O-muligheter er tilveiebrakt gjennom funksjoner som tar en-hetsnummeret som en inn-parameter. For handling units and I/O services, each equipment unit, including those equipment units whose lower-level operation is hidden by the VM 20 behind unit-specific functions, is assigned a unit type (used to categorize result codes) and a unique unit number. Unit numbers are arbitrary; but references to device numbers -1 through 15 (4 bits) can be made with just a single symbol, and so these are assigned to the most common services such as keyboards, ICC readers, magnetic stripe card readers, displays, printers, power management devices, or vending machines. General I/O capabilities are provided through functions that take the device number as an input parameter.

En terminal 1 i overensstemmelse med den herværende oppfinnelse inneholder fortrinnsvis i det minste tre større ikke-flyktige databaser: en bruksspesifikk transaksjonslogg, en database for meldinger på ett eller flere språk og en modul database. VM-en 20 beskytter databaser så mye som mulig, da de kan inneholde fortrolige opplysninger. Tilgang til databaser er begrenset. VM-en 20 tilveiebringer en mekanisme til håndtering av databaser (VM-en 20 som "tjener") som skjuler implementeringsdetaljer fra bruksprogramvaren (bruk som "kunden"). Ingen direkte tilgang til databasen tillates fra en modul som kjøres på VM-en 20. Tjenestene tar i bruk følgende trekk som vil bli beskrevet under henvisning til fig. 7: - På hvilket som helst gitt tidspunkt har kunden, dvs. et program som kjøres i en modul, tilgang til én for øyeblikket valgt database (DBCURRENT) og ett for øyeblikket valgt postnummer (DBRECNUM) som er felles for alle definerte databaser. - Informasjon om hver database blir overført mellom kunde og tjener gjennom en databaseparameterblokk (DPB) 51 som tjeneren kan få tilgang til for lesing og skriving. Kunden "eier" DPB-en 51 i den forstand at den er i kundens dataområde 24, men kunden tillates ikke direkte tilgang. I stedet kan bare databasetjenestesymboler benyttes for tilgang til dataene. DPB-en 51 har en standardstruktur som innbefatter felter for i det minste en DPB-lenke, en databasepeker, en angivelse av databasetype og av poststørrelse og det neste tilgjengelige postnummer. All informasjon til.spesifisering av en database må finnes i DPB-en 51. Kundeprogramvare får ikke utføre noen påfølgende direkte tilgang til DPB-en 51 og må ikke gjøre no-en antakelser om de verdier som holdes direkte i DPB-en 51 etter at modulen som definerer den DPB 51, er blitt lastet inn for utførelse. Databaseparameterblokker 51 blir overført til symbolinnlasteren/tolkeprogrammet i form av en peker (DPB-lenke) til en dertil lenket liste i en moduls initialiserte dataseksjon. Dette felt må forhåndsbestemmes til adressen i initialiserte data i den neste DPB 51 på listen; eller null dersom denne DPB 51 er den siste eller den eneste DPB 51 på listen. For kompilerte databaser som finnes i kundens initialiserte dataområde, må DB-pekeren være forhåndssatt til "opprinnelses"adressen i initialiserte data. For databaser hvis lagring styres av tjeneren, må feltet forhåndsbestemmes til null. DB-typen tilveiebringer detaljer i databasen i kodet form. Det finnes i det minste tre slags databaser: A terminal 1 in accordance with the present invention preferably contains at least three major non-volatile databases: a use-specific transaction log, a database for messages in one or more languages and a module database. The VM 20 protects databases as much as possible, as they may contain confidential information. Access to databases is limited. The VM 20 provides a database management mechanism (the VM 20 as the "server") that hides implementation details from the application software (use as the "client"). No direct access to the database is permitted from a module that runs on the VM 20. The services use the following features which will be described with reference to fig. 7: - At any given time, the customer, i.e. a program running in a module, has access to one currently selected database (DBCURRENT) and one currently selected postal code (DBRECNUM) which is common to all defined databases. - Information about each database is transferred between client and server through a database parameter block (DPB) 51 that the server can access for reading and writing. The customer "owns" the DPB 51 in the sense that it is in the customer's data area 24, but the customer is not allowed direct access. Instead, only database service symbols can be used to access the data. The DPB 51 has a standard structure which includes fields for at least one DPB link, a database pointer, an indication of database type and of record size and the next available postcode. All information for the specification of a database must be found in the DPB 51. Customer software must not perform any subsequent direct access to the DPB 51 and must not make any assumptions about the values held directly in the DPB 51 after the module defining that DPB 51 has been loaded for execution. Database parameter blocks 51 are transferred to the symbol loader/interpreter program in the form of a pointer (DPB link) to a linked list in a module's initialized data section. This field must be pre-assigned to the address in initialized data in the next DPB 51 on the list; or zero if this DPB 51 is the last or the only DPB 51 on the list. For compiled databases contained in the customer's initialized data area, the DB pointer must be pre-set to the "origin" address in the initialized data. For databases whose storage is controlled by the server, the field must be preset to zero. The DB type provides details of the database in coded form. There are at least three types of databases:

"Flyktige" databaser hvis innhold ikke behøver bevares mellom modulinnlastinger eller over en strømutkopling i terminalen 1 hvor databasen befinner seg. "Volatile" databases whose contents do not need to be preserved between module loads or over a power cut in the terminal 1 where the database is located.

"Ikke-flyktige" databaser hvis innhold må bevares mellom modulinnlastinger eller over en strømutkopling. Dersom modulen som definerer en ikke-flyktig database skiftes ut, blir databasen ødelagt når den gamle modul lastes ut. "Non-volatile" databases whose contents must be preserved between module loads or across a power outage. If the module that defines a non-volatile database is replaced, the database is destroyed when the old module is unloaded.

"Kompilerte databaser" blir oppbygd av symbolkompilatoren 71 i et tilstøtende område av initialiserte data som poster av fast lengde. Poster kan ikke legges til eller slettes fra en kompilert database, og databasen kan ikke initialiseres på kjøretidspunktet, men ellers skal fullstendig lese/skrive-mulighet støttes. "Compiled databases" are built up by the symbol compiler 71 in a contiguous area of initialized data as fixed-length records. Records cannot be added to or deleted from a compiled database, and the database cannot be initialized at runtime, but otherwise full read/write capability must be supported.

Det neste tilgjengelige postnummerfelt må bestemmes til én pluss det sist tildelte postnummer i databasen for kompilerte databaser. For hvilke som helst annen database settes dette felt til null. The next available zip code field must be determined to one plus the last assigned zip code in the database for compiled databases. For any other database, this field is set to zero.

- Adressen for et vindu inn til den aktuelle post (en postbuffer 53) er tilveiebrakt via tjeneren til kunden for hver kundedatabase. For visse databaseoperasjoner kan kunden over-føre adressene for kjeder og nøkkelbuffere 52 til tjeneren. For hver database som er blitt gjort kjent for tjeneren via - The address for a window into the relevant record (a record buffer 53) is provided via the server to the customer for each customer database. For certain database operations, the customer can transfer the addresses of chains and key buffers 52 to the server. For each database that has been made known to the server via

en kundemodul, tilveiebringes en postbuffer 53 av VM-en 20. Denne buffer 53 begynner ved en innrettet adresse. Innholdet i postbufferen 53 tilknyttet en spesiell database forblir tilgjengelig etter et postvalg inntil kunden velger en annen post fra databasen. Bortsett fra disse postbuffere 53, kompilerte databaser, og parametere overført på datastakken 27 av spesifikke databasefunksjoner, blir ikke noe annet dataområde 54 delt mellom kunde og tjener. Programmer får ikke anta at postene i en database er tilstøtende i minne. - En database blir momentanvalgt gjennom innlastingsprosessen for den modul hvor dens DPB er definert. Flyktige databaser installert av brukermoduler blir ikke-momentanvalgt automatisk og gjennomsiktig av tjeneren når bruken avsluttes av terminalresidente tjenester, når alt tjenertildelt datalager som vedrører de databaser, blir frigitt. - Tjeneren sletter ikke-flyktige databaser når den modul som definerer dem, blir skiftet ut. Dersom modulen er lastet inn når den skiftes, f.eks. i tilfelle av en TRS-modul, må tjeneren slette modulens ikke-flyktige databaser når modulen lastes ut. a customer module, a mail buffer 53 is provided by the VM 20. This buffer 53 begins at a configured address. The content of the record buffer 53 associated with a special database remains available after a record selection until the customer selects another record from the database. Apart from these record buffers 53, compiled databases, and parameters transferred on the data stack 27 by specific database functions, no other data area 54 is shared between client and server. Programs must not assume that the records in a database are contiguous in memory. - A database is momentarily selected through the loading process for the module where its DPB is defined. Volatile databases installed by user modules are non-momentarily selected automatically and transparently by the server when use is terminated by terminal-resident services, when all server-assigned data storage relating to those databases is released. - The server deletes non-volatile databases when the module that defines them is replaced. If the module is loaded when it is replaced, e.g. in the case of a TRS module, the server must delete the module's non-volatile databases when the module is unloaded.

Den handling som VM-en 20 foretar når en database blir momentanvalgt på modulinnlastingstidspunktet, avhenger av verdien på DB-type og DM-peker i DPB-en 51, og om databasen er flyktig eller ikke-flyktig. Dersom databasen er en ikke-flyktig type, blir DPB-adressen benyttet sammen med modulidentifika-sjonen (modul ID) for å identifisere eventuelle eldre data som tilhører databasen. Dersom det finnes eldre data, blir det neste tilgjengelige postnummer gjenopprettet til dettes tidligere verdi. Ellers momentanvelger tjeneren (VM 20) ny ikke-flyktig lagerplass og setter neste tilgjengelige postnummer til null. I begge tilfeller er det tilveiebrakt en buffer 53 for den aktuelle post i databasen. Dersom DP-peker er null og DB-type ikke er en kompilert type, momentanvelger eller tilgjengeliggjør tjeneren det lager som er nødvendig for databasen, initialiserer lageret til bare nuller, tilveiebringer en buffer 53 for den "aktuelle post" i databasen, og setter det neste tilgjengelige postnummer (DBAVAIL) til null. Dersom DB-peker er ikke-null og DB-type er en kompilert type, setter tjeneren opp interne strukturer for å benytte den kundedatastruktur hvis opprinnelsesadresse er blitt over-ført i DB-peker og setter det neste tilgjengelige postnummer (DBAVAIL) til den verdi som blir overført i det neste tilgjengelige postnummerfelt i DPB-en 51. Tjeneren opprettholder de faktiske databaseposter 55, forholdet mellom adressestedet og posten i en databasestyringsblokk 56 og en post fra denne database som en modul for øyeblikket går inn i, i en sammen-hengsinformasjonsblokk 57. The action that the VM 20 takes when a database is momentarily selected at module load time depends on the value of DB type and DM pointer in the DPB 51, and whether the database is volatile or non-volatile. If the database is a non-volatile type, the DPB address is used together with the module identification (module ID) to identify any older data belonging to the database. If there is older data, the next available postcode is restored to its previous value. Otherwise, the server (VM 20) instantly selects a new non-volatile storage space and sets the next available postal code to zero. In both cases, a buffer 53 is provided for the relevant record in the database. If DP pointer is null and DB type is not a compiled type, the server instantiates or makes available the storage needed for the database, initializes the storage to zeros only, provides a buffer 53 for the "current record" in the database, and sets it next available zip code (DBAVAIL) to zero. If DB pointer is non-null and DB type is a compiled type, the server sets up internal structures to use the customer data structure whose origin address has been transferred in DB pointer and sets the next available zip code (DBAVAIL) to that value which is transferred in the next available postal code field in the DPB 51. The server maintains the actual database records 55, the relationship between the address location and the record in a database management block 56 and a record from this database that a module is currently accessing in a context information block 57.

Den sikre modulhåndteringsprosedyre i overensstemmelse med den herværende oppfinnelse vil nå bli beskrevet under henvisning til fig. 6. På fig. 6 er vist et område for logisk lese/skriveminne. Et minneområde som modulen til venstre (før-ste modul) kan få tilgang til, har stiplet linje. Et minneområde som første modul ikke kan få tilgang til, har en grense med en heltrukken linje. Et minneområde som mer enn én modul kan få tilgang til, er vist med en strekpunktlinje. VM 20 beskytter databaser DB1 og DB2 og databaseoppbevaringsste-det og modulene i moduloppbevaringsstedet, slik at de ikke blir tilgjengelige for noen modul. Etter at første modul er lastet inn, kan de ikke-initialiserte data i minne 42 bli tilgjengelige for første modul, men VM-en 20 tillater ikke at modulen får direkte tilgang til noe område utenfor denne modul. Tilgang til registre, stakker eller rammeminne 46 kan bare opprettes gjennom de relevante symboler. Databaser blir bare tilgjengelige via vindusprosedyren nevnt ovenfor. Særlig første modul kan verken gå inn i sitt eget programminne 26 hvor symbolene er plassert, eller gå inn i noen annen modul. Dette er viktig som beskyttelse mot virus. I overensstemmelse med den herværende oppfinnelse er minnet tildelt første modul definert og beskyttet. Det er definert gjennom tildelingen av minne i overensstemmelse med angivelsen av minnemengden som skal tildeles, inneholdt i modulen. Det er beskyttet fordi ingen annen modul kan få tilgang til det tildelte område, og ingen annen lastemekanisme er tilveiebrakt for noe annet program enn for moduler. Siden den foretrukne fremgangsmåte til kjøring av moduler er éntrådet, blir ethvert minne som er tildelt i den utvidbare buffer 45, fraordnet før noen annen modul kan bli aktiv. Fraordnet minne blir fortrinnsvis slettet. The secure module handling procedure in accordance with the present invention will now be described with reference to fig. 6. In fig. 6 shows an area for logical read/write memory. A memory area that the module on the left (first module) can access has a dashed line. An area of memory that the first module cannot access has a border with a solid line. An area of memory that can be accessed by more than one module is shown with a dash-dotted line. VM 20 protects databases DB1 and DB2 and the database repository and the modules in the module repository so that they are not accessible to any module. After the first module is loaded, the uninitialized data in memory 42 may become available to the first module, but the VM 20 does not allow the module to directly access any area outside this module. Access to registers, stacks or frame memory 46 can only be created through the relevant symbols. Databases are only accessible via the window procedure mentioned above. In particular, the first module can neither enter its own program memory 26 where the symbols are located, nor enter any other module. This is important as protection against viruses. In accordance with the present invention, the memory allocated to the first module is defined and protected. It is defined through the allocation of memory in accordance with the specification of the amount of memory to be allocated, contained in the module. It is protected because no other module can access the allocated area, and no other loading mechanism is provided for any program other than modules. Since the preferred method of running modules is single-threaded, any memory allocated in the expandable buffer 45 is deallocated before any other module can become active. Allocated memory is preferably deleted.

Første moduls eksklusive importliste er i dens hode, som før-ste modul ikke har direkte tilgang til. VM-en 20 leser hodet og kaller opp den andre modul som er nevnt i importlisten (funksjon fgh fra den andre modul). VM-en 20 laster inn den andre modul og tildeler minne for de ikke-initialiserte data 42', rammeminne 46', og initialiserte data 41'. Den første modul får ikke tilgang til noen del av andre modul og om-vendt. I andre moduls hode er funksjonen fgh blitt plassert i den eksklusive liste over funksjoner som kan eksporteres. Dette gjør funksjonen fgh tilgjengelig for andre moduler. VM-en 20 søker etter funksjonen fgh i kodeminneområdet 26' for den andre modul og utfører symbolstrømmen med motsvarende innebygde data (representert ved strømmen TITTITT). I dette eksempel krever denne kodebit tilgang til en database DB2. En database i overensstemmelse med den herværende oppfinnelse The first module's exclusive import list is in its head, which the first module does not have direct access to. The VM 20 reads the header and calls up the second module mentioned in the import list (function fgh from the second module). The VM 20 loads the second module and allocates memory for the uninitialized data 42', frame memory 46', and initialized data 41'. The first module does not get access to any part of the second module and vice versa. In the second module's head, the function fgh has been placed in the exclusive list of functions that can be exported. This makes the function fgh available to other modules. The VM 20 searches for the function fgh in the code memory area 26' for the second module and executes the symbol stream with corresponding embedded data (represented by the stream TITTITT). In this example, this piece of code requires access to a database DB2. A database in accordance with the present invention

"eies" av en modul, dvs. en database er bare tilgjengelig for modulen som momentanvalgte den ved første innlasting av modulen. Databasetilgangssymbolene lest fra kodeområdet 26' utfø- "owned" by a module, i.e. a database is only available to the module that momentarily selected it when the module was first loaded. The database access symbols read from code area 26' execute

res av VM-en 20 som tildelte en buffer 53' i den andre moduls ikke-initialiserte dataområde 42' ved innlasting. Funksjonen fgh krever tilgang til den tredje post i DB2. VM-en 20 over-fører deretter henvisningsposten til vinduet 53' i den andre modul, hvorfra den blir eksportert til det ikke-initialiserte område 42 i den første modul. Ved bruk av den samme database-vindusprosedyre, kan den første modul også hente en post fra sin egen database DB1 som blir overført til bufferen 53 i det ikke-initialiserte dataområde 42. Første modul kan nå operere på resultatene av de to prosedyrer. res by the VM 20 which allocated a buffer 53' in the second module's uninitialized data area 42' on loading. The function fgh requires access to the third record in DB2. The VM 20 then transfers the referral record to the window 53' of the second module, from where it is exported to the uninitialized area 42 of the first module. Using the same database window procedure, the first module can also retrieve a record from its own database DB1 which is transferred to the buffer 53 in the uninitialized data area 42. The first module can now operate on the results of the two procedures.

VM-en 20 tar seg fortrinnsvis av dataobjekter ved hjelp av grunnleggende kodingsregler . (Basic Encoding Rules) eller etikett (Tag), lengde (Length), verdi (Value) (BER-TLV forkortet til TLV til bruk her), som beskrevet i ISO/IEC 8825 (1990). TLV-dataobjekter består av to eller tre fortløpende felter: et etikettfelt som angir klasse, type og nummer, et lengde-felt som angir størrelsen på dataene, og dersom lengden ikke er null, et verdifelt som inneholder dataene. Siden ICC-kort-reaksjoner vanligvis er begrenset i størrelse til f.eks. 255 byte eller mindre, er det en maksimumsstørrelse for et TLV-objekt i overensstemmelse med den herværende oppfinnelse. Etikettfeltet er fortrinnsvis én eller to byte, lengdefeltet er fortrinnsvis én eller to byte, og således er verdifeltets maksimumsstørrelse fortrinnsvis 252 byte (et felt som er så langt, krever to lengdebyte, som forklart nedenfor). Etikettfeltets første byte er brutt opp i tre felter. Biter 7 og 8 angir objektklasse. Bit 6 bestemmer om verdifeltet inneholder "primitive" data, eller om det er et "konstruert" objekt som består av andre TLV-kodede felter. Konstruerte objekter kalles også maler. De forårsaker at deres verdifelter bli analy-sert med hensyn til TLV-sekvenser når de blir påtruffet. Bit 1 til 5 angir objektets nummer eller, dersom alle disse biter er fastsatt, angir at ytterligere etikettbyte følger. De ytterligere etikettbyte har sitt åttende bitsett om enda en by-te følger. Alle biter i opp til to byte blir benyttet til å bestemme et etikettnavn. Lengdefeltet består av én til tre fortløpende byte, typisk to. Dersom bit 8 i den første byte er 0, angir bit 1 til 7 størrelsen på verdifeltet. Dersom bit 8 i den første byte er 1, da angir bit 1 til 7 antallet byte som følger. De følgende byte, dersom det er noen, angir stør-relsen på verdifeltet og fremkommer med den mest signifikante byte først. Verdifeltet kan bestå av "primitive" data eller kan være "konstruert" med TLV-kodede sekvenser i tillegg. Hvis bit 6 i den første byte i etikettfeltet er fastsatt, inneholder verdifeltet ytterligere TLV-sekvenser. De primitive objekter kan være kodet i flere forskjellige formater: binærkodede desimalnibler med ledende nuller eller etterhengende nibler med alle biter fastsatt, binære nummer eller bytese-kvenser, tegnsekvenser i alfanumeriske eller ASCII-byte, eller udefinerte formater. Hvert blir håndtert ulikt etter som det blir brukt. Et ICC 5 kan også benytte en dataobjektliste (DOL) for å be om verdier for spesifiserte etikettnavn. Kortet 5 sender en DOL som består av en liste av etikett- og lengdefelter, og terminalen 1 returnerer det tilhørende verdifelt, uten skilletegn. The VM 20 preferably deals with data objects using basic coding rules. (Basic Encoding Rules) or label (Tag), length (Length), value (Value) (BER-TLV abbreviated to TLV for use here), as described in ISO/IEC 8825 (1990). TLV data objects consist of two or three consecutive fields: a label field that specifies the class, type, and number, a length field that specifies the size of the data, and if the length is not zero, a value field that contains the data. Since ICC card reactions are usually limited in size to e.g. 255 bytes or less is a maximum size for a TLV object in accordance with the present invention. The label field is preferably one or two bytes, the length field is preferably one or two bytes, and thus the maximum size of the value field is preferably 252 bytes (a field this long requires two length bytes, as explained below). The first byte of the label field is broken up into three fields. Bits 7 and 8 indicate object class. Bit 6 determines whether the value field contains "primitive" data, or whether it is a "constructed" object consisting of other TLV-encoded fields. Constructed objects are also called templates. They cause their value fields to be parsed for TLV sequences when encountered. Bits 1 to 5 indicate the object's number or, if all these bits are set, indicate that further label bytes follow. The additional label bytes have their eighth bit set if another byte follows. All bits up to two bytes are used to determine a label name. The length field consists of one to three consecutive bytes, typically two. If bit 8 in the first byte is 0, bits 1 to 7 indicate the size of the value field. If bit 8 in the first byte is 1, then bits 1 to 7 indicate the number of bytes that follow. The following bytes, if there are any, indicate the size of the value field and appear with the most significant byte first. The value field can consist of "primitive" data or can be "constructed" with TLV-encoded sequences in addition. If bit 6 of the first byte of the label field is set, the value field contains additional TLV sequences. The primitive objects can be encoded in several different formats: binary-coded decimal nibles with leading zeros or trailing nibles with all bits fixed, binary numbers or bytese sequences, sequences of characters in alphanumeric or ASCII bytes, or undefined formats. Each is handled differently according to how it is used. An ICC 5 can also use a data object list (DOL) to request values for specified label names. The card 5 sends a DOL consisting of a list of label and length fields, and the terminal 1 returns the corresponding value field, without separators.

Hver TLV som skal brukes, må være definert av terminalen eller brukerprogrammer for å fastslå dens datatype og navn. Siden terminalprogrammet og brukerprogrammene er utviklet separat, benytter VM-en 20 i overensstemmelse med den herværende oppfinnelse en lenket struktur (et balansert binærtre) for å tillate rask tilføyelse og fjerning av etikettnavn fra den globale etikettnavneliste. Dette krever at følgende struktur kompileres for hver TLV i initialisert dataområde 41 i den modul som definerer TLV: Lenke En celle med "venstre" (mest signifikante to byte) og "høyre" (minst signifikante to byte) komponenter som tilveiebringer lenker til elementer i treet. Each TLV to be used must be defined by the terminal or user programs to determine its data type and name. Since the terminal program and the user programs are developed separately, the VM 20 in accordance with the present invention uses a linked structure (a balanced binary tree) to allow rapid addition and removal of label names from the global label name list. This requires that the following structure be compiled for each TLV in initialized data area 41 of the module that defines the TLV: Link A cell with "left" (most significant two bytes) and "right" (least significant two bytes) components that provide links to elements in the tree.

Lenke venstre En 16-biters fortegnsbestemt adressedifferanse mellom denne TLVs tilgangsparameter og tilgangsparameteren for en TLV-post hvis etrkett numerisk er mindre enn denne posts etikett. En verdi på null angir at denne TLV ikke er lenket til en TLV med en etikett som numerisk er mindre enn denne. Link left A 16-bit signed address difference between this TLV's access parameter and the access parameter of a TLV record whose etrket is numerically less than this record's label. A value of zero indicates that this TLV is not linked to a TLV with a label numerically smaller than this one.

Lenke høyre En 16-biters fortegnsbestemt adressedifferanse mellom denne TLVs tilgangsparameter og tilgangsparameteren for en TLV-post hvis etikett er numerisk større enn denne posts etikett. En verdi på null angir at denne TLV ikke er lenket til en TLV med en etikett som er numerisk større enn denne. Link right A 16-bit signed address difference between this TLV's access parameter and the access parameter of a TLV record whose label is numerically greater than this record's label. A value of zero indicates that this TLV is not linked to a TLV with a label numerically greater than this one.

Etikett En to bytes streng, hvis numeriske verdi i stor-enden er TLV-etiketten. Label A two-byte string, whose numerical value at the large end is the TLV label.

Type En enkelt byte som angir styringsinformasjon.Type A single byte indicating management information.

Reservert En byte som må initialiseres til null av kompilatoren 71. Reserved A byte that must be initialized to zero by the compiler 71 .

Data En celle som innehar VM-spesifikke opplysninger innbefattet tilgang til denne TLVs lengde- og verdifelter. Dette felt må initialiseres til null av kompilatoren 71. Systemet må også opprettholde en statusbyte for hver TLV. Dette kan være Reservert-byten i den ovennevnte struktur. Denne bytes minst signifikante bit skal fastsettes dersom TLV-en er blitt tilordnet en verdi som et resultat av at den er i en sekvens som er blitt behandlet gjennom symbolene TLVPARSE eller TLVSTORE. Formålet med å opprettholde en tilordnet status er å identifisere TLV-verdier som inneholder gyldige data (som kan være null) og skjelne disse fra TLV-verdier som aldri er blitt fastsatt og derfor er ugyldige. VM-kjernen håndterer en global liste over TLV-etiketter ved å opprettholde en liste av pekere til det initialiserte dataområde 41 som inneholder disses faktiske definisjoner som beskrevet ovenfor. Når en modul er lastet inn, blir dens TLV-definisjoner tilføyd i denne liste som en del av dens initialisering; når den lastes ut, skal dens TLV-definisjoner automatisk bli fjernet fra listen av VM-en 20. En unntakssituasjon kan bli fremsatt dersom modulen inneholder en TLV-definisjon som allerede finnes. Adressen til Lenke-feltet beskrevet ovenfor blir returnert som "tilgangsparameteren" for TLV-referanser. Programmereren skal ikke gå inn i disse filer direkte, heller ikke gjøre no-en antakelse om deres innhold, etter at VM-en 20 har momentanvalgt TLV-definisjonene . Data A cell that contains VM-specific information including access to this TLV's length and value fields. This field must be initialized to zero by the compiler 71. The system must also maintain a status byte for each TLV. This could be the Reserved byte in the above structure. The least significant bit of this byte shall be determined if the TLV has been assigned a value as a result of being in a sequence that has been processed through the symbols TLVPARSE or TLVSTORE. The purpose of maintaining an assigned status is to identify TLV values that contain valid data (which may be null) and distinguish these from TLV values that have never been set and are therefore invalid. The VM core manages a global list of TLV labels by maintaining a list of pointers to the initialized data area 41 containing their actual definitions as described above. When a module is loaded, its TLV definitions are added to this list as part of its initialization; when it is unloaded, its TLV definitions shall be automatically removed from the list by the VM 20. An exception may be raised if the module contains a TLV definition that already exists. The address of the Link field described above is returned as the "access parameter" for TLV references. The programmer must not enter these files directly, nor make any assumptions about their contents, after the VM 20 has momentarily selected the TLV definitions.

Henvisninger til TLV-definisjoner i kildekoden blir kompilert enten som direkte henvisninger til definisjonsstrukturene angitt ovenfor, eller numeriske etikettverdier. Innenfor visse binære TLV-definisjoner, blir enkeltbiter eller grupper av biter definert til å ha bestemte betydninger. Disse blir kalt "TLV-biter". Henvisninger til TLV-biter kan kompileres med en litteral peking på en bit innenfor TLV-ens verdifelt. Bit 0 er den minst signifikante bit i den første byte, bit 7 er den mest signifikante bit i den samme byte, bit 8 er den minst signifikante bit i den andre byte og så videre. References to TLV definitions in the source code are compiled either as direct references to the definition structures specified above, or numeric label values. Within certain binary TLV definitions, individual bits or groups of bits are defined to have particular meanings. These are called "TLV bits". References to TLV bits can be compiled with a literal pointing to a bit within the TLV's value field. Bit 0 is the least significant bit in the first byte, bit 7 is the most significant bit in the same byte, bit 8 is the least significant bit in the second byte and so on.

Dataene tilordnet en TLV-definisjon blir utlagt for bruk The data assigned to a TLV definition is laid out for use

gjennom et 252-bytes arbeidsområde opprettholdt av VM-en 20 i form av et databasevindu (se fig. 7). Brukerprogrammet tillates å endre innholdet i dette arbeidsområde. Dersom endringer skal beholdes, må en adresse og lengde innenfor arbeidsområ-det føres tilbake til TLVSTORE-symbolet. Arbeidsområdets adresse og innhold kan bli ugyldig når hvilket som helst TLV-symbol deretter blir utført. through a 252-byte work area maintained by the VM 20 in the form of a database window (see Fig. 7). The user program is allowed to change the contents of this work area. If changes are to be retained, an address and length within the working area must be returned to the TLVSTORE symbol. The workspace address and contents may become invalid when any TLV symbol is subsequently executed.

Som en del av den sikkerhetsmessige håndtering av kort 5 som blir ført inn i leseren 7, blir det foretatt en kontroll med tanke på kort 5 som er meldt mistet eller ugyldige. En liste over slike kort 5 er kjent som en svarteliste eller en hettkortliste. Håndtering av svarteliste eller hettkortliste tilveiebringes av et sett dediserte funksjoner som er spesifikke for håndteringen av en stor 'hettkortliste. En typisk liste kan inneholde 10 000 primærkontonumre (PAN) på opp til 10 by-te hver, eller 20 binærkodede desimaltall (BCD-tall). PAN-innføringene blir lagret i komprimert numerisk (cn) format, til høyre polstret med heksadesimale FH-er. Siden et PAN maksimalt har nitten BCD-tall, vil en innføring i listen alltid bli polstret med i det minste én FH. Ved søking i hettkortlisten, vil FH-er i en listeoppføring bli betraktet som villkort eller "uinteressante" tall, men eventuelle FH-er i PAN-et brukt som inndata, er ikke villkort. Villkort kan bare fremkomme i høyre ende av en oppføring. Et PAN skal betraktes som funnet i hettkortlisten dersom det er en listeoppføring som er identisk frem til den første FH i oppføringen. As part of the security-related handling of cards 5 that are entered into the reader 7, a check is made with regard to cards 5 that have been reported lost or invalid. A list of such cards 5 is known as a blacklist or a hot card list. Blacklist or hotcard list management is provided by a set of dedicated functions specific to handling a large 'hotcard list'. A typical list may contain 10,000 primary account numbers (PANs) of up to 10 bytes each, or 20 binary coded decimal (BCD) numbers. The PAN entries are stored in compressed numeric (cn) format, right-padded with hexadecimal FHs. Since a PAN has a maximum of nineteen BCD numbers, an entry in the list will always be padded with at least one FH. When searching the cover card list, FHs in a list entry will be considered wild cards or "uninteresting" numbers, but any FHs in the PAN used as input are not wild cards. Wild cards can only appear at the right end of an entry. A PAN shall be considered as found in the hot card list if there is a list entry that is identical up to the first FH in the entry.

En annen del av sikkerhetskontrollen er tilveiebringelsen av kryptografiske tjenester til kryptering og dekoding av data. Hvilke som helst egnede fremgangsmåter for kryptering kan benyttes. Tre kryptografiske algoritmer er særlig tilveiebrakt for VM-en 20: modulo-multiplikasjon og modulo-eksponensiering, hvilke blir benyttet i RSA-algoritmen; og den sikre nøkkeltransformeringsalgoritme SHA-1, men oppfinnelsen er ikke begrenset til disse. Modulo-multiplikasjon foretar en multiplikasjon av to verdier x og y uten fortegn, hvor produktet blir redusert ved å bruke modulusen z. Formelen er: Another part of the security control is the provision of cryptographic services for the encryption and decoding of data. Any suitable methods of encryption may be used. Three cryptographic algorithms are particularly provided for the VM 20: modulo multiplication and modulo exponentiation, which are used in the RSA algorithm; and the secure key transformation algorithm SHA-1, but the invention is not limited to these. Modulo multiplication performs an unsigned multiplication of two values x and y, where the product is reduced by using the modulus z. The formula is:

resultat = mod(x<*>y,z)result = mod(x<*>y,z)

Innverdiene (x,y,z) har alle samme lengde. De er representert ved bytestrenger og kan være hvilket som helst multiplum av 8 biter opp til og med 1024 biter. Verdiene må være i stor-ende-byteorden. The input values (x,y,z) all have the same length. They are represented by byte strings and can be any multiple of 8 bits up to and including 1024 bits. The values must be in upper-end byte order.

Algoritmen The Secure Hash Algorithm (SHA-1) (den sikre nøk-keltransformeringsalgoritme) er standardisert som FIPS 180-1. SHA-1 tar innmeldinger på vilkårlig lengde og lager en 20-bytes nøkkeltransformeringsverdi. Modul-eksponensiering opp-høyer en verdi x uten fortegn til en potens gitt av en ekspo-nent y uten fortegn, hvor produktet blir redusert ved å bruke modulusen z. Formelen er: The algorithm The Secure Hash Algorithm (SHA-1) (the secure key transformation algorithm) is standardized as FIPS 180-1. SHA-1 takes entries of arbitrary length and creates a 20-byte key transformation value. Modulo exponentiation raises an unsigned value x to a power given by an unsigned exponent y, where the product is reduced using the modulus z. The formula is:

resultat = mod(x<A>y,z)result = mod(x<A>y,z)

Innverdien x og modulusen z er representert ved bytestrenger og kan være hvilket som helst multiplum av 8 biter til og med 1024 biter. Verdiene må være i stor- The input value x and the modulus z are represented by byte strings and can be any multiple of 8 bits up to and including 1024 bits. The values must be in capital

ende-byteorden.end byte order.

Tjenester og derfor programvare og til og med inn/ut-enheter kan forandres over tid avhengig av behovet i markedet. Når større endringer er nødvendige, kan en oppdatering av programvaren i terminalen 1 utføres enten manuelt eller fra et fjerntliggende sted via et telekommunikasjonsnettverk. For brukeravhengige tjenester er det imidlertid å foretrekke å ha en dynamisk, men sikker fremgangsmåte for å foreta mindre eller brukerspesifikke oppgraderinger av tjenester tilveiebrakt gjennom en terminal 1. "Støpsel og kontakt"-programvaremekanismen i overensstemmelse med den herværende oppfinnelse tilveiebringer en fleksibel og sikker måte for online utforming av de forskjellige moduler som utgjør termi-nalprogrammer og bruksprogrammer. Som vist skjematisk på fig. 8, kan det i transaksjonssystemet ifølge den herværende oppfinnelse defineres en rekke prosedyrer (kalt "kontakter" 60) som kan settes inn av bruksprogrammereren (og deretter være sikre siden de er under erververens kontroll og under beta-lingssystemovervåking) i et bruksprogram 61, 62 for å virke som plassbevarere for tilføyelse av forbedringskode i tillegg (kalt "plugger" 66) under transaksjonsbehandling. Enhver til-leggskode som skal plugges inn i en kontakt 60, må være skrevet uttrykt i VM-ens 20 symbolsett. Kontakter 60 blir fortrinnsvis plassert på forskjellige egnede steder i eksisterende terminalbruksprogram 61, 62 eller til og med i selve terminalprogrammet. De benyttes til å vise til biblio-tekfunksjoner, og kan til og med forekomme innenfor en bibli-otekfunksjon dersom et betalingssystem forutser behovet for å endre en bibliotekfunksjons virkemåte. Kontakter 60 blir initialisert til standardoppførsel av VM-en 20. Dersom det ikke fattes noen ytterligere tiltak av terminalprogrammet, vil kontakters 60 standardoppførsel være å ikke gjøre noe når de utføres (dvs. ikke-operasjon). Services and therefore software and even input/output devices can change over time depending on market needs. When major changes are required, an update of the software in the terminal 1 can be performed either manually or from a remote location via a telecommunications network. However, for user-dependent services, it is preferable to have a dynamic but secure method of making minor or user-specific upgrades of services provided through a terminal 1. The "plug and socket" software mechanism in accordance with the present invention provides a flexible and secure way for online design of the various modules that make up terminal programs and application programs. As shown schematically in fig. 8, in the transaction system according to the present invention, a series of procedures (called "contacts" 60) can be defined which can be inserted by the application programmer (and then be secure since they are under the control of the acquirer and under payment system monitoring) in an application program 61, 62 to act as placeholders for the addition of additional enhancement code (called "plugs" 66) during transaction processing. Any additional code to be plugged into a connector 60 must be written expressed in the VM's 20 symbol set. Contacts 60 are preferably placed in various suitable places in the existing terminal application program 61, 62 or even in the terminal program itself. They are used to refer to library functions, and can even occur within a library function if a payment system foresees the need to change the way a library function works. Contacts 60 are initialized to default behavior by the VM 20. If no further action is taken by the terminal program, the default behavior of contacts 60 will be to do nothing when executed (ie, non-operation).

Plugger 66 innbefatter utførbar kode, skrevet i symboler støttet av terminalen 1, hvilke kan settes inn på steder av-grenset av kontakter 60 for å forbedre standard-terminallogikken. Plugger 66 kan allerede eksistere i terminalen 1 i et pluggbibliotek 63 som kan oppsøkes fra ICC-et 5, f.eks. kontakt/plugg-identifikatorer 67 i et ICC 5 og logikk i terminalen 1. Kontakt/plugg-identifikatorer 67 innbefatter en henvisning til både pluggen og den kontakt som skal plugges, hvor pluggen ikke finnes i ICC-et 5, men i pluggbiblioteket 63. Plugger 66 kan også komme fra en innenhet 65 (slik som ICC-et 5 eller et vertssystem koplet til terminalen 1), men bare dersom medlemmene i betalingssystemet, f.eks. utsteder, erverver og handelsmann) er enige om dette. Plugs 66 include executable code, written in symbols supported by terminal 1, which can be inserted into locations delimited by contacts 60 to enhance standard terminal logic. Plugs 66 may already exist in the terminal 1 in a plug library 63 which can be searched from the ICC 5, e.g. connector/plug identifiers 67 in an ICC 5 and logic in the terminal 1. Connector/plug identifiers 67 include a reference to both the plug and the connector to be plugged, where the plug is not found in the ICC 5, but in the plug library 63. Plugs 66 can also come from an internal unit 65 (such as the ICC 5 or a host system connected to the terminal 1), but only if the members of the payment system, e.g. issuer, acquirer and trader) agree on this.

Ved avslutning av en transaksjon blir kontaktene 60 tilbake-ført til s-in opprinnelige bruksstandardoppf ørsel. I overensstemmelse med den herværende oppfinnelse foretrekkes det at et ICC 5 ikke inneholder hele brukerprogram, men bare plugger 66 som forbedrer eksisterende terminalbruksprogram, da disse krever mindre minne. At the end of a transaction, the contacts 60 are returned to their original standard usage configuration. In accordance with the present invention, it is preferred that an ICC 5 does not contain the entire user program, but only plugs 66 that improve the existing terminal user program, as these require less memory.

Kontakter 60 innehar utførelsespekere, også kjent som prose-dyrepekere, som tillater opprettelse av en prosedyre hvis oppførsel kan endres på utførelsestidspunktet. Kontakter 60 kan betraktes (og være implementert) som en rekke av prosedyrer som det er tilgang til gjennom DOSOCKET-symbolet, som tar kontaktnummeret som en innebygd byte, eller gjennom IDOSOCKET-symbolet som tar kontaktnummeret fra datastakken 27 . Contacts 60 hold execution pointers, also known as procedure pointers, which allow the creation of a procedure whose behavior can be changed at execution time. Sockets 60 can be thought of (and implemented) as a series of procedures that are accessed through the DOSOCKET symbol, which takes the socket number as an embedded byte, or through the IDOSOCKET symbol, which takes the socket number from the data stack 27 .

Kontakter 60 muliggjør rekonfigurering av et terminalprogram eller brukerprogram for å tilveiebringe varianter eller for-bedringer i transaksjonsbehandlingsflyten. Alternativt kan kontakter i ICC-er 5 tillate oppgradering av ICC-er 5 fra en terminal 1. Kontakter 60 tilveiebringer et grensesnitt mellom programvaremoduler og prosedyrer som kan komme fra flere forskjellige kilder (erverver, utsteder, osv.). Siden en erverver og en utsteder har et kontraktfestet forhold, kan de bli enige om å bruke spesifikke kontakter 60 tilveiebrakt gjennom erververens program i en terminal, slik at en utsteder kan utvide programmets oppførsel, for eksempel for å tilveiebringe en lojalitetsfunksjon (flystrekninger, kuponger, osv.) Connectors 60 enable reconfiguration of a terminal program or user program to provide variations or improvements in the transaction processing flow. Alternatively, connectors in ICCs 5 may allow upgrading of ICCs 5 from a terminal 1. Connectors 60 provide an interface between software modules and procedures that may come from several different sources (acquirer, issuer, etc.). Since an acquirer and an issuer have a contractual relationship, they may agree to use specific contacts 60 provided through the acquirer's program in a terminal, allowing an issuer to extend the program's behavior, for example to provide a loyalty function (flights, coupons, etc.)

En modul kan angi at kontakter 60 skal rekonfigureres automatisk når den lastes inn for utførelse, eller et kundeprogram kan programmessig tilordne en ny prosedyre til en kontakt på kjøretidspunktet. Forutsatt at sikkerhetsbetingelsene tillater det, kan kontakter 60 i en anvendelse tilordnes en stan-dardoppf ørsel og deretter bli plugget på ny med nye prosedyrer av påfølgende moduler for å tilveiebringe spesialiserte oppførsler. For å unngå uendelige situasjoner, er det å foretrekke dersom alle prosedyrer som er vektorisert til å bruke en spesiell kontakt 60, ikke har noen datastakkevirkning (bortsett fra kontakt null, som forklart senere). Dette sik-rer programkontinuitet uansett hvilken vektorisert utgave av prosedyren som utføres. Standardvirksomheten for alle kontakter 60 før modifisering skal være i det minste den med ikke-operasjon. A module may specify that connectors 60 be automatically reconfigured when it is loaded for execution, or a client program may programmatically assign a new procedure to a connector at runtime. Provided security conditions permit, contacts 60 in an application may be assigned a standard behavior and then re-plugged with new procedures by subsequent modules to provide specialized behaviors. To avoid infinite situations, it is preferable if all procedures vectored to use a particular contact 60 have no data stack impact (except for contact zero, as explained later). This ensures program continuity regardless of which vectorized version of the procedure is executed. The default operation of all contacts 60 before modification shall be at least that of non-operation.

En erverver kan tillate transaksjonsforbedringer ved kode på et ICC 5 som en del av CSS nevnt ovenfor. I så fall kan disse implementeres med kontakter 60. Et bibliotek eller en utfør-bar modul kan innbefatte definisjonen av nye kontakter 60 for senere plugger 66 som kommer fra et ICC 5. I dette tilfelle ville modulen definere en kontakt 60 og deretter bruke SETSOCKET-symbolet for å tilordne den en standardoppførsel (ofte en null-oppførsel). Dersom tilgangskontrollen tillater det, vil et ICC 5 senere kunne laste ned en plugg 66 innbefattet symboler som definerer en ny oppførsel, og deretter bruke SETSOCKET-symbolet for å lagre den i den samme kontakt 60, hvorved den overstyrer standardoppførselen. An acquirer may allow transaction enhancements by code on an ICC 5 as part of the CSS mentioned above. If so, these could be implemented with sockets 60. A library or executable module could include the definition of new sockets 60 for later plugs 66 coming from an ICC 5. In this case, the module would define a socket 60 and then use the SETSOCKET- symbol to assign it a default behavior (often a null behavior). If the access control allows it, an ICC 5 will later be able to download a plug 66 containing symbols that define a new behavior, and then use the SETSOCKET symbol to store it in the same socket 60, thereby overriding the default behavior.

Å modifisere oppførsler er gunstig og fleksibelt, men kan gi anledning for ondsinnede personer å modifisere oppførsel til deres fordel. Spesiell forsiktighet kan være nødvendig med plugger 66 fra et ICC 5 dersom de kan modifisere en kontakts oppførsel eller bli plassert i programstrømmen før vellykket kortautentisering. Av sikkerhetsmessige hensyn kan terminal-programvaren spesifisere i overensstemmelse med den herværen- Modifying behaviors is beneficial and flexible, but can provide opportunities for malicious individuals to modify behaviors to their advantage. Special care may be required with plugs 66 from an ICC 5 if they can modify a contact's behavior or be placed in the program stream prior to successful card authentication. For security reasons, the terminal software can specify in accordance with the

de oppfinnelse en kontaktkontrollprosedyre som kontrollerer om hver enkelt kontakt 60 kan modifiseres eller ikke. Således kan for eksempel utførelsen av kode nedlastet fra et ICC 5 they invented a contact control procedure that checks whether each individual contact 60 can be modified or not. Thus, for example, the execution of code downloaded from an ICC 5

kontrolleres strengt av erververen, slik at ikke noen kontakt blir plugget av ICC-et 5 før alle gyldighetsvurderingsrutiner er blitt utført på kortet, f.eks. undersøkelse av en elektronisk signatur. is strictly controlled by the acquirer, so that no contact is plugged by the ICC 5 before all validity assessment routines have been carried out on the card, e.g. examination of an electronic signature.

I overensstemmelse med den herværende oppfinnelse innbefatter kontaktsikkerhet spesifisering av kontaktkontrollprosedyren som skal anvendes på senere forsøk på å plugge en kontakt 60 (SETPLUGCONTROL-symboi). PLUGCONTROL-prosedyren må være skrevet slik at den for et gitt kontaktnummer melder tilbake om den kontakt 60 nå kan modifiseres. Når en moduls kontaktliste deretter blir behandlet på modulinnlastingstidspunktet, eller når en kontakt 60 blir plugget via program, utfører VM-en 20 først den brukerskrevne PLUGCONTROL-prosedyre for å bestemme om kontakten 60 virkelig kan plugges, og beholder kontaktens 60 eksisterende oppførsel dersom den ikke kan. In accordance with the present invention, connector security includes specifying the connector control procedure to be applied to subsequent attempts to plug a connector 60 (SETPLUGCONTROL symbol). The PLUGCONTROL procedure must be written so that for a given contact number it reports back whether contact 60 can now be modified. When a module's connector list is then processed at module load time, or when a connector 60 is programmatically plugged, the VM 20 first executes the user-written PLUGCONTROL procedure to determine if the connector 60 is indeed pluggable, and retains the connector 60's existing behavior if it is not can.

En modul som ønsker å begrense tilgang til hvilke kontakter A module that wants to limit access to which contacts

60 det måtte være, før en annen modul blir innlastet for ut-førelse, kan utføre en prosedyre definert gjennom SETPLUGCONTROL-symboiet på en pluggbar kontakt (kontakt null) med den valgte PLUGCONTROL-funksjon som en parameter, før innlasting av den modul. Når den neste modul, og hvilke som helst andre moduler som er lastet inn for dens utførelse, får sine kontaktlister behandlet, skal kontakter 60 til hvilke tilgang blir avslått av den brukerdefinerte PLUGCONTROL-prosedyre, bevare sin eksisterende oppførsel. Denne tilstand skal ikke ansees som en feil. Kode som ønsker å begrense tilgang til hvilke kontakter 60 det måtte være, før ytterligere kode er utført, kan utføre prosedyren definert gjennom SETPLUGCONTROL-symboiet med den valgte PLUGCONTROL-prosedyre som en parameter, på et egnet punkt i programflyten. En program-forespørsel om å plugge en kontakt 60 kan bestemme om anmodningen ble godtatt eller avslått gjennom oppkallingen til SETSOCKET. Enhver kontakt 60 hvis oppførsel ble endret, enten gjennom modulinnlastingsprosessen eller dynamisk gjennom programmert kommando, blir tilbakeført til den oppførsel den hadde da den sist utførbare modul ble lastet inn for ut-førelse, som en del av avslutningsprosedyren pakket inn i prosedyren definert gjennom modulutførelsessymbolet 60 it may be, before another module is loaded for execution, can execute a procedure defined through the SETPLUGCONTROL symbol on a pluggable contact (contact zero) with the selected PLUGCONTROL function as a parameter, before loading that module. When the next module, and any other modules loaded for its execution, have their contact lists processed, contacts 60 to which access is denied by the user-defined PLUGCONTROL procedure shall retain their existing behavior. This condition should not be considered a fault. Code that wishes to restrict access to whatever connectors 60 there may be, before further code is executed, can execute the procedure defined through the SETPLUGCONTROL symbol with the selected PLUGCONTROL procedure as a parameter, at an appropriate point in the program flow. A program request to plug a socket 60 can determine whether the request was accepted or rejected through the call to SETSOCKET. Any contact 60 whose behavior was changed, either through the module loading process or dynamically through programmed command, is reverted to the behavior it had when the last executable module was loaded for execution, as part of the exit procedure wrapped in the procedure defined through the module execution symbol

(EXECUTEMODULE).(EXECUTEMODULE).

Som et eksempel på en erververspesifikk funksjon, kan det an-tas at den grunnlegende transaksjonskode innbefatter frasen 27 SOCKET LOYALTY som definerer LOYALTY og gjør den tilgjengelig for senere utførelse. Erververens transaksjonsprogram-kode definerer videre kode som setter opp tillattflagget for denne kontakt bare dersom utstederen er den samme som erververen, og transaksjonsmengden overskrider et visst minimum. Under transaksjonen er det en kommando som i vilkårlig kode leser fra ICC-et 5. En del av ICC-koden kunne definere en REWARD-rutine som oppdaterer registreringen over brukerens hyppige flyvninger, og deretter forsøke å utføre frasen PLUG REWARD INTO LOYALTY. Denne frase forbinder utførelsen av REWARD med utførelsen av LOYALTY. Dersom LOYALTY-kontaktens tillatt-flagg er satt i overensstemmelse med ovenstående logikk, vil SETSOCKET finne sted; ellers vil LOYALTY bevare sin standardoppførsel, sannsynligvis en ikke-operasjon. Når da brukerprogramkoden senere utfører sin LOYALTY-funksjon, vil den tillate den ICC-definerte REWARD bare i overensstemmelse med de erverver-definerte regler. As an example of an acquirer-specific function, it can be assumed that the basic transaction code includes the phrase 27 SOCKET LOYALTY which defines LOYALTY and makes it available for later execution. The acquirer's transaction program code further defines code that sets up the allow flag for this contact only if the issuer is the same as the acquirer, and the transaction amount exceeds a certain minimum. During the transaction, there is a command that in arbitrary code reads from the ICC 5. Part of the ICC code could define a REWARD routine that updates the record of the user's frequent flyers, and then attempt to execute the phrase PLUG REWARD INTO LOYALTY. This phrase connects the performance of REWARD with the performance of LOYALTY. If the LOYALTY socket's allow flag is set in accordance with the above logic, SETSOCKET will occur; otherwise, LOYALTY will preserve its default behavior, probably a non-operation. When the user program code subsequently performs its LOYALTY function, it will allow the ICC-defined REWARD only in accordance with the acquirer-defined rules.

Typisk kan VM-en 20 som kjøres på en terminal 1, ha et begrenset antall kontakter 60, f.eks. 64 kontakter, nummerert fra 0 til og med 63. I sin mest grunnleggende form vil en terminalprogramstamme kunne utgjøres nesten fullstendig av kontakter 60 og grunnprogramflyt fra kontakt til kontakt. Kontaktene 60 ville da bli plugget med transaksjonsbehand-lingsprosedyrer av andre moduler lastet inn på bruksvalgtids-punktet, enten fra terminalen 1 eller fra ICC-et 5. Kontakter 60 som forekommer i stammeprogrammet før bruksvalg, blir tilordnet en nullstandardoppførsel av TRS. Dersom en gitt kontakt 60 blir plugget med en prosedyre av mer enn én modul, vil siste operasjon ganske enkelt erstatte eventuelle tidligere operasjoner. Typically, the VM 20 which is run on a terminal 1 can have a limited number of contacts 60, e.g. 64 contacts, numbered from 0 to 63 inclusive. In its most basic form, a terminal program trunk would be made up almost entirely of contacts 60 and basic program flow from contact to contact. The contacts 60 would then be plugged with transaction processing procedures of other modules loaded at the time of use selection, either from the terminal 1 or from the ICC 5. Contacts 60 occurring in the trunk program before use selection are assigned a zero default behavior by the TRS. If a given connector 60 is plugged with a procedure of more than one module, the last operation will simply replace any previous operations.

Kode skrevet for å kjøres på VM-en 20 (innbefattet terminalresidente tjenester kompilert som symbolmoduler) kan anta at etterfølgende oppstart av den terminalspesifikke kjernepro-gramvare som støtter VM-en 20, har utført eventuell, nødven-dig, terminalspesifikk oppstart-initialisering, og har begynt utførelse av hovedbehandlingssløyfen i terminalresidente tjenester (TRS) gjennom en modulinnlastingsprosess som er beskrevet nedenfor. Dersom hovedbehandlingssløyfen i TRS blir avsluttet, går styringen tilbake til det terminalspesifikke lag av programvare som er ansvarlig for ny innlasting av TRS og ny innlegging av dennes hovedsløyfe. Alle VM-ressurser blir frigjort når TRS avsluttes, bortsett fra data i ikke-flyktige databaser. Frigjørelse av ressurser skjer når strøm-men koples ut på terminalen, TRS avsluttes, eller TRS startes igjen av terminalens operativsystem (hvis slikt finnes). Dersom det er ervervet en oppdatert versjon av en eller annen TRS-modul siden TRS-hovedsløyfen sist ble lagt inn, blir alle TRS-ressurser innbefattet data i dens egne ikke-flyktige databaser frigjort når den avsluttes. Code written to run on the VM 20 (including terminal-resident services compiled as token modules) may assume that subsequent startup of the terminal-specific kernel software supporting the VM 20 has performed any necessary terminal-specific boot initialization, and has begun execution of the main processing loop in Terminal Resident Services (TRS) through a module loading process described below. If the main processing loop in the TRS is terminated, control returns to the terminal-specific layer of software which is responsible for reloading the TRS and re-entering its main loop. All VM resources are freed when TRS terminates, except for data in non-volatile databases. Resources are released when the terminal is powered off, TRS is terminated, or TRS is restarted by the terminal's operating system (if available). If an updated version of any TRS module has been acquired since the TRS main loop was last entered, all TRS resources including data in its own non-volatile databases are freed when it exits.

Programvare kjørt på en terminal 1 eller et ICC 5 håndteres av VM-en 20 i form av én eller flere moduler, hvor hver modul kan inneholde hvilke som helst av følgende informasjonskate-gorier : Software run on a terminal 1 or an ICC 5 is handled by the VM 20 in the form of one or more modules, where each module can contain any of the following information categories:

- kode som symboler- code as symbols

- initialiserte data- initialized data

- ikke-initialisert datatildeling- uninitialized data allocation

- databasedefinisjoner- database definitions

- TLV-definisjoner- TLV definitions

- kontaktliste- contact list

- modulers innbyrdes avhengighet- interdependence of modules

Hver modul blir fortrinnsvis levert til en terminal 1 i et modulleveringsformat (MDF). VM-en 20 opprettholder et ikke-flyktig oppbevaringssted i det ikke-flyktige lese/skriveminne 18 med moduler som er blitt levert og installert i terminalen 1. Hver modul på oppbevaringsstedet skal være identifisert ved en modulidentifikator eller modul-ID. Etter registrering på moduloppbevaringsstedet er modulinformasjon tilgjengelig gjennom en ikke-flyktig moduldatabase som opprettholdes av VM-en 20 og lagres i ikke-flyktig minne 18. I overensstemmelse med den herværende oppfinnelse beskytter VM-en 20 moduler innenfor oppbevaringsstedet mot modifisering fra eventuell annen modul, fordi det ikke finnes noen symboler for slik tilgang. Videre gir VM-en 20 rom for plassering av en ny utgave av en gitt modul på oppbevaringsstedet, mens en modul med samme modul-ID finnes til utførelsesformål. Each module is preferably delivered to a terminal 1 in a module delivery format (MDF). The VM 20 maintains a non-volatile storage location in the non-volatile read/write memory 18 with modules that have been delivered and installed in the terminal 1. Each module in the storage location shall be identified by a module identifier or module ID. After registration at the module repository, module information is available through a non-volatile module database maintained by the VM 20 and stored in non-volatile memory 18. In accordance with the present invention, the VM 20 protects modules within the repository against modification by any other module, because there are no symbols for such access. Furthermore, the VM 20 provides space for placing a new edition of a given module in the repository, while a module with the same module ID exists for execution purposes.

Begrepsmessig finnes det to faser ved behandling av en modul: for det første blir den "lastet inn", hvilket betyr at den gjøres tilgjengelig, og dens data, databaser osv. momentan-velges, og for det andre, dersom det er en utførbar modul, begynner VM-en 20 behandlingen av dens symboler, idet den be gynner ved inngangspunktet. Utførelsesprosedyren vil bli beskrevet under henvisning til flytdiagrammet på fig. 9. Conceptually, there are two phases in processing a module: first, it is "loaded", meaning it is made available, and its data, databases, etc. are momentarily selected, and second, if it is an executable module , the VM 20 begins processing its symbols, starting at the entry point. The execution procedure will be described with reference to the flow diagram of fig. 9.

Først, i trinn 100, blir ressursene merket og lagret. Før ut-førelse av en modul merker VM-en 20 modulens tilstand og lagrer eventuelle ressurser som er nødvendige, slik at denne tilstand kan gjenopprettes senere. Tilstanden innbefatter: First, in step 100, the resources are tagged and stored. Before executing a module, the VM 20 notes the module's state and stores any resources that are necessary, so that this state can be restored later. The condition includes:

- Posisjonen for utvidbart-minne-pekeren, rammepekeren,- The position of the expandable-memory pointer, the frame pointer,

og rammeendepekeren.and the frame end pointer.

- Innholdet i hele den gjeldende kontaktliste.- The contents of the entire current contact list.

- TLV-ene registrert i TLV-etikettnavnelisten.- The TLVs registered in the TLV label name list.

- Andre interne data som VM-implementeringen trenger for å håndtere aktiveringen og utføringen av moduler. - Other internal data that the VM implementation needs to handle the activation and execution of modules.

Deretter blir modulen.lastet inn i trinn 102. Modul-ID-en for den modul som skal utføres, blir overført til underrutinen Last inn Modul som vil bli beskrevet senere. Dersom modulen blir lastet inn uten feil som bestemt i trinn 104, kan den utføres, og programmet fortsetter til trinn 108. Dersom en feil blir påvist i trinn 104, forlates utførelsen av modulen og alle ressurser som er nødvendige for utførelse av modulen, blir frigjort i trinn 105. Dette krever at VM-en 20 utfører følgende handlinger: - Alt flyktig minne som kreves for å laste inn modulen, og enhver modul som den krevde innlasting av, må frigjøres og slettes til null. Dette innbefatter, men er ikke begrenset til: - Området som behøves til alle modulens initialiserte og ikke-initialiserte data. - Området som behøves for eventuelle interne TLV-buffere og håndteringsdatastrukturer definert av disse moduler. - Området som behøves for eventuelle interne buffere og håndteringsdatastrukturer som kreves av databaser definert av Then the module is loaded in step 102. The module ID of the module to be executed is transferred to the Load Module subroutine which will be described later. If the module is loaded without error as determined in step 104, it can be executed, and the program continues to step 108. If an error is detected in step 104, execution of the module is abandoned and all resources necessary for execution of the module are released. in step 105. This requires the VM 20 to perform the following actions: - All volatile memory required to load the module, and any module it required to be loaded, must be freed and cleared to zero. This includes, but is not limited to: - The area needed for all the module's initialized and uninitialized data. - The area needed for any internal TLV buffers and handling data structures defined by these modules. - The area needed for any internal buffers and handling data structures required by databases defined by

disse moduler.these modules.

- TLV-navnelisten opprettholdt i VM-en til gjenfinning av etiketter, må gjenopprettes til sin tilstand umiddelbart før modulutførelse. - Innholdet i kontaktlisten opprettholdt i VM-en må gjenopprettes til sin tilstand umiddelbart før modulutførelse. - Innholdet i rammepekeren, rammeendepekeren, og utvidbart-minne-pekeren gjenopprettes til verdiene umiddelbart før mo-dulutf ørelse . - The TLV name list maintained in the VM for label retrieval must be restored to its state immediately before module execution. - The contents of the contact list maintained in the VM must be restored to their state immediately before module execution. - The contents of the frame pointer, end-of-frame pointer, and expandable-memory pointer are restored to the values immediately before module execution.

Etter vellykket innlasting av modulen, blir det i trinn 106 bestemt om modulen er en utførbar modul eller en bibliotekmo-dul. I tilfelle sistnevnte, skjer det ingen utførelse av modulen, og VM-en 20 frigir alle ressurser i trinnet 110 som beskrevet for trinn 105. Dersom modulen er utførbar, påvises feltet som spesifiserer modulens inngangspunkt. VM-en 20 starter modulen ved å kalle opp symbolet angitt i inngangspunktfeltet. Deretter blir hvert symbol utført etter tur i trinn 108. Modulen avslutter ved å bruke et RETURN-symbol, hvoretter alle ressurser blir frigitt i trinn 110. After successfully loading the module, it is determined in step 106 whether the module is an executable module or a library module. In the latter case, no execution of the module occurs, and the VM 20 releases all resources in step 110 as described for step 105. If the module is executable, the field specifying the module's entry point is detected. The VM 20 starts the module by calling the symbol specified in the entry point field. Then, each symbol is executed in turn in step 108. The module exits by using a RETURN symbol, after which all resources are released in step 110.

Prosessen som kreves for å laste inn en modul, underrutinen "Last inn modul", vil bli beskrevet under henvisning til flytdiagrammet vist på fig. 10. Dersom det oppdages en feil under innlasting av modulen, får dette underrutinen "Last inn modul" til straks å melde " false" ( ukorrekt). En generell feil er en slik som "utenfor minne" hvor det ikke er til-strekkelige ressurser til å tilveiebringe plass til initialiserte data, ikke-initialiserte data, databaser, eller TLV-er; når en duplikat-TLV-etikett oppdages; og så videre. Initialiserte data må settes opp før behandling av databasen og TLV-seksjonene, da disse er en del av den initialiserte datasek sjon. I trinn 120 blir det fastslått om modulen allerede er lastet inn i minne. Hvis den allerede er lastet inn, blir den ikke lastet for andre gang, og "Last inn modul" er straks vellykket og melder "true" ( korrekt). Deretter blir det i trinn 122 fastslått om modulen er på oppbevaringsstedet. Hvis ikke, kan den ikke lastes inn, slik at underrutinen "Last inn modul" svikter og melder false. I trinn 124 blir det fastslått hvor mange byte data som behøves for modulens ikke-initialiserte dataområde 41, og den nødvendige mengde reser-veres. Dette område 41 blir satt til bare nuller av VM-en 20. På lignende måte blir-i trinn 126 det nødvendige antall byte data for modulens initialiserte dataområde 42 reservert. Deretter blir de initialiserte data kopiert til dette område. I trinn 18 blir TLV-ene som er definert i den modul som skal lastes inn, tilføyd av VM-en 20 i dennes interne navneliste benyttet til å slå opp TLV. Roten i TLV-data-strukturen blir lagret. Deretter, i trinn 130, blir databasene som er definert i den modul som skal lastes inn, momentanvalgt av VM-en 20. Trinn 128 og 130 kan utføres i hvilken som helst rekke-følge. I trinn 132 blir de importere moduler for den aktuelle modul valgt. I trinn 134 blir listen over importerte moduler gjennomlest, og hver modul rekursivt lastet inn etter tur. Dersom en importert modul av en eller annen grunn ikke kan lastes inn, som bestemt i trinn 136, blir den modul som importerte modulen, også bedømt som å ha mislykket innlasting, da den ikke kan få tilgang til den importerte moduls tjenester. I dette tilfelle melder "Last inn modul" false. I trinn 138 blir det bestemt om en ytterligere modul skal importeres. Hvis ja, går prosedyren tilbake til trinn 132. Etter bestem-melsen i 138 om at den sist importerte modul er blitt rekursivt innlastet, har den aktuelle modul fått sine ressurser tildelt, innlastet og momentanvalgt uten feil, slik at "Last inn modul" plugger kontaktene 60 på sin liste i trinn 139 og deretter melder true, hvorved angis at modulen ble lastet inn vellykket. Ethvert forsøk på å plugge kontakt null må ignore-res av VM-en 20. Dersom kontakt null må plugges, kan dette oppnås ved å benytte SETSOCKET-symbolet. The process required to load a module, the "Load Module" subroutine, will be described with reference to the flow diagram shown in FIG. 10. If an error is detected while loading the module, this causes the "Load module" subroutine to immediately report "false" (incorrect). A general error is one such as "out of memory" where there are insufficient resources to provide space for initialized data, uninitialized data, databases, or TLVs; when a duplicate TLV label is detected; and so on. Initialized data must be set up before processing the database and the TLV sections, as these are part of the initialized data section. In step 120, it is determined whether the module has already been loaded into memory. If it has already been loaded, it will not be loaded a second time, and "Load module" is immediately successful and reports "true". Then, in step 122, it is determined whether the module is at the storage location. If not, it cannot be loaded, so the "Load Module" subroutine fails and reports false. In step 124, it is determined how many bytes of data are needed for the module's non-initialized data area 41, and the required amount is reserved. This area 41 is set to only zeros by the VM 20. In a similar way, in step 126, the required number of bytes of data for the module's initialized data area 42 is reserved. The initialized data is then copied to this area. In step 18, the TLVs defined in the module to be loaded are added by the VM 20 in its internal name list used to look up the TLV. The root of the TLV data structure is stored. Then, in step 130, the databases defined in the module to be loaded are momentarily selected by the VM 20. Steps 128 and 130 can be performed in any order. In step 132, the import modules for the relevant module are selected. In step 134, the list of imported modules is read, and each module recursively loaded in turn. If an imported module cannot be loaded for some reason, as determined in step 136, the module that imported the module is also judged to have failed to load, as it cannot access the imported module's services. In this case, "Load module" reports false. In step 138, it is decided whether a further module is to be imported. If yes, the procedure returns to step 132. Following the determination in 138 that the last imported module has been recursively loaded, the module in question has had its resources allocated, loaded and momentarily selected without error, so that "Load module" plugs the contacts 60 in its list in step 139 and then reports true, indicating that the module was loaded successfully. Any attempt to plug contact zero must be ignored by the VM 20. If contact zero must be plugged, this can be achieved by using the SETSOCKET symbol.

Prosedyren for plugging av kontaktene 60 i trinn 140 vil bli beskrevet under henvisning til fig. 11. I trinn 140 momentan-velges standardoppførselen for hver kontakt i en innlastet modul. I trinn 141 blir det fastslått om det finnes en plugg. Hvis nei, blir modulen utført i trinn 149. Hvis ja, blir den første plugg valgt i trinn 142. I 143 blir det fastslått om sikkerhetsflagget for den tilhørende kontakt er satt opp eller ikke. Hvis ikke, blir kontakten plugget i trinn 146. Hvis ja, blir sikkerhetsfunksjonen angitt for kontakten utført. Dersom sikkerhetsvurderingen er positiv, blir kontakten plugget i trinn 146. I trinn 148 blir det fastslått om pluggen er den siste plugg. Hvis nei, blir neste plugg valgt for vurde-ring. Dersom sikkerhetskontrollen er negativ, blir det fastslått om pluggen er den siste plugg i trinn 147. Dersom det i trinn 147 eller 148 blir fastslått at pluggen er den siste, blir modulen utført med standardoppførsel for alle kontakter som ikke er blitt plugget, og med plugget oppførsel for dem som er blitt plugget. Ved dette middel er det oppnådd en sikker oppførselsmodifisering. The procedure for plugging the contacts 60 in step 140 will be described with reference to fig. 11. In step 140, the default behavior is momentarily selected for each contact in a loaded module. In step 141, it is determined whether there is a plug. If no, the module is executed in step 149. If yes, the first plug is selected in step 142. In 143, it is determined whether the security flag for the associated socket is set or not. If not, the connector is plugged in step 146. If yes, the security function specified for the connector is performed. If the safety assessment is positive, the connector is plugged in step 146. In step 148, it is determined whether the plug is the last plug. If no, the next plug is selected for evaluation. If the security check is negative, it is determined whether the plug is the last plug in step 147. If it is determined in step 147 or 148 that the plug is the last, the module is executed with standard behavior for all contacts that have not been plugged, and with the plug behavior for those who have been plugged. By this means, a safe modification of behavior has been achieved.

Moduler som blir lastet fra et ICC 5 av LOADCARDMODULE-symbol, må håndteres annerledes enn dem som lastes inn fra oppbevaringsplassen i'terminalen 1 ved bruk av EXECUTEMODULE-symbolet. Flytskjemaet for LOADCARDMODULE er vist på fig. 12. Før utførelse av en kortmodul, merker VM-en 20 dens tilstand og bevarer de ressurser som måtte behøves i trinn 150, slik at denne tilstand kan gjenopprettes senere. Tilstanden innbefatter: - Posisjonen for utvidbart-minne-pekeren, rammepekeren, og rammeendepekeren. Modules loaded from an ICC 5 by LOADCARDMODULE symbol must be handled differently than those loaded from the terminal 1 storage space using the EXECUTEMODULE symbol. The flowchart for LOADCARDMODULE is shown in fig. 12. Before executing a card module, the VM 20 notes its state and preserves the resources that may be needed in step 150, so that this state can be restored later. The state includes: - The position of the expandable-memory pointer, the frame pointer, and the end-of-frame pointer.

- Andre interne data som VM-implementeringen behøver for å styre aktiveringen av kortmoduler. - Other internal data that the VM implementation needs to control the activation of card modules.

Modulen blir lastet inn i trinn 152 ved bruk av rutinen "Last inn modul" beskrevet ovenfor under henvisning til fig. 9, idet forskjellen er at modulen er på ICC-et 5 og ikke befinner seg på oppbevaringsstedet og ikke allerede er lastet inn. The module is loaded in step 152 using the "Load Module" routine described above with reference to FIG. 9, the difference being that the module is on the ICC 5 and is not in the storage location and has not already been loaded.

Dersom det i trinn 154 fastslås at kortmodulen ikke ble lastet inn vellykket, blir alle ressurser returnert i trinn 155 til den tilstand de hadde umiddelbart før utførelse av LOADCARDMODULE-symbolet. Dette krever at: - Alt flyktig minne som er nødvendig til innlasting av modulen, og enhver modul som den krevde innlastet, må bli frigjort og slettet til null. Dette skal innbefatte, men er ikke begrenset til: - Nødvendig område for alle modulers initialiserte og ikke-initialiserte data. - Nødvendig område for eventuelle interne TLV-buffere og håndteringsdatastrukturer definert av disse moduler. - Nødvendig område for eventuelle interne buffere og håndteringsdatastrukturer som kreves av databaser definert av disse moduler. - TLV-navnelisten som opprettholdes av VM-en til gjenfinning av etiketter, må gjenopprettes til sin tilstand umiddelbart før modulutførelse. - Innholdet i kontaktlisten opprettholdt av VM-en må gjenopprettes til sin tilstand umiddelbart før modulutførelse. - Innholdet i rammepekeren, rammeendepekeren, og utvidbart-minne-pekeren blir gjenopprettet til verdiene If it is determined in step 154 that the card module was not loaded successfully, all resources are returned in step 155 to the state they had immediately before execution of the LOADCARDMODULE symbol. This requires that: - All volatile memory required to load the module, and any module it required loaded, must be freed and cleared to zero. This shall include, but is not limited to: - Necessary area for all modules' initialized and uninitialized data. - Necessary area for any internal TLV buffers and handling data structures defined by these modules. - Required area for any internal buffers and handling data structures required by databases defined by these modules. - The TLV namelist maintained by the VM for label retrieval must be restored to its state immediately prior to module execution. - The contents of the contact list maintained by the VM must be restored to their state immediately before module execution. - The contents of the frame pointer, end-of-frame pointer, and expandable-memory pointer are restored to their values

umiddelbart før modulutførelse.immediately before module execution.

Dersom kortmodulen blir lastet inn vellykket, vil tilstanden bevart i trinnet 150 "Merk og bevar ressurser" ganske enkelt bli slettet i trinn 156. En kortmodul er således blitt podet inn i et system som kjører. For å være til nytte må en kortmodul plugge kontakter, ellers finnes det ikke noen måte for utføring av noen som helst kode som måtte finnes i kortmodulen. Deretter blir det i trinn 158 fastslått om modulen er en utførbar modul, og i så fall blir den utført i trinn 160 som beskrevet under henvisning til trinn 106 og 108 på fig. 9. If the card module is loaded successfully, the state preserved in step 150 "Mark and preserve resources" will simply be deleted in step 156. A card module has thus been grafted into a running system. To be useful, a card module must plug contacts, otherwise there is no way to execute any code that may exist in the card module. Then, in step 158, it is determined whether the module is an executable module, and if so, it is executed in step 160 as described with reference to steps 106 and 108 in fig. 9.

De spesifikke utførelser av oppfinnelsen beskrevet ovenfor er kun ment å være illustrative, og mange andre variasjoner og modifiseringer kan foretas på den i overensstemmelse med oppfinnelsens prinsipper. Alle slike utførelser og varianter og modifikasjoner av den ansees å ligge innenfor oppfinnelsens ramme som definert i de etterfølgende krav. The specific embodiments of the invention described above are intended to be illustrative only, and many other variations and modifications may be made thereon in accordance with the principles of the invention. All such designs and variants and modifications thereof are considered to be within the scope of the invention as defined in the following claims.

VEDLEGGATTACHMENTS

1. Symboldefinering1. Symbol definition

1.1 Oversikt1.1 Overview

EPICode-symboler er instruksjonssettet for en to-stakkers virtuell datamaskin med en rammepeker i tillegg. Symbolene kan også behandles som et mellomværende språk for en kompila-tor. Noen implementeringer av programoversetteren kan faktisk kompilere EPICode-symboler til maskinkode. EPICode symbols are the instruction set for a two-stack virtual computer with an additional frame pointer. The symbols can also be treated as an intermediate language for a compiler. Some implementations of the program translator can actually compile EPICode symbols into machine code.

ElPCode-symboler er bytesymboler som tillater maksimalt 256 symboler. En-bytes prefikssymboler tillater rekken av symboler å bli utvidet til et teoretisk maksimum på 65536 symboler, hvor prefiksene ansees å definere sider på 256 symboler hver. Faktisk blir en begrenset rekke av prefiks-symboler definert. Hver symbolverdi blir vist i heksadesimal som en 2-sifret heksadesimalkode sammen med dens tilhørende navn. Symboler uten prefiks (én-bytes symboler) blir kalt primærsymboler, mens de som har prefiks (to-bytes symboler), blir kalt se^undærsymboler. ElPCode symbols are byte symbols that allow a maximum of 256 symbols. One-byte prefix symbols allow the range of symbols to be extended to a theoretical maximum of 65536 symbols, where the prefixes are considered to define pages of 256 symbols each. In fact, a limited number of prefix symbols are defined. Each symbol value is displayed in hexadecimal as a 2-digit hexadecimal code along with its associated name. Symbols without a prefix (one-byte symbols) are called primary symbols, while those with a prefix (two-byte symbols) are called secondary symbols.

Utførelsen av hvilket som helst primær- eller sekundærsymbol som ikke er definert i nedenstående liste, vil forårsake en ILLOP-unntakssituasjon. The execution of any primary or secondary symbol not defined in the list below will cause an ILLOP exception situation.

1.1.1 Forth-funksjoner for EPICode-symboler1.1.1 Forth functions for EPICode symbols

Dette avsnitt viser en alfabetisk samsvarsliste over Forth-ord benyttet som EPICode-symboler. Hver linje inneholder fra venstre mot høyre: - Definisjonsnavn med øvre tastesett, mono-space og fet skrift; - Naturlig språk dersom dette avviker fra engelsk; This section shows an alphabetical matching list of Forth words used as EPICode symbols. Each line contains, from left to right: - Definition name with upper keyset, mono-space and bold; - Natural language if this differs from English;

- Spesielle betegnelser, etter behov- Special designations, as needed

A ANS Forth ord (innbefattet alle valgfrie A ANS Forth words (including all optional

ordsett)word set)

C Kompilatordirektiv; må brukes inne i en C Compiler Directive; must be used inside a

definisjondefinition

G Generisk Forth ord (i vanlig bruk, f.eks. G Generic Forth word (in common use, e.g.

Forth Interest Group, men ikke i ANS Forth). Forth Interest Group, but not in ANS Forth).

H Verts(kompilator)ord, som både kan og ikke kan bidra med symboler til målet. H Host (compiler) word, which can and cannot contribute symbols to the target.

- Likeverdig(e) EPICode-symbol(er) - Equivalent EPICode symbol(s)

1.2 Regler 1.2 Rules

1.2.1 Nummerformater1.2.1 Number formats

Nummer større enn én byte blir overført i symbolprogrammer i "storendet" 2-er-komplementform med den mest signifikante byte først. Innenfor et EPICode-program skal operatørers tilgang til numre alltid skje i det korrekte format for å tillate programmer å lagre numre i den form som er best egnet for den underliggende struktur. Numbers larger than one byte are transferred in symbol programs in "big-ended" 2's complement form with the most significant byte first. Within an EPICode program, operators' access to numbers must always be in the correct format to allow programs to store numbers in the form best suited to the underlying structure.

Flerpresisjonsdatatyper holdes på stakken med den mest signifikante celle øverst. I minne blir disse datatyper bevart med den mest signifikante celle i den lavest-adresserte celle innenfor typen med flere celler. Multi-precision data types are held on the stack with the most significant cell at the top. In memory, these data types are stored with the most significant cell in the lowest-addressed cell within the multi-cell type.

1.2.2 Kontrollstrukturer og adressedifferanser Kontrollstrukturer blir utformet gjennom et kontrollsymbol (BRA, RLOOP, osv.) etterfulgt av en fortegnsbestemt fire-bytes, to-bytes, eller én-bytes adressedifferanse. Adressedifferansen som følger etter kontrollsymbolet, blir lagt til 1.2.2 Control structures and address differences Control structures are formed through a control symbol (BRA, RLOOP, etc.) followed by a signed four-byte, two-byte, or one-byte address difference. The address difference that follows the control symbol is added

symbolpekeren (TP) etter at adressedifferansen er hentet. Hvis et grensymbol er i addr, blir således måladressen addr+ 2+ adressedifferanse for en 1-bytes adressedifferanse (SBRA), addr+ 3+ adresssdifferanse for en 2-bytes adressedifferanse (BRA) og addr+ 5+ adressedifferanse for en 4-bytes adressedifferanse (EBRA). the symbol pointer (TP) after the address difference is fetched. Thus, if a branch symbol is in addr, the target address becomes addr+ 2+ address difference for a 1-byte address difference (SBRA), addr+ 3+ address difference for a 2-byte address difference (BRA) and addr+ 5+ address difference for a 4-byte address difference (EBRA ).

Symboler som tar fire-bytes adressedifferanser er tilgjengelige bare for terminalspesifikk kode ved implementeringer av virtuell datamaskin som støtter et 32 bits lineasradresseområ-de for koden. Symbols that take four-byte address ranges are available only to terminal-specific code on virtual computer implementations that support a 32-bit linear address space for the code.

1.2.3 Adresser1.2.3 Addresses

Brukerdefinerte prosedyrer blir definert gjennom sine adresser innenfor EPICode-programmet. Dersom symbolene blir over-satt eller egen-kode-kompilert for større prosessorer, vil symbolområdeadressen ikke tilsvare kodens faktiske adresse. User-defined procedures are defined through their addresses within the EPICode program. If the symbols are translated or self-code compiled for larger processors, the symbol area address will not correspond to the code's actual address.

1.3 Datatypifisering1.3 Data typification

De fleste symboler opererer på mengder med en datastørrelse og en fortegnsbestemt eller ikke-fortegnsbestemt tolking bestemt av symbolet, men instruksjoner som gir tilgang til minne i rammelageret, kan ta en datatypeoverstyring bestemt ved et prefikssymbol. Et bytesett, vist i tabell 1, er reservert for slike prefikssymboler, men bare SBYTE og UBYTE blir brukt i dag. Most symbols operate on quantities with a data size and a signed or unsigned interpretation determined by the symbol, but instructions that access memory in the frame store may take a data type override determined by a prefix symbol. A byte set, shown in Table 1, is reserved for such prefix symbols, but only SBYTE and UBYTE are used today.

Datatyper som krever mindre enn én celle (1 byte), hentes fra minne ved å bruke en byteoperatør eller en operatør med et overstyringsprefiks. Dersom en fortegnsbestemt datatype blir anvendt eller spesifisert, blir dataene tegn-utvidet til cel-lebredde. Dersom en ikke-fortegnsbestemt datatype blir anvendt eller spesifisert, blir dataene null-utvidet. Data types that require less than one cell (1 byte) are retrieved from memory using a byte operator or an operator with an override prefix. If a signed data type is used or specified, the data is character-extended to cell width. If an unsigned data type is used or specified, the data is null-extended.

Tabell 1: Datatypeprefikser Table 1: Data type prefixes

1.4 Aritmetikk1.4 Arithmetic

Addisjons- og subtraksjonsoperasjoner som overskrider den størrelse som er angitt for det returnerte resultat, vil melde den resultatmodulo [maksimal ikke-fortegnsbestemt verdi som kan rommes i den størrelse]+1. Addition and subtraction operations that exceed the size specified for the returned result will report the result modulo [maximum unsigned value that can fit in that size]+1.

Lagreoperasjoner hvis mållager er mindre enn størrelsen på den overførte verdi, vil lagre verdien avkuttet til målområ-dets bredde. Store operations whose target storage is smaller than the size of the transferred value will store the value truncated to the width of the target area.

Divisjonsoperasjoner er symmetriske; dvs, avrunding skjer alltid mot null uansett tegn. Division operations are symmetrical; i.e., rounding always takes place towards zero regardless of the sign.

1.5 Primærsymboler1.5 Primary Symbols

Symboler blir inndelt i flere logiske sett av bekvemmelig-hetshensyn og er vist i separate avsnitt nedenfor. Alle sym-bolverdier er i heksadesimal. Symbols are divided into several logical sets for convenience and are shown in separate sections below. All symbol values are in hexadecimal.

Datatypeprefikser som.kan benyttes på symbolene, er satt opp uttrykkelig, idet forkortelsene gitt i tabell 1 blir benyttet. Ethvert primærsymbol med et prefiks i form av et symbol som ikke finnes i dets prefiksliste, er ugyldig, og utførel- sen av et slikt symbol fører til at det fremsettes en ILLOP-unntakssituasjon. Standardtypen for symbolet er skrevet i kursiv, og kommer alltid først. Standarddatatype-prefikset er overflødig og er ugyldig dersom det brukes som prefiks for et symbol, som ovenfor. Data type prefixes that can be used on the symbols are set up explicitly, as the abbreviations given in table 1 are used. Any primary symbol prefixed with a symbol not found in its prefix list is invalid, and the execution of such a symbol causes an ILLOP exception to be thrown. The default type for the symbol is written in italics, and always comes first. The default data type prefix is redundant and is invalid if used as a symbol prefix, as above.

1.5.1 Operasjonssett1.5.1 Operation set

00 NOOP00 NOOP

( ) ( )

Ingen handling iverksatt.No action taken.

04 BFETCHS04 BFETCHS

( addr - num )(addr-num)

Hent en 8 biters byte fra den gitte adresse, hvor tegn forlenger den. Get an 8-bit byte from the given address, where characters extend it.

08 LIT08 LIT

f -x ; f - x ;

Returner cellen som følger i rekken, som da-ta. Return the cell that follows in the row, like da-ta.

09 LITC09 LITC

( - addr )( - addr )

Returner cellen som følger i rekken, som litteral som er en adresse i kodebildet. Verdien av litteralen kan lokaliseres igjen i det bilde av programinnlasteren. Return the cell that follows in the row, as a literal that is an address in the code image. The value of the literal can be located again in that image by the program loader.

OA LITDOA LTD

( - addr )( - addr )

Returner cellen som følger i rekken, som en litteral som er en adresse i et initialisert dataområde. Verdien av litteralen kan lokaliseres igjen i det bilde av programinnlasteren . Return the cell that follows in the row as a literal that is an address in an initialized data area. The value of the literal can be located again in that image of the program loader.

OB LITUOB LITU

( - addr )( - addr )

Returner cellen som følger i rekken som en litteral som er en adresse i ikke-initialisert dataområde. Verdien av litteralen kan lokaliseres igjen i det bilde av programinnlasteren. Return the cell following in the row as a literal that is an address in uninitialized data space. The value of the literal can be located again in that image by the program loader.

0C PLIT0C COB

( -u ; ( -u ;

Returner den byte som følger i rekken. Byten blir nullutvidet til 32 biter. Return the next byte in the sequence. The byte is zero extended to 32 bits.

OD NLITOD NLIT

( — num )( — num )

Returner den byte som følger i rekken, nullutvidet til 32 biter og deretter negert. Return the next byte in the sequence, zero-extended to 32 bits and then negated.

OE HLITOE HLIT

( - u )( - u )

Returner 2-bytesverdien som følger i rekken. Verdien er nullutvidet til 32 biter. Return the 2-byte value that follows the sequence. The value is zero extended to 32 bits.

10 HLITC10 HLITC

( - addr )( - addr )

Returner adressen som er resultatet av å legge den ikke-fortegnsbestemte 2-bytesverdi som følger i rekken, til kodebildets grunnadresse. Verdien er nullutvidet til 32 biter. Return the address resulting from adding the unsigned 2-byte value that follows the array to the base address of the code image. The value is zero extended to 32 bits.

11 SLITD11 WEAR

( a addr )( a addr )

Returner adressen som er resultatet av å legge den ikke-fortegnsbestemte byte som følger i rekken, tolket som en positiv adressedifferanse i celler, til initialiserte datas grunnadresse. Byten er nullutvidet til 32 biter og multiplisert med 4 for å gi en adressedifferanse i byte. Return the address resulting from adding the unsigned byte following the row, interpreted as a positive address difference in cells, to the initialized data's base address. The byte is zero extended to 32 bits and multiplied by 4 to give an address difference in bytes.

12 HLITD12 HLITD

( - addr )( - addr )

Returner adressen som er resultatet av å legge 2-bytesverdien som følger i rekken, til initialiserte datas grunnadresse. Verdien er fortegnsutvidet til 32 biter. Return the address resulting from adding the 2-byte value following the array to the initialized data's base address. The value is sign extended to 32 bits.

13 SLITU13 WEAR

( - addr )( - addr )

Returner adressen som er resultatet av å legge den ikke-fortegnsbestemte byte som følger i rekken, tolket som en positiv adressedifferanse i celler, til ikke initialiserte datas grunnadresse. Byten er nullutvidet til 32 biter og multiplisert med 4 for å gi en adressedifferanse i byte. Return the address resulting from adding the unsigned byte that follows the row, interpreted as a positive address difference in cells, to the uninitialized data's base address. The byte is zero extended to 32 bits and multiplied by 4 to give an address difference in bytes.

14 HLITU14 SHUT UP

( - addr )( - addr )

Returner adressen som er resultatet av å legge 2-bytesverdien som følger i rekken, til ikke-initialiserte datas grunnadresse. Verdien er fortegnsutvidet til 32 biter. Return the address resulting from adding the 2-byte value following the array to the uninitialized data's base address. The value is sign extended to 32 bits.

15 ADDLIT15 ADDLIT

( Xi- X2 )(Xi-X2)

Legg dataene i cellen som følger i rekken, til Xi, hvilket gir x2. Add the data in the next cell in the row to Xi, giving x2.

16 SADDLIT16 SADDLIT

( Xj- X? )( Xj - X? )

Legg en litteral fra den fortegnsbestemte énbytesverdi som følger i rekken, til Xi, hvilket gir x2. Add a literal from the signed one-byte value that follows in the array to Xi, yielding x2.

19 SUBLIT19 SUBLIT

( x,-x?; (x,-x?;

Trekk dataene i cellen som følger i rekken, fra Xi, hvilket gir x2. Subtract the data in the next cell in the row from Xi, giving x2.

IA SSUBLITIA SSUBLIT

(X/—x?-t ) (X/—x?-t )

Trekk den fortegnsbestemte énbytesverdi i rekken fra Xi, hvilket gir x2. Subtract the signed one-byte value in the row from Xi, yielding x2.

1C VSUBLIT1C VSUBLIT

( d - d lit )( d - d lit )

Trekk den fortegnsbestemte åttebytesverdi i rekken fra dobbeltnummeret d. Subtract the signed eight-byte value in the row from the double number d.

ID SMULLITID SMULLIT

( num — num* lit )( num — num* lit )

Multipliser num med den fortegnsbestemte énbyteslitteral som følger i rekken. Multiply num by the signed one-byte literal that follows in the sequence.

1E SDIVLIT1ST DIVISION

( num — num/ lit )( num — num/ lit )

Divider num med den fortegnsbestemte énbyteslitteral som følger i rekken. Divide num by the signed one-byte literal that follows in the sequence.

21 DIVU21 DIVU

( U/U - u3)(U/U - u3)

Divider u; med u? (ikke-fortegnsbestemt), hvilket gir u3. Divide u; with u? (unsigned), which gives u3.

3A SHRU3A SHRU

( u - u»l)(u - u»l)

Logisk skift u høyre én bit, idet det settes inn en null-bit. Logical shift u right one bit, inserting a zero bit.

NB: SETxx-operatørene utfører en sammenligning med null, hvor flagget settes opp alt etter resultatet av denne sammenligning. NB: The SETxx operators perform a comparison with zero, where the flag is set according to the result of this comparison.

42 SETGE42 SET

( num - flag )(num-flag)

Returner TRUE (korrekt) dersom num > 0 (fortegnsbestemt). Return TRUE (correct) if num > 0 (signed).

45 SETLE45 NOTES

( num - flag )(num-flag)

Returner TRUE hvis num < 0 (fortegnsbestemt) . Return TRUE if num < 0 (signed) .

4 8 CMPGEU4 8 CMPGEU

( u.Uj- flag )(u.Uj flag)

Sammenlign de ikke-fortegnsbestemte verdierUjogUo og returner TRUE dersom ui<>>u2. Compare the unsigned valuesUjogUo and return TRUE if ui<>>u2.

4C CMPGE4C CMPGE

( nummum?— flag )( nummum?— flag )

Sammenlign de fortegnsbestemte verdier num; Compare the signed values num;

og num? og returner TRUE hvis numi> num2. and num? and return TRUE if numi> num2.

4 F CMPLE4 F CMPLE

( numinum2- flag )(numinum2 flag)

Sammenlign de fortegnsbestemte verdier num;Compare the signed values num;

og num? og returner TRUE hvis numj< num2. and num? and return TRUE if numj< num2.

Følgende symboler gir tilgang til rammelageret. The following symbols provide access to the frame store.

50..53 PFRFETCH2...PFRFETCH550..53 PFRFETCH2...PFRFETCH5

( — num )( — num )

Kortformekvivalenter av SFRFETCHn (s.d.), hvor n er 2..5. Mulige datatypeoverstyringer innbefatter: SL, SB, UB. Short form equivalents of SFRFETCHn (s.d.), where n is 2..5. Possible data type overrides include: SL, SB, UB.

54..5F TFRFETCH12...TFRFETCH154..5F TFRFETCH12...TFRFETCH1

( — num )( — num )

Kortformekvivalenter av SFRFETCHn (s.d.), hvor n er -12..-1. Mulige datatypeoverstyringer innbefatter: SL, SB; UB Short form equivalents of SFRFETCHn (s.d.), where n is -12..-1. Possible data type overrides include: SL, SB; UB

60.. 63 PFRSTORE2...PFRSTORE560.. 63 PFRSTORE2...PFRSTORE5

( - num )( - num )

Kortformekvivalenter for SFRSTORE n (s.d.), hvor n er 2..5. Mulige datatypeoverstyringer innbefatter: SL, SB Short form equivalents for SFRSTORE n (s.d.), where n is 2..5. Possible data type overrides include: SL, SB

64..6F TFRSTORE12...TFRSTORE164..6F TFRSTORE12...TFRSTORE1

( num — )(num — )

Kortformekvivalenter for SFRSTORE n (s.d.), hvor n er -12..-1. Mulige datatypeoverstyringer innbefatter: SL, SB Short form equivalents for SFRSTORE n (s.d.), where n is -12..-1. Possible data type overrides include: SL, SB

7 0 SFRFETCH7 0 SFRFETCH

( — num )( — num )

Hent verdien (standard er celle) num i den fortegnsbestemte en-bytes adressedifferansen i rekken fra rammepekeren. Adressedifferansen blir tolket som et celleregister (dvs. den blir multiplisert med 4 for å gi en byteadressert adressedifferanse) for standard-datatypen, og som et byteregister for en dataoverstyring av bytestørrelse. Legg merke til at SFRFETCH 0 og SFRFETCH 1 returnerer interne rammehåndteringsdata som ikke har noen mening for programmet som kaller opp, og derfor ikke utgjør noen gyldige henvisninger i rammen. Parametere starter således ved SFRFETCH 2, og midlertidige variabler starter ved SFRFETCH -1, siden rammestakker vokser nedover i minne. Mulige datatypeoverstyringer innbefatter: SL, SB, UB Get the value (default is cell) num in the signed one-byte address difference in the row from the frame pointer. The address difference is interpreted as a cell register (ie, it is multiplied by 4 to give a byte-addressed address difference) for the standard data type, and as a byte register for a byte-sized data override. Note that SFRFETCH 0 and SFRFETCH 1 return internal frame handling data that has no meaning to the calling program, and therefore do not constitute valid references in the frame. Thus, parameters start at SFRFETCH 2, and temporary variables start at SFRFETCH -1, since frame stacks grow downward in memory. Possible data type overrides include: SL, SB, UB

71 SFRSTORE71 SFRSTORE

( num — )(num — )

Lagre verdien (standard er celle) num i påstanden i den fortegnsbestemte én-bytes adressedifferanse i rekken fra rammepekeren. Adressedifferansen tilveiebringes som en verdi i rekken, hvilken behandles som en celleindeks (dvs. den blir multiplisert med 4 for å gi en byteadressert adressedifferanse) for standard-datatypen, og som en byteindeks for en dataoverstyring av bytestør-relse. Se SFRFETCH for nærmere detaljer. Mulige datatypeoverstyringer innbefatter: Store the value (default is cell) num in the assertion in the signed one-byte address difference in the row from the frame pointer. The address difference is provided as a value in the row, which is treated as a cell index (ie it is multiplied by 4 to give a byte-addressed address difference) for the standard data type, and as a byte index for a byte-size data override. See SFRFETCH for details. Possible data type overrides include:

SL, SB.SL, SB.

7 2 FRFETCH7 2 FRFETCH

( num )( number )

Hent verdien num i den fortegnsbestemte adressedifferanse i rammepekeren. Adressedifferansen tilveiebringes gjennom en to-bytesverdi i rekken. Se beskrivelsen for SFRFETCH for flere detaljer. Mulige datatypeoverstyringer innbefatter: SL, SB, UB. Get the value num in the signed address difference in the frame pointer. The address difference is provided through a two-byte value in the row. See the description for SFRFETCH for more details. Possible data type overrides include: SL, SB, UB.

7 3 FRSTORE7 3 FREEZER

( num — ; ( num — ;

Lagre verdien num i påstanden i den fortegnsbestemte adressedifferanse fra rammepekeren. Adressedifferansen er tilveiebrakt gjennom en to-bytesverdi i rekken. Se SFRSTORE for ytterligere detaljer. Mulige datatypeoverstyringer innbefatter: SL, SB. Store the value num in the assertion in the signed address difference from the frame pointer. The address difference is provided through a two-byte value in the row. See SFRSTORE for further details. Possible data type overrides include: SL, SB.

7 4 SFRADDR7 4 SFRADDR

( - addr )( - addr )

Returner adressen i rammen ved den fortegnsbestemte adressedifferanse fra rammepekeren. Adressedifferansen er tilveiebrakt gjennom en én-bytes verdi i rekken, hvilken blir multiplisert med 4 for å gi en byte-adressedifferanse for standarddatatypen, og benyttes direkte som en byteindeks for en dataoverstyring av bytestørrelse. Mulige datatypeoverstyringer innbefatter: SL, SB Return the address in the frame by the signed address difference from the frame pointer. The address difference is provided through a one-byte value in the row, which is multiplied by 4 to give a byte address difference for the standard data type, and is used directly as a byte index for a data override of byte size. Possible data type overrides include: SL, SB

75 FRADDR75 FRADDR

( - addr )( - addr )

Returner adressen i rammen ved den fortegnsbestemte celle-adressedifferanse fra rammepekeren. Adressedifferansen tilveiebringes gjennom en to-bytesverdi i rekken, hvilken multipliseres med 4 for å gi en byte-adressedifferanse for standarddatatypen, og brukes direkte som en byteindeks for en dataoverstyring av bytestørrelse. Return the address in the frame by the signed cell address difference from the frame pointer. The address difference is provided through a two-byte value in the row, which is multiplied by 4 to give a byte address difference for the default data type, and is used directly as a byte index for a byte-size data override.

For symboler som gir støtte til Forth standard nummer-konverteringsfunksjoner: NMBR i symbolnavnene uttales "number". Symbolene LTNMBR, NMBRS og TONUMBER anvender brukervariabelen BASE som konverteringsnummergrunnlag. For symbols that support Forth's standard number conversion functions: NMBR in symbol names is pronounced "number". The symbols LTNMBR, NMBRS and TONUMBER use the user variable BASE as the conversion number basis.

8C UNDER8C BELOW

( X1X2—XiXiX2) (X1X2—XiXiX2)

Dupliker det andre element i stakken.Duplicate the second element in the stack.

9C ZERO9C ZERO

( - 0 )( - 0 )

La verdien 0 være igjen i stakken.Leave the value 0 on the stack.

9D ONE9D ONE

( - 1 )( - 1 )

La verdien 1 være igjen i stakken.Leave the value 1 on the stack.

9E MINUSONE9E MINUS ZONE

( - - 1 )( - - 1 )

La verdien -1 være igjen i stakken.Leave the value -1 on the stack.

AO INDEXAO INDEX

( addrLnum addr2)( addrLnum addr2)

Multipliser num med 4 og legg addr} til gitt addr2. Multiply num by 4 and add addr} to given addr2.

A2 EDOCREATEA2 EDOCREATE

( — a-addr )( — a-addr )

Returner adressen i dataområde hvis adressedifferanse følger i rekken i cellen umiddelbart etter dette symbol, og foreta en underrutineretur. Dette symbol blir benyttet til identifisering av et dataområde ved å kalle opp en prosedyre som tilsvarer dette, hvorved det er mulig å lage posisjonsuavhengige datatabeller. Return the address in the data area whose address difference follows in the row in the cell immediately after this symbol, and make a subroutine return. This symbol is used to identify a data area by calling a procedure that corresponds to this, whereby it is possible to create position-independent data tables.

A3 EDOCLASSA3 EDOCLASS

( a-addr )( a-addr )

Forgren til kodeområdeadressen hvis adressedifferanse finnes i cellen som følger i rekken, etter å ha skjøvet inn på datastakken den adresse som fremkommer ved å legge den ikke-fortengsbestemte adressedifferanse som følger i neste celle i rekken (dvs. etter kodeadressedifferansen) til grunnadressen for initialisert dataområde. Dette symbol blir benyttet til å identifisere en datastruktur i programminne og til å overføre styring til den rutine som behandler den, hvilket tilveiebringer grunnlaget for en enkel klassemekanisme. Branch to the code area address whose address difference is found in the cell following in the row, after pushing onto the data stack the address resulting from adding the non-prefixed address difference that follows in the next cell in the row (i.e. after the code address difference) to the initialized data area base address . This symbol is used to identify a data structure in program memory and to transfer control to the routine that processes it, providing the basis for a simple class mechanism.

A4 DOCREATEA4 DOCTORATE

( - a-addr .)( - a-addr .)

Returner den adresse i dataområde hvis adressedifferanse følger i to-bytesverdien i rekken umiddelbart etter dette symbol, og foreta en underrutineretur. Dette symbol blir benyttet til å identifisere en data-adressedifferanse ved å kalle opp en prosedyre som tilsvarer den, hvilket muliggjør opprettelse av posisjonsuavhengige datatabeller . Return the address in data area whose address difference follows in the two-byte value in the row immediately after this symbol, and make a subroutine return. This symbol is used to identify a data-address difference by calling a procedure corresponding to it, which enables the creation of position-independent data tables.

A5 DOCLASSA5 DOCLASS

( — a-addr )( — a-addr )

Forgren til kodeområdeadressen, hvis adressedifferanse finnes i den følgende celle i rekken, etter å ha skjøvet inn på stakken den adresse som er resultatet av å legge den ikke-fortegnsbestemte adressedifferanse som følger i de neste to byte i rekken (dvs. etter kodeforskyvningen), til grunnadressen for initialisert dataområde. Dette symbol benyttes til å identifisere en datastruktur i programminne og til å overføre styring til den rutine som behandler den, hvorved grunnlaget gis for en enkel klassemekanisme. Branch to the code area address, whose address difference is found in the following cell in the row, after pushing onto the stack the address resulting from adding the unsigned address difference that follows in the next two bytes in the row (ie, after the code shift), to the base address of initialized data area. This symbol is used to identify a data structure in program memory and to transfer control to the routine that processes it, thereby providing the basis for a simple class mechanism.

A6 ECALLA6 ECALL

( ) ( )

Etterfulgt av en celle i rekken, kaller opp prosedyren som benytter denne celle som en fortegnsbestemt byte-adressedifferanse inn til kodeområde. Followed by a cell in the row, calls the procedure that uses that cell as a signed byte address difference into the code area.

A7 SCALLA7 SCALL

( ) ( )

Etterfulgt av en byte i rekken, kaller opp den prosedyre som benytter denne byte som en fortegnsbestemt byte-adressedifferanse inn til kodeområde. Followed by a byte in the row, calls the procedure that uses this byte as a signed byte address difference into code area.

A8 CALLA8 CALL

( ) ( )

Etterfulgt av en to-bytes adressedifferanse i rekken, kaller opp prosedyren som benytter denne verdi som fortegnsbestemt byte-adressedif f eranse inn til kodeområde. Followed by a two-byte address difference in the row, calls the procedure that uses this value as the signed byte address difference into the code area.

AB SMAKE FRAMEAB TASTE FRAME

( Xparams • • • Xj )( Xparams • • • Xj )

Etterfulgt av to ikke-fortegnsbestemte én-bytes litteraler som inneholder første params, hvor antallet celler danner prosedyre-parametrene, og deretter temps, antallet celler med midlertidige variabler. Tildeler params+ temps+ 2 celler og setter deretter den aktuelle rammepeker til å peke på den nye ramme. Dette symbol lar PRFETCH og FRSTORE få tilgang til prosedyreparametere og midlertidige variabler. Followed by two unsigned one-byte literals containing first params, where the number of cells form the procedure parameters, and then temps, the number of cells with temporary variables. Assigns params+ temps+ 2 cells and then sets the current frame pointer to point to the new frame. This symbol allows PRFETCH and FRSTORE to access procedure parameters and temporary variables.

Den virtuelle maskin tillates å bygge rammer på returstakken, slik at bruk av rammer be-grenses av reglene som gjelder for bruk av returstakk generelt. Prosedyreparametere vil bli flyttet fra datastakken og inn i rammen av SMAKEFRAME, slik FRFETCH og FRSTORE kan få tilgang til dem. The virtual machine is allowed to build frames on the return stack, so that the use of frames is limited by the rules that apply to the use of return stacks in general. Procedure parameters will be moved from the data stack into the frame of SMAKEFRAME, so FRFETCH and FRSTORE can access them.

Dersom det ikke er mulig å bygge en ramme av den ønskede størrelse, vil det bli fremsatt en FRAME_STACK_ERROR (rammestakkefeil). If it is not possible to build a frame of the desired size, a FRAME_STACK_ERROR will be issued.

AC MAKEFRAMEAC MAKEFRAME

( Xpairams- • -X; ( Xpairams- • -X;

Etterfulgt av to ikke fortegnsbestemte to-bytes litteraler som inneholder første params, antallet celler som danner prosedyre-parametrene, og deretter temps, antallet celler med midlertidige variabler. Se Followed by two unsigned two-byte literals containing first params, the number of cells that form the procedure parameters, and then temps, the number of cells with temporary variables. See

SMAKEFRAME for ytterligere detaljer.TASTEFRAME for further details.

AD RELFRAMEAD RAIL FRAME

(<->) (<->)

Tilbakefør rammepekeren til dens tidligere verdi og frigjør den aktuelle ramme. Return the frame pointer to its previous value and free the frame in question.

1.5.2 Grensett1.5.2 Limit set

Disse symboler innbefatter de vanlige stakkmaskin-grenoperatører pluss kjøretidene for Forth-ordene DO ?D0 LOOP +LOOP LEAVE I og J. These symbols include the usual stack machine branch operators plus the runtimes for the Forth words DO ?D0 LOOP +LOOP LEAVE I and J.

AF EBRAOF EBRA

(<->) (<->)

Forgren hver gang. Fire-bytes adressedifferanse i rekken. Branch every time. Four-byte address difference in the row.

BO EBZBO EBZ

( num — )(num — )

Forgren hvis num = 0. Fire-bytes adressedifferanse i rekken. Branch if num = 0. Four-byte address difference in the row.

Bl EBNZBl EBNZ

( num — )(num — )

Forgren hvis num 0. Fire-bytes adressedifferanse i rekken. Branch if num 0. Four-byte address difference in the row.

B2 SBRAB2 SBRA

(<->) (<->)

Kort forgrening. Fortegnsbestemt byte-adressedif f eranse . Short branching. Signed byte address difference.

B3 SBZB3 SBZ

(num —)(num —)

Kort forgrening hvis num = 0. Fortegnsbestemt byte-adressedifferanse. Short branch if num = 0. Signed byte address difference.

B4 SBNZB4 SBNZ

( num — )(num — )

Kort forgrening hvis num * 0. Fortegnsbestemt byte-adressedifferanse. Short branch if num * 0. Signed byte address difference.

B5 BRAB5 GOOD

(<->) (<->)

Ubetinget forgrening. Fortegnsbestemt toby-tes adressedifferanse. Unconditional branching. Signed two-byte address difference.

B7 BNZB7 BNZ

( num — )(num — )

Forgren hvis num * 0. Fortegnsbestemt toby-tes adressedifferanse. Branch if num * 0. Signed two-byte address difference.

1.5.3 Datatype- og kodesideoverstyringer1.5.3 Data type and code page overrides

Denne gruppe gjør det mulig å overvinne begrensninge-ne ved 8-biters symboler. Vær oppmerksom på at deres stakkehandling avhenger av det etterfølgende symbol. Symbolparet kalles et sekundært symbol. Utvidelsessymbolene for datatyper legger beslag på symbolene CO til CF. Ubenyttede symboler i denne rekken er reservert for fremtidig bruk når det kreves ytterligere datatypeprefikser. This group makes it possible to overcome the limitations of 8-bit symbols. Note that their stack action depends on the subsequent symbol. The symbol pair is called a secondary symbol. The extension symbols for data types attach to the symbols CO to CF. Unused symbols in this row are reserved for future use when additional data type prefixes are required.

Cl SBYTECl SBYTE

( ) ( )

Fortegnsbestemt byte.Signed byte.

C2 UBYTEC2 UNBYTE

r - r -

Ikke-fortegnsbestemt byte.Unsigned byte.

C5 SLONGC5 HUNG

( ) ( )

Lang fortegnsbestemt, 32 biter.Long signed, 32 bits.

C6 ULONGC6 ULONG

( ) ( )

Lang ikke-fortegnsbestemt, 32 biter. Long unsigned, 32 bits.

1.5.4 Kontakthåndteringssyrnboler1.5.4 Contact handling syrnbols

D2 DOSOCKETD2 DOSOCKET

( (

Etterfulgt av en byte (0..63) i rekken, hvilken angir det nødvendige funksjonsnummer. Stakkeeffekten bestemmes av funksjonen knyttet til kontakten. Followed by a byte (0..63) in the row, which indicates the required function number. The stack effect is determined by the function associated with the contact.

D3 IDOSOCKETD3 IDOSOCKET

( u - )( u - )

Utfører den kontaktfunksjon hvis kontaktnummer (0..63) er angitt ved u. Stakkeeffekten på nedre nivå blir angitt gjennom den funksjon som er knyttet til kontakten. ANS Forth unntakssituasjon 24 (ugyldig numerisk påstand) vil bli fremsatt dersom u er større enn 63. Performs the contact function whose contact number (0..63) is indicated by u. The stack effect at the lower level is indicated through the function associated with the contact. ANS Forth exception situation 24 (invalid numeric assertion) will be raised if u is greater than 63.

1.5.5 Kontrollsett1.5.5 Control set

E6 IMCALLE6 IMCALL

(<->(<->

Utfør funksjonen fra modulen, hvis modulnum-mer (0-255) er gitt i den neste byte i rekken, og hvis funksjonsnummer (0-255) er gitt i den påfølgende byte i rekken. Stakkeeffek-ter avhenger av den påkalte funksjon. Execute the function from the module, whose module number (0-255) is given in the next byte in the row, and whose function number (0-255) is given in the following byte in the row. Stack effects depend on the called function.

E7 CLASSPROCE7 CLASSPROC

( ) ( )

Under innlasting markerer CLASSPROC inngan-gen til klassehåndteringskode. Benyttes til kompileringsbistand og kan implementeres som en NOOP. During loading, CLASSPROC marks the entry for class handling code. Used for compilation assistance and can be implemented as a NOOP.

F9 SYSFUNCF9 SYS FUNC

( ) ( )

Et sideutvidelsestegn behandlet som den før-ste byte i et sekundært symbol. Kaller opp A page extension character treated as the first byte of a secondary symbol. Calling up

ken. Det støttede sekundær-symbolsett er åken. The supported secondary symbol set is to

finne i avsnitt 1.7. Stakkeeffekten bestem-find in section 1.7. The stack effect determines

mes gjennom den angitte rutine.mes through the specified routine.

1.6 Kontakter1.6 Contacts

De første åtte sekundære kontaktsymboler er reservert for kontakthåndteringsfunksjoner, og definerte håndteringsfunk-sjoner er beskrevet nedenfor. Gjenstående kontakter (D2 08 til D2 3F) er til bruksformål. The first eight secondary contact symbols are reserved for contact handling functions, and defined handling functions are described below. Remaining contacts (D2 08 to D2 3F) are for utility purposes.

F9 91 SETSOCKETF9 91 SET SOCKET

( xp u - flag )(xp u-flag)

Sett utførelsespekeren xp til å være den som behandler kontaktfunksjon u, hvilket fører til at xp utføres ved en påfølgende utførel- Set the execution pointer xp to be the one processing contact function u, causing xp to be executed on a subsequent execution

se av DOSOCKET <u>. Før utførelsespekeren settes, kjøres prosedyren som er installert gjennom SETPLUGCONTROL, for å fastslå om kontakten kan plugges med denne nye xp. flag er verdien som returneres av denne prosedy- see of DOSOCKET <u>. Before setting the execution pointer, the procedure installed through SETPLUGCONTROL is run to determine if the socket can be plugged with this new xp. flag is the value returned by this procedure-

re. SETSOCKET vil bare sette pekeren dersom flag er FALSE (ukorrekt) , ellers forkastes pekeren. Unntakssituasjon -24 (ugyldig numerisk påstand) vil bli fremsatt dersom u er større enn 63. re. SETSOCKET will only set the pointer if flag is FALSE (incorrect), otherwise the pointer is discarded. Exception -24 (invalid numeric assertion) will be raised if u is greater than 63.

D2 00 SETPLUGCONTROLD2 00 SET PLUG CONTROL

( xp - )( xp - )

Lagrer utførelsespekeren xp for en bruker-skrevet prosedyre som vil bli kjørt av SETSOCKET for å fastslå om kontakten kan plugges. Stores the execution pointer xp for a user-written procedure that will be run by SETSOCKET to determine whether the socket is pluggable.

Handlingen i denne prosedyre (som her kalles PLUGCONTROL for illustrasjonsformål) må væ- The action in this procedure (which is here called PLUGCONTROL for illustration purposes) must be

re : re :

( u - flag )(u-flag)

hvor u er kontaktnummeret og flag returneres FALSE (ukorrekt) hvis kontakten kan plugges, eller TRUE (korrekt) hvis den ikke kan. I tillegg må PLUGCONTROL-prosedyren fremsette en unntakssituasjon -24 (ugyldig numerisk påstand) for verdier av u som er utenfor området 0-63. where u is the contact number and flag returns FALSE (incorrect) if the contact can be plugged, or TRUE (correct) if it cannot. In addition, the PLUGCONTROL procedure must raise an exception -24 (invalid numeric assertion) for values of u outside the range 0-63.

En standardhandling for PLUGCONTROL er installert gjennom den Virtuelle Maskin for å returnere FALSE for alle verdier av u, hvorved alle kontakter tillates plugget. A default action for PLUGCONTROL is installed through the Virtual Machine to return FALSE for all values of u, allowing all contacts to be plugged.

D2 03 OSCALLBACKD2 03 OSCALLBACK

( dev fn numinum2ior )( dev fn numinum2ior )

Kaller opp en operativsystemrutine med parametrene: dev velger den ønskede inn/ut-enhet for funksjon fn med num;32 biters parametere inneholdt i en rekke num?, hvilket returnerer ior som er implementeringsavhengig. Legg merke til at num?er øverst i stakken, num;og num? tilsvarer henholdsvis arve og argv i C-bruk. Calls an operating system routine with the parameters: dev selects the desired I/O device for function fn with num; 32-bit parameters contained in an array num?, which returns ior which is implementation dependent. Notice that num? is at the top of the stack, num; and num? correspond respectively to arve and argv in C usage.

Legg merke til at denne kontakt er implementeringsavhengig og er tilveiebrakt slik at terminalspesifikke programmer (TRS) som er skrevet ved bruk av EPICode, kan ha terminalavhengig inn/ut. Dersom den angitte funksjon ikke er støttet, fremsette unntakssituasjon -21 (ikke-støttet operasjon). Note that this connector is implementation-dependent and is provided so that terminal-specific programs (TRS) written using EPICode can have terminal-dependent I/O. If the specified function is not supported, issue exception situation -21 (unsupported operation).

D2 04 EPICALLBACKD2 04 EPICALLBACK

( dev fn num;num2ior )( dev fn num;num2ior )

En kontakt for en EPICode-rutine som kan kalles opp av det underliggende operativsystem. De fire parametere er 32-biters verdier ment til å brukes som følger: dev velger den ønskede inn/ut-enhet for funksjon fn med numi32-biters parametere inneholdt i rekken num2, hvilket returnerer ior hvis betydning er implementeringsavhengig. num; og num2tilsvarer henholdsvis arve og argv i C-bruk. A connector for an EPICode routine that can be called by the underlying operating system. The four parameters are 32-bit values intended to be used as follows: dev selects the desired I/O device for function fn with numi32-bit parameters contained in the array num2, which returns ior whose meaning is implementation-dependent. num; and num2 correspond respectively to arve and argv in C usage.

Legg merke til at denne kontakt er implementeringsavhengig og er tilveiebrakt slik at terminalspesifikke programmer (TRS) skrevet ved bruk av EPICode, kan tilveiebringe til-bakekallingsrutiner for operativsystemet. Dersom den spesifikke funksjon ikke støttes, blir unntakssituasjon -21 (ikke-støttet operasjon) fremsatt. Note that this contact is implementation-dependent and is provided so that terminal-specific programs (TRS) written using EPICode can provide callback routines for the operating system. If the specific function is not supported, exception situation -21 (unsupported operation) is raised.

1.7 SYSFUNC inn/ut-sett1.7 SYSFUNC in/out set

Dette sett definerer funksjonene som er tilgjengelige via SYSFUNC-symbolet, hvilket virker som et grensesnitt som er gjort generelt for underliggende operativsystemrutiner. This set defines the functions accessible via the SYSFUNC symbol, acting as a generalized interface to underlying operating system routines.

1.7.1 Enhetstilgang1.7.1 Device Access

Hver enhet er tilordnet et eget enhetsnummer. Status ior-koder er enhetsavhengige, bortsett fra at en ior-kode 0 alltid indikerer vellykket. Each unit is assigned a separate unit number. Status ior codes are device dependent, except that an ior code 0 always indicates successful.

F9 00 DKEYF9 00 DKEY

( dev — echar )( dev — echar )

Les et tegn fra innenhet dev.Read a sign from within dev.

F9 01 DKEYTESTF9 01 DKEY TEST

( dev - flag )(dev-flags)

Returner TRUE hvis et tegn er klar til å le-Return TRUE if a character is ready to read-

ses fra innenhet dev.seen from within unit dev.

F9 02 DEMITF9 02 DEMIT

( char dev )( char dev )

Overfør char til utenhet dev.Transfer char to entity dev.

F9 03 BEEPF9 03 BEEP

( u dev - )( u dev - )

Be utenheten dev om å generere en lyd med va-righet på u millisekunder. Denne funksjon kan oppholde behandlingen over den angitte varig-het. Ask the external device dev to generate a sound with a duration of u milliseconds. This function can delay processing for the specified duration.

F9 04 DREADF9 04 DREAD

( addr len dev - ior )( addr len dev - ior )

Les en streng fra innenhet dev, idet en enhetsavhengig ior returneres. Den returnerte streng inneholder bare den minst signifikante byte med tegn lest fra en tastaturenhet. Read a string from within unit dev, returning a unit-dependent ior. The returned string contains only the least significant byte of characters read from a keyboard device.

F9 05 DWRITEF9 05 DWRITE

( addr len dev — ior )( addr len dev — ior )

Skriv en streng til utenhet dev, hvorved det returneres en enhetsavhengig ior. Write a string to non-unit dev, which returns a unit-dependent ior.

F9 0 6 DSTATUSF9 0 6 DSTATUS

( dev - ior )( dev - ior )

Returner status-ior for kilden tilknyttet enhet dev, hvor vanligvis "ready" (klar) og "serviceable" (kan betjenes) angis med 0, og "not ready" (ikke klar) angis med hvilken som helst annen verdi. En spesifikk enhet kan returnere ikke-null-verdier som har betydning for den enhet. Dersom enheten er blitt valgt ved en tidligere utførelse av OUTPUT-symbolet, skal DSTATUS returnere "not ready" inntil utførelsen av funksjonen overført til OUTPUT fullføres. Return the status-ior of the source associated with device dev, where typically "ready" and "serviceable" are set to 0, and "not ready" is set to any other value. A specific entity can return non-zero values that are meaningful to that entity. If the device has been selected by a previous execution of the OUTPUT symbol, DSTATUS shall return "not ready" until the execution of the function transferred to OUTPUT is completed.

F9 07 DIOCTLF9 07 DIOCTL

( dev fn num a-addr - ior )( dev fn num a-addr - ior )

Gjennomfør IOCTL-funksjon fn for kanal dev med num påstander av cellestørrelse i rekken ved a- addr. Execute IOCTL function fn for channel dev with num assertions of cell size in row at a- addr.

F9 08 OUTPUTF9 08 OUTPUT

( xp dev - ior )( xp dev - ior )

Utfør prosedyren hvis utførelsespeker er gitt ved xp idet resultatet blir styrt til enhet dev. Ved retur fra OUTPUT er den aktuelle utenhet (se GETOP) upåvirket, ior returneres som null dersom prosedyren lar seg utføre. Alle unntakssituasjoner som oppstår ved utfø-relsen av xp, fanges opp av den virtuelle maskin og fører til øyeblikkelig avslutning av Execute the procedure whose execution pointer is given by xp with the result being directed to unit dev. When returning from OUTPUT, the external unit in question (see GETOP) is unaffected, ior is returned as zero if the procedure can be executed. All exception situations that occur during the execution of xp are caught by the virtual machine and lead to immediate termination of

OUTPUT.OUTPUT.

F9 09 DWRITESTRINGF9 09 DWRITE TESTING

( dev - )( dev - )

Dette symbol følges av en streng av tegn, lagret i symbolstrømmen som en tellebyte etterfulgt av så mange byte. DWRITESTRING-symbolet skriver tegnene til den valgte enhet dev. Utførelse fortsetter umiddelbart etter siste tegn. This symbol is followed by a string of characters, stored in the symbol stream as a count byte followed by that many bytes. The DWRITESTRING symbol writes the characters to the selected device dev. Execution continues immediately after the last character.

F9 OA GETOPF9 OA GETOP

( - dev )(-dev)

Returnerer den enhet dev som ble valgt sist ved SETOP eller under utførelse av en funksjon overført til OUTPUT. Benyttes til å finne standardenhet for enhetsorienterte inn/ut-operasjoner. Denne funksjon tillater funksjoner avhengig av en aktuell enhet å implementeres på en lett måte. Returns the device dev that was last selected at SETOP or during execution of a function passed to OUTPUT. Used to find the default unit for unit-oriented I/O operations. This feature allows functions depending on a current device to be easily implemented.

F09 OB SETOPF09 OB SETUP

{ dev - ){ dev - )

Benyttes til å sette standardenhet dev returnert av GETOP for enhetsorienterte inn/ut-operasjoner. Denne funksjon tillater funksjoner avhengig av en aktuell enhet å implementeres på en lett måte. Used to set the default device dev returned by GETOP for device-oriented I/O operations. This feature allows functions depending on a current device to be easily implemented.

F9 OC FORMFESDF9 OC FORM FESD

( dev - )( dev - )

Utfører en enhetsavhengig "nytt ark"-handling slik som "slett skjermbilde" (terminaldis-play) eller "ny side" (skriver) på enhet dev. Performs a device-dependent "new sheet" action such as "clear screen" (terminal dis-play) or "new page" (printer) on device dev.

F9 OD CRF9 OD CR

( dev - )( dev - )

Utfører en enhetsavhengig "ny linje"-handling på enhet dev. Performs a device-dependent "newline" action on device dev.

F9 OE SETXYF9 OE SETXY

( numinum2dev )(numinum2dev)

Utfører en enhetsavhengig "sett absoluttposi-sjon"-handling på enhet dev ved å benytte num!som x-ordinaten og num2som y-ordinaten. Performs a unit-dependent "set absolute position" operation on unit dev using num! as the x-ordinate and num2 as the y-ordinate.

1.7.2 Tidshåndtering1.7.2 Time management

Standard Forth-ord.Standard Forth words.

1.7.3 Språk- og meldingshåndtering Symboler i denne gruppe tilveiebringer en mekanisme til håndtering av språk og meldingsutvalg og display. 1.7.3 Language and message handling Symbols in this group provide a mechanism for handling language and message selection and display.

F9 20 CHOOSELANGF9 20 CHOSELONG

( addr — flag )( addr — flag )

Velg det språk hvis ISO 639 språkkode er gitt gjennom de to tegn i addr. Dersom flag er TRUE, ble språket funnet og er nå det gjel dende språk. Ellers skal oppkallingsprogram-met velge et annet språk. I det minste ett språk (terminalens morsmål) vil alltid være tilgjengelig. Select the language if the ISO 639 language code is given through the two characters in addr. If flag is TRUE, the language was found and is now the current language. Otherwise, the calling program must select another language. At least one language (the terminal's native language) will always be available.

F9 21 CODEPAGEF9 21 CODE PAGE

( num — flag )( num — flag )

Forsøk på å velge det residente kodesidenum. Kodesider er nummerert i henhold til ISO 8859 (0 = vanlig tegnsett, 1 er Latin 1, osv.). flag er TRUE hvis kodesiden er blitt valgt. Attempt to select the resident code page number. Code pages are numbered according to ISO 8859 (0 = regular character set, 1 is Latin 1, etc.). flag is TRUE if the code page has been selected.

F9 22 LOADPAGEF9 22 LOAD PAGE

( addr — flag )( addr — flag )

Installer kodeside i addr i terminalen (denne side vil vanligvis finnes i kortet). Flag angir vellykket opplasting av siden. Sidein-stallering kan gjøres når ny meldingstabell er blitt lastet inn fra ICC-et som krever en kodeside som ikke er tilgjengelig i terminalen . Install code page in addr in the terminal (this page will usually be found in the card). Flag indicates successful page upload. Page installation can be done when a new message table has been loaded from the ICC that requires a code page that is not available in the terminal.

F9 23 INITMESSAGESF9 23 INIT MESSAGES

Denne funksjon sletter fortrolige utsteder-meldinger, nummerert fra CO til FF (heks.) og eventuelle beskjeder installert av LOADMESSAGES. Denne funksjon skal kalles opp etter hver brukerøkt. This function deletes confidential issuer messages, numbered from CO to FF (hex.) and any messages installed by LOADMESSAGES. This function must be called after each user session.

F9 24 LOADMESSAGESF9 24 LOAD MESSAGES

( c-addr - )(c-addr - )

Installer en meldingstabell på et egnet sted i databasen for forbigående meldinger, c- addr angir stedet for meldingstabelldefinisjonen, innbefattet sidekode til bruk for meldinger, den tobokstavers språkkode i overensstemmelse med ISO 639, samt de meldinger som skal installeres . Install a message table in a suitable location in the database for transient messages, c-addr specifies the location of the message table definition, including page code to use for messages, the two-letter language code in accordance with ISO 639, and the messages to be installed.

F9 25 GETMESSAGEF9 25 GETMESSAGE

(num — c-addr len)(num — c-addr len)

Returnerer strengparametere for melding-num. Etterhengende mellomromstegn fjernes fra strengens lengde Jen. Returns string parameters for message-num. Trailing spaces are removed from the string's length Jen.

F9 27 UPDATEMESSAGESF9 27 UPDATE MESSAGES

( addr "len — )( addr "len — )

Installer en meldingstabell i de residente språktabeller. Hvis et språk med samme kode allerede finnes, vil det bli erstattet, ellers vil det nye språk bli tilføyd. Hvis det ikke er nok plass til det nye språk, vil en THROW (unntakssituasjon) bli utstedt med kode 22 (TOO_MANY_LANGUAGES) (for mange språk). addr angir stedet for TLV-en som inneholder meldingstabelldefinisjonen, innbefattet side-koden til bruk for meldinger, den tobokstavers språkkode i overensstemmelse med ISO 639, og beskjedene som skal installeres. Install a message table in the resident language tables. If a language with the same code already exists, it will be replaced, otherwise the new language will be added. If there is not enough space for the new language, a THROW (exception situation) will be issued with code 22 (TOO_MANY_LANGUAGES) (too many languages). addr specifies the location of the TLV containing the message table definition, including the page code to be used for messages, the two-letter language code conforming to ISO 639, and the messages to be installed.

F9 28 MESSAGESIZEF9 28 MESSAGESIZE

( - len )( - len )

Returnerer standard meldingslengde for denne terminal. Returns the default message length for this terminal.

F9 2 9 TYPEMESSAGEF9 2 9 TYPE MESSAGE

( addr len — )( addr len — )

Skjermviser den gitte streng i terminalens me1dings1inj e. Displays the given string in the terminal's message input.

1.7.4 Håndtering av ICC-kort1.7.4 Handling of ICC cards

Symboler i denne gruppen tilveiebringer en mekanisme til håndtering av lesere for kort med integrerte kretser (ICC). Symbols in this group provide a mechanism for handling integrated circuit card (ICC) readers.

F9 30 INITCARDF9 30 INIT CARD

( num — ior )( num — ior )

Velger ICC-leser-num, hvor num er 0 eller 1. Selects ICC reader num, where num is 0 or 1.

F9 31 CARDF9 31 CARD

( c-addrileni c-addr len2— c-addr2len3)( c-addrileni c-addr len2— c-addr2len3)

Send dataene i bufferen c- addri leni til kortet og motta data i c- addr2len2. Den returnerte len3gir den faktiske lengde på den mottatte streng. Send the data in the buffer c-addri leni to the card and receive data in c-addr2len2. The returned len3 gives the actual length of the received string.

Bufferen c- addri leni må inneholde:The c-addri leni buffer must contain:

Fire-bytes standard ISO-hode (Klasse, Instruksjon, Pl, P2) . Four-byte standard ISO header (Class, Instruction, Pl, P2) .

Valgfrie data ( lengde etterfulgt av lengdebyte, hvor lengde kan være 0-255). Optional data (length followed by length bytes, where length can be 0-255).

Bufferen c- addr2len2 må gi tilstrekkelig plass til svaret fra kortet pluss to statusbyte som inneholder SW1 og SW2. Feilhåndteringer blir gjort internt i CARD. The buffer c-addr2len2 must provide sufficient space for the response from the board plus two status bytes containing SW1 and SW2. Error handling is done internally in CARD.

F9 32 CARDONF9 32 CARDON

( c-addr leni — c-addr len2ior )( c-addr leni — c-addr len2ior )

Påfør strøm på ICC og utfør kort-tilbakestillingsfunksjonen. c- addr leni tilveiebringer en buffer hvor Answer to Reset (svar på tilbakestilling) vil bli plassert; len2er faktisk lengde på den returnerte streng. Apply power to the ICC and perform the card reset function. c- addr leni provides a buffer where Answer to Reset will be placed; len2 is the actual length of the returned string.

F9 33 CARDOFFF9 33 CARDOFF

(<->) (<->)

Slå av strømmen på ICC. Dette utføres når al-le transaksjoner er fullført. Turn off the power on the ICC. This is performed when all transactions have been completed.

F9 34 CARDABSENTF9 34 CARDABSENT

( - flag )( - flag )

Returner TRUE hvis det ikke er et ICC-kort i leseren, ellers returneres FALSE. Return TRUE if there is no ICC card in the reader, otherwise return FALSE.

1.7.5 Magnetstripehåndtering Symboler i denne gruppe tilveiebringer en mekanisme til håndtering av magnestripeenheter. 1.7.5 Magnetic stripe handling Symbols in this group provide a mechanism for handling magnetic stripe devices.

F9 38 FROMMAGF9 38 FROMMAG

( c-addr leni num — c-addr len2ior )( c-addr leni num — c-addr len2ior )

Les én eller flere ISO-magnetstriper. Operasjonen kan avbrytes ved brukers CANCEL-tast eller ved et tidsavbrudd. num er ISO-identifikatoren i den (de) magnetstripe(r) som skal leses, c- addr er strengens måladres-se, og len-, er dens maksimumslengde (minst 78 byte for IS01, 41 byte for IS02, og 108 for IS03, eller summer av disse for lesing av flere magnetstriper). Ved retur gir len? den leste strengs faktiske lengde. Read one or more ISO magnetic strips. The operation can be canceled by the user's CANCEL key or by a timeout. num is the ISO identifier of the magnetic strip(s) to be read, c- addr is the target address of the string, and len- is its maximum length (at least 78 bytes for IS01, 41 bytes for IS02, and 108 for IS03 , or sums of these for reading several magnetic strips). When returning, give the fiefdom? the actual length of the read string.

F9 39 TOMAGF9 39 TOMAG

( c-addr len num — ior )( c-addr len num — ior )

Skriv én ISO-magnetstripe. Dataene er i bufferen c- addr len og vil bli skrevet til stri-pe-num (1-3). Operasjon kan avbrytes ved brukers CANCEL-tast eller ved tidsavbrudd. Write one ISO magnetic stripe. The data is in the buffer c-addr len and will be written to strip-pe-num (1-3). Operation can be canceled by the user's CANCEL key or by a timeout.

1.7.6 Modemhåndtering1.7.6 Modem management

Symboler i denne gruppe tilveiebringer en mekanisme for håndtering av modemenheten. Symbols in this group provide a mechanism for handling the modem device.

F9 4 0 MODEMCALLF9 4 0 MODEMCALL

( numinum2num3num^num5C-addr len — ior )(numinum2num3num^num5C-addr len — ior )

Kaller opp et nummer som bruker et internt terminalmodem. Calls a number using an internal terminal modem.

numiog num? angir den inn- og ut-linjehastighet som skal benyttes (fra 75 til 19200 baud). De faktiske støttede hastigheter er implementeringsbestemt. numio and num? specifies the input and output line speed to be used (from 75 to 19200 baud). The actual supported speeds are implementation specific.

num3angir paritet (0 = ingen, 1 = ulik, 2 = lik) . num3 indicates parity (0 = none, 1 = odd, 2 = even) .

nvni4angir antall biter som skal benyttes (7 eller 8) . nvni4 specifies the number of bits to be used (7 or 8).

numsangir antall stoppbiter benyttet til overføring (1 eller 2 biter). c- addr len er en streng som inneholder tele-fonnummeret som skal ringes opp. ',' kan innbefattes for påvente av ringetone. Dersom det første tegn i denne streng er 'P', blir puls-oppringning benyttet i stedet for standard-toneoppringning. num indicates the number of stop bits used for transmission (1 or 2 bits). c-addr len is a string containing the telephone number to be called. ',' can be included for waiting for ringtone. If the first character in this string is 'P', pulse dialing is used instead of standard tone dialing.

F9 41 MODEMHANGUPF9 41 MODEM HANGUP

( - ior )( - ior )

Denne funksjon benyttes til å avslutte den pågående modemøkt. This function is used to end the current modem session.

F9 42 TOMODEMF9 42 TOMODEM

( c-addr len - ior )( c-addr len - ior )

Send strengen i c- addr len i en opprettet mo-demøkt . Send the string in c-addr in a created mod session.

F9 4 3 FROMMODEMF9 4 3 FROM MODEM

( c-addr leni - c-addr len2ior )( c-addr leni - c-addr len2ior )

Mottar en streng fra modemet, c- addr er mål adressen for strengen, og len; er dens maksi-male lengde. Ved retur angir len2den faktiske lengde på den leste streng. Dersom det ikke mottas noen tegn i løpet et spesifisert tidsrom, oppstår et tidsavbrudd. Receives a string from the modem, c- addr is the target address of the string, and len; is its maximum male length. On return, len2 indicates the actual length of the read string. If no characters are received during a specified period of time, a timeout occurs.

F9 4 4 MODEMBREAKF9 4 4 MODEM BREAK

( - ior )( - ior )

Denne funksjon sender et brudd i den oppkop-lede modemøkt. This function sends a break in the connected modem session.

1.7.7 Håndtering av svarteliste1.7.7 Handling of blacklists

Symboler i denne gruppe tilveiebringer en mekanisme for å håndtere svartelistefilen. Symbols in this group provide a mechanism for managing the blacklist file.

F9 48 INITBLACKLISTF9 48 INITBLACKLIST

r - r -

Denne funksjon initialiserer svartelisten til tom tilstand. This function initializes the blacklist to an empty state.

F9 49 BLACKLISTINSERTF9 49 BLACKLIST INSERTED

( c-addr len — flag )( c-addr len — flag )

Denne funksjon setter inn en oppføring i c-addr len i listen, hvilken opprettholdes i sortert orden. This function inserts an entry in c-addr len into the list, which is maintained in sorted order.

Denne funksjon må benyttes ved oppdatering av listen. This function must be used when updating the list.

Det returnerte flag er FALSE hvis oppføringen var vellykket (oppføringen ikke ble funnet i den eksisterende liste, og listen ikke var full). The returned flag is FALSE if the entry was successful (the entry was not found in the existing list and the list was not full).

F9 4A INBLACKLISTF9 4A INBLACKLIST

( c-addrileni- c-addr2len2flag )(c-addrileni-c-addr2len2flag)

Denne funksjon forsøker å finne en nøkkel c-addrilensi listen. c- addr2len2 inneholder resultatet av søket (innbefattet gjenværende byte fra den valgte oppføring og muligens noen andre informa-sjonsbyte), dersom nøkkelen ble funnet. This function tries to find a key c-addrilensi list. c-addr2len2 contains the result of the search (including remaining bytes from the selected entry and possibly some other information bytes), if the key was found.

Det returnerte flag er FALSE hvis nummeretThe returned flag is FALSE if the number

ble funnet.was found.

F9 4B BLACKLISTDELETEF9 4B BLACKLIST DELETE

( c-addr len — flag )( c-addr len — flag )

Denne funksjon sletter en oppføring i listenThis function deletes an entry in the list

hvor c- addr len er nøkkelen til den oppføring som skal slettes. Den kan være opptil 18 byte lang. where c-addr len is the key to the entry to be deleted. It can be up to 18 bytes long.

Det returnerte flag er FALSE hvis slettingenThe returned flag is FALSE if the deletion

var vellykket (oppføringen ble funnet).was successful (entry found).

1.7.8 Støtte for sikkerhetsalgoritmer1.7.8 Security Algorithm Support

Symboler i denne gruppen gir støtte til initialisering og bruk av sikkerhetstjenester. Symbols in this group provide support for the initialization and use of security services.

F9 50 INITSECALGOF9 50 INITSCALGO

( c-addr len num - flag )( c-addr len num - flag )

c- addr er adressen til initialiseringsbuffer,c-addr is the address of initialization buffer,

og len er dens lengde. Inn-parameteren (-parametrene) for hver algoritme kan varie- and len is its length. The input parameter(s) for each algorithm can vary

re, men en nøkkel skal vanligvis overføres til denne initialisering. flag er FALSE hvis initialisering var vellykket. re, but a key should usually be passed to this initialization. flag is FALSE if initialization was successful.

F9 51 SECALGOF9 51 SECALGO

( c-addrilen c-addr2num — flag )( c-addrilen c-addr2num — flag )

Hvor c- addr! er inndatabufferen som skal behandles, og len er dens lengde. c- addr2 er utbufferen til lagring av resultatet. Where c-addr! is the input buffer to be processed and len is its length. c- addr2 is the output buffer for storing the result.

flag er FALSE hvis behandling foregikk vellykket. flag is FALSE if processing was successful.

1.7.9 Terminal tjenester1.7.9 Terminal services

F9 58 POWERLESSF9 58 POWERLESS

( - flag )( - flag )

Returnerer FALSE hvis det er nok strøm til å fullføre den pågående transaksjon. Returns FALSE if there is enough power to complete the current transaction.

1.7.10 Databasetjenester1.7.10 Database Services

Nedenstående symboler tilveiebringer en mekanisme til håndtering av databaser. The symbols below provide a mechanism for managing databases.

F9 61 DBMAKECURRENTF9 61 DBMAKECURRENT

( a- addr — )(a- addr — )

Lag databasen hvis DPB er i a- addr i den aktuelle database. Create the database if DPB is in a-addr in the relevant database.

F9 62 DBSIZEF9 62 DBSIZE

( - len )( - len )

Returnerer størrelsen på postbufferen som tilveiebringer vinduet inn til den aktuelle post i den aktuelle database. Returns the size of the record buffer that provides the window into the current record in the current database.

F9 63 DBFETCHCELLF9 63 DBFETCHCELL

( num, — num?)( num, — num?)

Returnerer 32-biters verdien num?fra cellen i den celleinnrettede byte-adressedifferanse numii den aktuelle post i den aktuelle database . Returns the 32-bit value num?from the cell in the cell-aligned byte address difference numii of the current record in the current database.

F9 64 DBFETCHBYTEF9 64 DBFETCHBYTE

( num — char )( num — char )

Returnerer én-bytesverdien char fra byte-adressedif f eransen num i den aktuelle post i den aktuelle database. Returns the one-byte value char from the byte address difference num in the current record in the current database.

F9 65 DBFETCHSTRINGF9 65 DBFETCHSTRING

( num len — addr len)(num len — addr len)

Returnerer strengparametrene addr og len i bytesekvensen i adressedifferanse num og med lengde len i den aktuelle post i den aktuelle database. Returns the string parameters addr and len in the byte sequence in address difference num and with length len in the relevant record in the relevant database.

F9 66 DBSTORECELLF9 66 DBSTORECELL

( numinum?— )( numinum?? )

Lagrer 32-bit-verdien numii cellen i den celleinnrettede adressedifferanse num?i den aktuelle post i den aktuelle database og oppdaterer databaseposten. Stores the 32-bit value numii the cell in the cell-aligned address difference num?i in the current record in the current database and updates the database record.

F9 67 DBSTOREBYTEF9 67 DBSTORE BYTE

( char num - )( char num - )

Lagrer 1-byte-verdien char! inntil byten i adressedifferanse num i den aktuelle post i den aktuelle database og oppdaterer databaseposten . Stores the 1-byte value char! until the byte in address difference num in the relevant record in the relevant database and updates the database record.

F9 68 DBSTORESTRINGF9 68 DBSTORE STRING

( addr leni num len2— )( addr leni num len2— )

Lagrer høyst len^-byte av bytesekvensen iStores at most len^ bytes of the byte sequence i

addr inntil adressedifferanse-num i den aktu-addr until address difference-num in the current

elle post i den aktuelle database og oppdate-elle record in the relevant database and update

rer databaseposten. Hvis leni er mindre enn len2lblir målet i databasepostbufferen fylt med mellomromstegn til len2. rer database record. If leni is less than len2l, the target in the database record buffer is padded with spaces to len2.

F9 69 DBINITIALIZEF9 69 DBINITIALIZE

(<->) (<->)

Initialiserer den aktuelle database til bare nuller og setter "aktuelle" og "tilgjengelige" postnummer i databasen (se DBRECNUM og DBAVAIL) til 0. Initializes the current database to zeros only and sets "current" and "available" postcodes in the database (see DBRECNUM and DBAVAIL) to 0.

F 9 6A DBRECNUMF 9 6A DBRECNUM

( - U )( - U )

Returnerer det aktuelle postnummer.Returns the current postal code.

F9 6B DBCAPACITYF9 6B DBCAPACITY

( - u )( - u )

Returnerer det totale antall poster som den aktuelle database kan inneholde. Returns the total number of records that the current database can contain.

F9 6C DBAVAILF9 6C DBAVAIL

( - num )( - num )

Returnerer postnummeret for den neste tilgjengelige post i den aktuelle fil. Returns the postal code of the next available record in the current file.

F9 6D DBADDRECF9 6D DBADDREC

(<->) (<->)

Legg en post i slutten av den aktuelle database til postnummeret gitt av DBAVAIL. Add a record at the end of the relevant database to the zip code given by DBAVAIL.

F9 6F DBSELECTF9 6F DBSELECT

( num — )(num — )

Velg post-num i den for øyeblikket valgte database.Select post-num in the currently selected database.

F9 7 0 DBMATCHBYKEYF9 7 0 DBMATCHBYKEY

( addr len — flag )( addr len — flag )

Søk i den aktuelle database etter en make i nøkkelfeltet til strengen angitt ved addr og len. Len kan være kortere enn den definerte lengde for nøkkelfeltet for denne struktur, idet de gjenværende tegn blir sammenlignet med blanke (ASCII 20h) tegn. Hvis makesøket er vellykket, blir makeposten gjeldende og flag er FALSE. Search the relevant database for a match in the key field of the string specified by addr and len. Len can be shorter than the defined length for the key field for this structure, as the remaining characters are compared to blank (ASCII 20h) characters. If the make search is successful, the make record becomes valid and flag is FALSE.

Dette symbol kan bare brukes med en Ordered (bestilt) database . This symbol can only be used with an Ordered database.

F9 71 DBADDBYKEYF9 71 DBADDBYKEY

( addr len — flag )( addr len — flag )

Søk i den aktuelle database etter en make i nøkkelfeltet til strengen angitt ved addr og len. Len kan være kortere enn den definerte lengde for nøkkelfeltet for denne struktur, idet de gjenværende tegn blir sammenlignet med blanke (ASCII 20h) tegn. Hvis makesøket er vellykket, blir makeposten gjeldende og flag er TRUE. Hvis makesøket ikke er vellykket, blir en ny post satt inn i den korrekte posisjon i databasen, og flag er FALSE. Denne nye post vil bli initialisert, bortsett fra dens nøkkelfelt som vil inneholde den gitte nøkkel. Search the relevant database for a match in the key field of the string specified by addr and len. Len can be shorter than the defined length for the key field for this structure, as the remaining characters are compared to blank (ASCII 20h) characters. If the make search is successful, the make record becomes valid and flag is TRUE. If the mate search is not successful, a new record is inserted in the correct position in the database, and flag is FALSE. This new record will be initialized, except for its key field which will contain the given key.

Dette symbol kan bare benyttes med en Ordered (bestilt) database . This symbol can only be used with an Ordered database.

F9 72 DBDELBYKEYF9 72 DBDELBYKEY

( addr len — flag )( addr len — flag )

Søk i den aktuelle databasse etter en make i nøkkelfeltet til strengen angitt ved addr og len. Len kan være kortere enn den angitte lengde for nøkkelfeltet for denne struktur, idet de gjenstående tegn blir sammenlignet med blanke (ASCII 20h) tegn. Hvis makesøket er vellykket, blir make-posten slettet og flag er FALSE. Slettehandlingen lukker igjen ethvert potensielt "hull" i en fysisk implementering ved å ta de nød-vendige skritt for fysisk å omplassere eller på ny lenke postene i en forhåndsinitialisert database. Dette symbol kan bare benyttes med en bestilt database. Search the relevant database for a match in the key field of the string specified by addr and len. Len may be shorter than the specified length for the key field for this structure, as the remaining characters are compared to blank (ASCII 20h) characters. If the make search is successful, the make record is deleted and flag is FALSE. The delete action closes any potential "hole" in a physical implementation by taking the necessary steps to physically relocate or relink the records in a pre-initialized database. This symbol can only be used with an ordered database.

F9 73 DBSAVECONTEXTF9 73 DBSAVECONTEXT

(<->) (<->)

Bevirker at tjeneren stakker den aktuelle sammenhengsinformasjon, innbefattet den aktuelle database, det aktuelle postnummer og eventuell nødvendig støtteinformasjon. Tjeneren er berettiget til å benytte den virtuelle datamaskins returstakk for lagring av sammenhengsinformasjon, og kundeprogramvare må derfor overholde de generelle regler som gjelder for bruk av returstakk. Causes the server to stack the relevant context information, including the relevant database, the relevant postcode and any necessary supporting information. The server is entitled to use the virtual computer's return stack for storing context information, and customer software must therefore comply with the general rules that apply to the use of return stacks.

F9 7 4 DBRESTORECONTEXTF9 7 4 DBRESTORECONTEXT

( ) ( )

Bevirker at tjeneren gjenoppretter den sist lagrede sammenhengsinformasjon (se DBSAVECONTEXT). Tjeneren er berettiget til å bruke den virtuelle datamaskins returstakk for å lagre sammenhengsinformasjon, og kundeprogramvare må derfor overholde de generelle regler som gjelder for bruk av returstakk. Causes the server to restore the last saved context information (see DBSAVECONTEXT). The server is entitled to use the virtual computer's return stack to store context information, and therefore customer software must comply with the general rules that apply to the use of return stacks.

1.8 TLV-håndtering1.8 TLV handling

Symbolene beskrevet i dette avsnitt tilveiebringer TLV-håndtering og tilgangsfunksjon. The symbols described in this section provide TLV handling and access functionality.

1.8.1 Støtte til strengbehandling1.8.1 Support for string processing

F9 78 PLUSSTRINGF9 78 PLUS STRING

( c-addrileni c-addr2len2- c-addr2len3)(c-addrileni c-addr2len2- c-addr2len3)

Lagre strengen i c- addri for. lenj-byte i enden av strengen i c- addr? for len?-byte. Returner begynnelsen av målstrengen ( c- addr?) og summen av de to lengder (len^) . Det må være plass i enden av målstrengen til å romme begge strenger. Store the string in c- addri for. lenj bytes at the end of the string in c-addr? for len? bytes. Return the beginning of the target string ( c- addr?) and the sum of the two lengths (len^) . There must be room at the end of the target string to accommodate both strings.

F9 79 CPLUSSTRINGF9 79 CPLUS STRING

( char c-addr len — c-addr len+1 )( char c-addr len — c-addr len+1 )

Lagre karakteren char i enden av strengen i c- addr for ien-byte. Returner begynnelsen av målstrengen ( c- addr) og lengden av den resulterende streng ( len pluss 1). Det må være plass i enden av målstrengen til å romme tilleggskarakteren. Store the character char at the end of the string in c-addr for ien-byte. Return the beginning of the target string ( c- addr ) and the length of the resulting string ( len plus 1). There must be space at the end of the target string to accommodate the additional character.

F9 7A MINUSTRAILINGF9 7A MINUSTRAILING

( c-addr leni - c-addr len2)(c-addr leni - c-addr len2)

Hvis Jenjer større enn null, er len2lik Jen, minus antallet mellomrom (ASCII 20h) i enden av karakterstrengen angitt ved c- addr leni. Hvis leni er null, eller hele strengen består av mellomrom, er len? null. If Jenjer is greater than zero, len2 is equal to Jen, minus the number of spaces (ASCII 20h) at the end of the character string indicated by c- addr leni. If leni is zero, or the entire string consists of spaces, is len? zero.

F9 7B MINUSZEROSF9 7B MINUS ZEROS

( c-addr leni — c-addr len2)( c-addr leni — c-addr len2)

Hvis leni er større enn null, er len? lik leni minus antall nuller (ASCII 0h) i enden av karakterstrengen angitt ved c-addr lenj. Hvis lent er null, eller hele strengen består av nuller, er len? null. If leni is greater than zero, is len? equal to leni minus the number of zeros (ASCII 0h) at the end of the character string indicated by c-addr lenj. If len is zero, or the entire string consists of zeros, is len? zero.

F9 7C STORECOUNTF9 7C STORECOUNT

( char c-addr — )( char c-addr — )

Lagre nummer-cnar sammen med byten i c- addr. Generer en unn takssituasjonskode STRING_TOO_LARGE (for lang streng) hvis char er større enn 255. Store number-cnar together with the byte in c-addr. Generate an exception code STRING_TOO_LARGE (string too long) if char is greater than 255.

1.8.2 Tilgang til TLV-buffer1.8.2 Access to TLV buffer

F9 8 0 TLVF9 8 0 Tel

( num — c-addr len fmt )( num — c-addr len fmt )

Returner tilgangsparametrene for den TLV hvis etikett er num. Dette kan generere en unntakssituasjonskode UNDEFINED_TLV (ikke definert TLV). Return the access parameters for the TLV whose label is num. This may generate an exception situation code UNDEFINED_TLV (not defined TLV).

F9 81 TLVFETCHF9 81 TLVFETCH

( c-addrilenifmt — num | c-addr2len2 )( c-addrilenifmt — num | c-addr2len2 )

Returner innholdet i den interne TLV-buffer i henhold til dets TYPE-felt som er de nedre åtte biter av fmt. Typekoder 0 og 2 returnerer numre i stakken, mens de andre returnerer strengpekere. Adressen returnert av typekode-3-felter er midlertidig og må straks flyttes til et mer permanent sted. Den len2som returneres for strenger, er den samme som den som sist ble lagret i bufferen. Return the contents of the internal TLV buffer according to its TYPE field which is the lower eight bits of fmt. Type codes 0 and 2 return numbers on the stack, while the others return string pointers. The address returned by type-code-3 fields is temporary and must be immediately moved to a more permanent location. The len2 returned for strings is the same as the one last stored in the buffer.

F9 82 TLVSTOREF9 82 TLVSTORE

( num c-addr2len2fmt | c-addrilenic-addr2fmt- )(num c-addr2len2fmt | c-addrilenic-addr2fmt- )

Sett innholdet i den interne TLV-buffer i overensstemmelse med dens TYPE-felt som er de nedre åtte biter i fmt. Typekoder 0 og 2 tar numre i stakken, mens de andre tar strengpekere. Denne handling vil fastsette oppdelt-status-biten for denne TLV. Set the contents of the internal TLV buffer according to its TYPE field which is the lower eight bits of fmt. Type codes 0 and 2 take numbers on the stack, while the others take string pointers. This action will set the split-status bit for this TLV.

F9 83 TLVBITFETCHF9 83 TLVBITFETCH

( c-addr — flag )( c-addr — flag )

Returner resultatene av maskering av innholdet i den interne TLV-buffer som det er vist til gjennom sekvensen c- addr mot verdifeltet på det sted. Dette kan generere en unntakssituasjonskode UNDEFINED_TLV. flag vil blir returnert TRUE dersom alle bitene angitt i masken finnes i den interne buffer. Ellers blir FALSE returnert. Bare bytene dekket av det korteste av to steder blir kontrollert. Return the results of masking the contents of the internal TLV buffer pointed to through the sequence c-addr against the value field at that location. This may generate an exception situation code UNDEFINED_TLV. flag will be returned TRUE if all the bits specified in the mask are in the internal buffer. Otherwise, FALSE is returned. Only the bytes covered by the shorter of two locations are checked.

F9 84 TLVBITSTOREF9 84 TLVBITSTORE

( flag c-addr — )( flag c-addr — )

Sett innholdet i den interne TLV-buffer som det er vist til gjennom sekvensen i c- addr basert på verdifeltet på det sted. Hvis flag er FALSE (0), vil alle bitene som er angitt der, bli slått av. Ellers vil alle disse bli slått på. Set the contents of the internal TLV buffer pointed to through the sequence in c-addr based on the value field at that location. If flag is FALSE (0), all bits set there will be turned off. Otherwise, all of these will be turned on.

1.8.3 TLV-behandling1.8.3 TLV processing

F9 8 5 PARSETLVF9 8 5 PARSETLV

( c- addr len—)(c-addr len—)

Behandle len-byte i c- addr med hensyn til TLV-sekvenser. Dette kan generere en unntakssituasjonskode UNDEFINED_TLV. Hvert etikettfelt som påtreffes, vil plassere lengdefelt-byte fra dets verdifelt inn i den interne buffer og fastsette dets oppdelt-status-bit. Når et konstruert etikettfelt påtreffes, blir alle de interne TLV-buffere som er blitt definert som tilknyttet dette, slettet før verdifeltet blir oppdelt med tanke på TLV-sekvenser. Det vil ikke bli generert noen unntakssituasjon hvis en TLV blir påtruffet i en konstruert mal som det ikke er definert tilknyttet til. Treat len bytes in c-addr with respect to TLV sequences. This may generate an exception situation code UNDEFINED_TLV. Each label field encountered will place length field bytes from its value field into the internal buffer and set its split-status bit. When a constructed label field is encountered, all the internal TLV buffers that have been defined as associated with it are cleared before the value field is split into TLV sequences. No exception will be generated if a TLV is encountered in a constructed template to which it is not defined.

F9 8 6 PLUSDOLF9 8 6 PLUS DOL

( c-addrileni c-addr2len2- c-addr2len3)(c-addrileni c-addr2len2- c-addr2len3)

Behandle Jenj-byte i c- addr: - med tanke på etikett- og lengdefelter. Dette kan generere en unntakssituasjonskode UNDEFINED_TLV. Hvert etikettfelt som påtreffes, vil plassere lengdefelt-byte fra dets interne buffer og inn i et verdifelt i enden av ut-strengen i c- addr2 for len^-byte. Returner begynnelsen av målstrengen ( c- addr2) og summen av de to lengder ( len3) . Det må være plass i enden av ut-strengen til å romme begge strenger. Process Jenj bytes in c-addr: - considering label and length fields. This may generate an exception situation code UNDEFINED_TLV. Each label field encountered will place length field bytes from its internal buffer into a value field at the end of the out string in c-addr2 for len^ bytes. Return the beginning of the target string ( c-addr2) and the sum of the two lengths ( len3) . There must be room at the end of the out string to accommodate both strings.

P9 87 PLUSTLVP9 87 PLUS TV

( c-addr leni num - c-addr len2)( c-addr leni num - c-addr len2)

Legg TLV-sekvensen, hvis etikett er num, til enden av ut-strengen i c- addr for lenj-byte. Dette kan generere en unn-takssituas jonskode UNDEFINED_TLV. Etikett-, lengde- og verdi-feltene er formatert i henhold til TLV-regler basert på data i dens interne buffer. Returner begynnelsen av målstrengen ( c- addr) og summen av de to lengder ( len?) . Det må være plass i enden av ut-strengen til å romme begge strenger. Append the TLV sequence, whose label is num, to the end of the out string in c-addr for lenj bytes. This may generate an exception situation ion code UNDEFINED_TLV. The label, length, and value fields are formatted according to TLV rules based on data in its internal buffer. Return the beginning of the target string ( c- addr ) and the sum of the two lengths ( len?) . There must be room at the end of the out string to accommodate both strings.

F9 8 9 TLVSTATUSF9 8 9 TLVSTATUS

( fmt — num char )( fmt — num char )

Dekode statusen for TLV-tilgangsparameteren fmt. Det returnerte num er formatindikatoren 0- og biter i den returnerte char har følgende betydning, hvor bit 0 er den minst signifikante bit: Decode the status of the TLV access parameter fmt. The returned num is the format indicator 0- and bits in the returned char have the following meaning, where bit 0 is the least significant bit:

1.8.4 TLV-sekvenstilgang 1.8.4 TLV Sequence Access

F9 8A STOREBCDF9 8A STOREBCD

( u c-addr len - )( u c-addr len - )

Lagre nummer u som en binærkodet-desimal-sekvens inn i strengen i c- addr for ien-byte. Nummeret er formatert slik at hvert siffer representerer 4-biters nibler i utstrengen. Ledende nibler vil bli fylt med O-er om nødvendig. Den mest signifikante del av nummeret vil bli avkuttet hvis len ikke er lang nok til å romme alle sifrene. Store number u as a binary-encoded-decimal sequence into the string in c-addr for ien bytes. The number is formatted so that each digit represents 4-bit nibbles in the output string. Leading nibles will be filled with O's if necessary. The most significant part of the number will be truncated if the line is not long enough to accommodate all the digits.

F9 8B FETCHBCDF9 8B FETCHBCD

( c-addr len - u )( c-addr len - u )

Hent nummer u fra en binærkodet desimalsekvens i c- addr for - len-byte. Nummeret er formatert slik at hvert siffer representerer 4-biters nibler i innstrengen. En unntakssituasjon DIGIT_TOO_LARGE (for mange siffer) blir fremsatt hvis en eller annen nibbel ikke er et gyldig BCD-siffer. Get number u from a binary encoded decimal sequence in c- addr for - len byte. The number is formatted so that each digit represents 4-bit nibbles in the input string. A DIGIT_TOO_LARGE (too many digits) exception is thrown if any nibble is not a valid BCD digit.

F9 8C STOREBNF9 8C HIGHWAY

( u c-addr len - )( u c-addr len - )

Lagre nummer u som binært nummer inn i strengen i c- addr for len-byte. Den mest signifikante byte i nummeret blir lagret først. Ledende byte vil bli fylt med O-er om nødvendig. Den mest signifikante del av nummeret vil bli avkuttet hvis len ikke er lang nok til å romme alle bytene. Store number u as binary number into the string in c-addr for len-byte. The most significant byte in the number is stored first. Leading bytes will be padded with O's if necessary. The most significant part of the number will be truncated if the len is not long enough to accommodate all the bytes.

F9 8D FETCHBNF9 8D FETCHBN

( c-addr len — u )( c-addr len — u )

Hent nummer u som et binært nummer fra strengen i c- addr med tanke på len-byte. Den mest signifikante byte i nummeret hentes først. Hvis det er mer enn fire byte data på stedet, vil de mest signifikante byte gå tapt. Get number u as a binary number from the string in c-addr considering len bytes. The most significant byte in the number is fetched first. If there are more than four bytes of data in place, the most significant bytes will be lost.

F9 8E STORECNF9 8E STORECN

( c-addrileni c-addr?len? - )( c-addrileni c-addr?len? - )

Lagre nummeret i c- addrt for lenj-byte som et komprimert nummer inn i en streng i c- addr2 for Ien?-byte. Nummeret er formatert slik at hver karakter representerer en 4-biters nibbel i utstrengen. Etterhengende nibler vil bli fylt med F-er etter behov. Nummeret vil bli avkuttet hvis len2ikke er lang nok til å romme alle karakterene { len2<[ ler\ i + l]/ 2). En unn-takssituas jonskode DIGIT_TOO_LARGE (for mange siffer) vil bli generert hvis en karakter i innstrengen ikke er et nummer. Store the number in c-addrt for lenj bytes as a compressed number into a string in c-addr2 for Ien? bytes. The number is formatted so that each character represents a 4-bit nibble in the output string. Trailing nibles will be filled with F's as needed. The number will be truncated if len2 is not long enough to accommodate all the characters { len2<[ ler\ i + l]/ 2). An exception ion code DIGIT_TOO_LARGE (too many digits) will be generated if a character in the input string is not a number.

F9 8F FETCHCNF9 8F FETCHCN

( c-addrileni — c-addr2len2)(c-addrileni — c-addr2len2)

Hent en streng til det midlertidige sted c- addr2 for len-byte som representerer det komprimerte nummer i strengen i c-addri, for ien;-byte. Nummeret er formatert slik at hver karakter i utstrengen representerer en 4-biters nibbel i innstrengen. Utstrengen vil bli avsluttet når det påtreffes en nibbel med alle biter fastsatt eller enden av strengen. En unntakssituasjonskode DIGIT_TOO_LARGE vil bli generert hvis en nibbel i innstrengen ikke er et tall. Utstrengen må straks flyttes til et mer permanent sted. Get a string into the temporary location c-addr2 for len bytes representing the compressed number in the string in c-addri, for ien; bytes. The number is formatted so that each character in the output string represents a 4-bit nibble in the input string. The output string will be terminated when a nibble is encountered with all bits set or the end of the string. An exception situation code DIGIT_TOO_LARGE will be generated if a nibble in the input string is not a number. The outrigger must be immediately moved to a more permanent location.

F9 90 TLVFETCHNAMEF9 90 TLVFETCHNAME

( c-addri— c-addr2num )( c-addr— c-addr2num )

Del opp TLV-sekvensen i c- addr! med tanke på et etikettfelt. Returner adressen c- addr2 som kommer etter etikettfeltet, og etikettfeltets num. Split the TLV sequence into c-addr! considering a label field. Return the address c-addr2 that comes after the label field, and the label field's num.

F9 91 TLVFETCHLENGTHF9 91 TLVFETCHLENGTH

( c-addri— c-addr?len )( c-addri— c-addr?len )

Del opp TLV-sekvensen i c- addri med tanke på et lengde-felt. Returner adressen c- addr2, som kommer etter lengde-feltet, og den len som inneholdes i feltet. Split the TLV sequence into c-addri with a length field in mind. Return the address c-addr2, which comes after the length field, and the len contained in the field.

1.9 Modulhåndtering1.9 Module handling

Nedenstående symboler gir rom for lagring og utførelse av EPICode-moduler i den virtuelle datamaskin. The symbols below provide space for storing and executing EPICode modules in the virtual computer.

F9 AO EXECUTEMODULEF9 AO EXECUTE MODULE

( c-addr len — flag )( c-addr len — flag )

Last inn en modul fra modulkatalogen ved å benytte AID-en angitt gjennom c- addr len. Unntakssituasjonen Load a module from the module directory using the AID specified through the c-addr len. The exceptional situation

CANNOT_LOAD_MODULE (kan ikke laste modul) blir fremsatt dersom det oppstår en feil. flag er TRUE hvis modulen ikke blir funnet, FALSE er "vellykket innlasting". CANNOT_LOAD_MODULE (cannot load module) is issued if an error occurs. flag is TRUE if the module is not found, FALSE is "successful loading".

F9 Al INITMODULEBUFFERF9 Al INITMODULE BUFFER

(<->) (<->)

Gjør klar for innhenting av en ny modul.Prepare for the acquisition of a new module.

F9 A2 MODULEBUFFERAPPENDF9 A2 MODULE BUFFER APPEND

( c-addr len — )( c-addr len — )

Føy innholdet i bufferen angitt gjennom c- addr og Jen til modul innhent ingsbu f f er en . Unntakssituasjon Add the contents of the buffer specified through c-addr and Jen to module acquisition buffer f f is a . Exceptional situation

CANNOT_ADD_T0_M0DUL (kan ikke tilføye til modul) blir fremsatt hvis modulbufferen ikke er blitt klargjort, eller hvis modulbufferens kapasitet er overskredet. CANNOT_ADD_T0_M0DUL (cannot add to module) is issued if the module buffer has not been prepared, or if the capacity of the module buffer has been exceeded.

F9 A3 REGISTERMODULEF9 A3 REGISTER MODULE

( c-addr len — )( c-addr len — )

Registrer modulbufferen i modulkatalogen under den gitte EPICode AID angitt gjennom c- addr len. Ressursene tilknyttet håndtering av modulbufferen blir automatisk frigjort. Register the module cache in the module directory under the given EPICode AID specified through the c-addr. The resources associated with handling the module buffer are automatically freed.

F9 A4 RELEASEMODULEBUFFERF9 A4 RELAY MODULE BUFFER

(<->) (<->)

Frigjør ressursene benyttet av den interne modulbuffer. Dette er nødvendig hvis for tidlig innlasting av en modul må avsluttes av brukerprogrammet uten å registrere modulen i modulkatalogen . Free the resources used by the internal module buffer. This is necessary if premature loading of a module must be terminated by the user program without registering the module in the module directory.

F9 A5 DELETEMODULF9 A5 DELETE MODULE

( c-addr len — flag )( c-addr len — flag )

Slett modulen hvis AID er angitt gjennom c- addr len, fra mo-dulregisteret. fiag er null hvis operasjonen var vellykket. Delete the module whose AID is specified through the c-addr len, from the module register. fiag is zero if the operation was successful.

F9 A6 MODULEINFOF9 A6 MODULE INFO

( c-addrileni — c-addr2len2flag )( c-addrileni — c-addr2len2flag )

Returner "offentlig" informasjon i den modul som er registrert i modulkatalogen under AID-en angitt gjennom c-addrilen!. flag er null hvis operasjonen var vellykket, og dataene i c- addrj er gyldige. Strukturen i bufferen returnert av dette symbol er definert gjennom opplysningene i modulho-det. Bare oppføringene EPF_VER gjennom EPF_ENTRY blir returnert av denne funksjon. Return "public" information in the module registered in the module directory under the AID specified through the c addril!. flag is zero if the operation was successful and the data in c-addrj is valid. The structure in the buffer returned by this symbol is defined through the information in the module header. Only the entries EPF_VER through EPF_ENTRY are returned by this function.

F9 A7 LOADCARDMODULEF9 A7 LOAD CARD MODULE

( a-addr — )(a-addr — )

Last inn modulen i a- addr. a- addr er adressen til hodet i en EPICode-modul levert fra kortet og inn i internlager. Unntakssituasjonen BAD_CARD_MODULE (dårlig kortmodul) fremsettes hvis modulen bryter noen av betingelsene for kortmodulinnlas-ting. Load the module in a-addr. a-addr is the address of the header in an EPICode module delivered from the card into internal storage. The exception situation BAD_CARD_MODULE (bad card module) is raised if the module violates any of the conditions for card module loading.

F9 A8 MODULESCHANGEDF9 A8 MODULE CHANGED

( - U )( - U )

Returner en verdi u som angir om moduler har forandret seg. Bit 0 til og med 7 angir hvilke modulklasser som er blitt registrert i modulkatalogen siden forrige utførelse av dette symbol. For eksempel vil en modul som er registrert med en innledende AID-byte som er F4, sette bit 4 i returstatusen. Bitene 8 til og med 31 er reservert for fremtidige utvidel-ser . Return a value u indicating whether modules have changed. Bits 0 to 7 indicate which module classes have been registered in the module catalog since the last execution of this symbol. For example, a module registered with an initial AID byte that is F4 will set bit 4 in the return status. Bits 8 to 31 are reserved for future extensions.

1.10 Håndtering av utvidbart minne1.10 Handling of expandable memory

Følgende symboler gir tilgang til en utvidbar "strekk"-buffer med lineært minne i dataområdet tilveiebrakt og håndtert av den virtuelle datamaskin. The following symbols provide access to an expandable "stretch" buffer of linear memory in the data area provided and managed by the virtual computer.

F9 BO EXTENDF9 BO EXTEND

( len— a-addr )( len— a-addr )

Utvid "strekk"-bufferen med len-celler og returner den celleinnrettede adresse a- addr for den første celle i den tildelte buffer. ZERO EXTEND returnerer en peker til den neste ikke-tildelte celle. En unntakssituasjon 0UT_0F_MEM0RY fremsettes dersom det ikke er nok minne tilgjengelig. Extend the "stretch" buffer with len cells and return the cell-aligned address a-addr of the first cell in the allocated buffer. ZERO EXTEND returns a pointer to the next unallocated cell. An exception situation 0UT_0F_MEM0RY is raised if there is not enough memory available.

F9 Bl BEXTENDF9 Bl BEXTEND

( len — c-addr )( len — c-addr )

Utvid "strekk"-bufferen med len-byte, og returner adressen c-addr for den første byte i den tildelte buffer. ZERO BEXTEND returnerer en peker til den neste ikke-tildelte byte. En unntakssituasjon OUT_OF_MEMORY blir fremsatt hvis det ikke er nok minne tilgjengelig. Extend the "stretch" buffer by len bytes, and return the address c-addr of the first byte in the allocated buffer. ZERO BEXTEND returns a pointer to the next unallocated byte. An OUT_OF_MEMORY exception is thrown if there is not enough memory available.

F9 B2 RELEASEF9 B2 RELEASE

( addr - )( addr - )

Frigjør lagerplass innhentet gjennom EXTEND eller BEXTEND, idet den "frie peker" settes til addr. Hvis addr er ugyldig (før starten av strekk-bufferen, eller ut over den aktuelle "frie peker") blir det fremsatt et ANS-unntakssituasjon -9 (ugyldig minneadresse). Free up storage space obtained through EXTEND or BEXTEND, as the "free pointer" is set to addr. If addr is invalid (before the start of the stretch buffer, or beyond the current "free pointer"), an ANS exception -9 (invalid memory address) is raised.

Ytterligere symboler:Additional symbols:

F9 BO DSCHECKF9 BO DSCHECK

( u - flag ) Kontroller at det i det minste finnes u ( u - flag ) Check that at least u exists

dataceller igjen i datastakken. Returnerdata cells left in the data stack. Return

FALSE hvis dette er tilfellet, ellers TRUE.FALSE if this is the case, otherwise TRUE.

F9 Bl RSCHECKF9 Bl RSCHECK

( u - flag )(u-flag)

Kontroller at det i det minste finnes uCheck that there is at least u

dataceller igjen på returstakken. Returner FALSE hvis dette er tilfellet, ellers TRUE. data cells left on the return stack. Return FALSE if this is the case, otherwise TRUE.

1.11 Sikkerhetskommandoer1.11 Security Commands

Behandling av sikkerhetsalgoritmer kan oppta flere sekunder på noen terminaler. Den herværende oppfinnelse innbefatter at den herværende enkeltkommando SECALGO skal faktoriseres inn i initierings- og kompletteringskomponenter for å gjøre det lettere å bruke den sammen med implementeringer av flerbruks-kjøringer. Dette er under utprøving, og følgende forslag fremsettes som et alternativ til SECALGO. Processing security algorithms can take several seconds on some terminals. The present invention includes the present single command SECALGO to be factored into initialization and completion components to facilitate its use in conjunction with implementations of multitasking executions. This is being tested, and the following proposal is put forward as an alternative to SECALGO.

F9 56 SECALGOBEGINF9 56 SECALGOBEGIN

( c- addr! len c- addr2 num — flag )( c- addr! len c- addr2 num — flag )

Dette behandler data ved bruk av algoritmenThis processes data using the algorithm

av type num. c- addri er inn-databufferen for behandling, og len er dens lengde. c- addr2 er ut-bufferen for lagring av resultatet. Denne funksjon returnerer et flag som angir FALSE of type num. c- addri is the input data buffer for processing, and len is its length. c- addr2 is the output buffer for storing the result. This function returns a flag indicating FALSE

hvis databehandling kan med hell innledes.whose data processing can be successfully initiated.

F9 57 SECALGOENDF9 57 SECALGOEND

(- ior)(- ior)

Denne funksjon returnerer en ior som viser:This function returns an ior showing:

0 = databehandling vellykket gjennomført; -1 = databehandling pågår; 1 = databehandling mislykket. 0 = data processing successfully completed; -1 = data processing in progress; 1 = data processing failed.

UnntakssituasjonskoderException Codes

Dette avsnitt innbefatter alle koder som benyttes som påstander for standardfunksjonen THROW for unntakssituasjonshåndte-ring. This section includes all code that is used as assertions for the standard function THROW for exception handling.

Følgende tabell viser ANS-Forth-kodene benyttet i EPIC-kj erner. The following table shows the ANS-Forth codes used in EPIC kernels.

Claims

1. Transaksjonshåndteringssystem til utførelse av transaksjoner mellom en første utstyrsenhet og en andre utstyrsenhet, hvor første og andre utstyrsenhet er tilpasset til å kommunisere med hverandre, og i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5), karakterisert ved at nevnte system omfatter i det minste én inn/ut-enhet (6); en bærbar virtuell datamaskin (20) til tolking av et dataprogram i nevnte første utstyrsenhet, idet nevnte virtuelle datamaskin (20) omfatter en virtuell mikroprosessor og en driver for nevnte i det minste ene inn/utenhet (6); samt utførelsesmiddel som reagerer på nevnte tolkede program for utførelse av nevnte program.1. Transaction management system for carrying out transactions between a first equipment unit and a second equipment unit, where the first and second equipment units are adapted to communicate with each other, and at least one of said first and second equipment units is an integrated circuit card (5) , characterized in that said system comprises at least one input/output unit (6); a portable virtual computer (20) for interpreting a computer program in said first equipment unit, said virtual computer (20) comprising a virtual microprocessor and a driver for said at least one input/output device (6); as well as execution means that react to said interpreted program for execution of said program.

2. Terminal (1) som omfatter en første utstyrsenhet til ut-førelse av en transaksjon med en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5), karakterisert ved at terminalen (1) omfatter en bærbar virtuell datamaskin (20) som tolker et dataprogram i nevnte første utstyrsenhet, idet nevnte bærbare virtuelle datamaskin (20) omfatter en virtuell mikroprosessor og en driver for i det minste én inn/ut-enhet (6), samt utførelsesmiddel som reagerer på nevnte tolkede program for utførelse av nevnte program.2. Terminal (1) comprising a first equipment unit for carrying out a transaction with a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card (5), characterized in that the terminal ( 1) comprises a portable virtual computer (20) which interprets a computer program in said first equipment unit, said portable virtual computer (20) comprising a virtual microprocessor and a driver for at least one input/output unit (6), as well as execution means which responds to said interpreted program for execution of said program.

3. Selvstendig, bærbart intelligent kort (5) som innbefatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, karakterisert ved at nevnte intelligente kort (5) omfatter en bær bar virtuell datamaskin (20) som omfatter en virtuell mikroprosessor og en driver for i det minste én inn/utenhet (6) .3. Independent, portable intelligent card (5) comprising a first equipment unit for carrying out a transaction with a second equipment unit, characterized in that said intelligent card (5) comprises a portable virtual computer (20) comprising a virtual microprocessor and a driver for at least one input/output device (6) .

4. System ifølge krav 1 eller terminal ifølge krav 2 eller intelligent kort ifølge krav 3, karakterisert ved at maskininstruksjonene i nevnte virtuelle datamaskin (20) er et sett av symboler, hvilke symboler er kundetilpasset bytekode.4. System according to claim 1 or terminal according to claim 2 or intelligent card according to claim 3, characterized in that the machine instructions in said virtual computer (20) are a set of symbols, which symbols are customized byte code.

5. Intelligent kort ifølge krav 3 eller 4, karakterisert ved at det videre omfatter et dataprogram lagret i nevnte intelligente kort, hvor nevnte virtuelle datamaskin (20) tolker nevnte dataprogram, samt utførelsesmiddel som reagerer på nevnte tolkede program til utførelse av nevnte program.5. Intelligent card according to claim 3 or 4, characterized in that it further comprises a computer program stored in said intelligent card, where said virtual computer (20) interprets said computer program, as well as execution means that react to said interpreted program for execution of said program.

6. System eller terminal (1) ifølge krav 4 eller intelligent kort ifølge krav 5, karakterisert ved at nevnte dataprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett samt motsvarende innebygde data.6. System or terminal (1) according to claim 4 or intelligent card according to claim 5, characterized in that said computer program is written as a stream of symbols selected from said symbol set as well as corresponding embedded data.

7. System eller terminal (1) eller intelligent kort (5) i-følge krav 6, karakterisert ved at nevnte strøm av symboler blir transportert i en modul (72), en modul som innbefatter strømmen av symboler sammen med de motsvarende innebygde data som er nødvendig for utførel-se av modulen.7. System or terminal (1) or intelligent card (5) according to claim 6, characterized in that said stream of symbols is transported in a module (72), a module which includes the stream of symbols together with the corresponding embedded data which is necessary for execution of the module.

8. System eller terminal (1) eller intelligent kort (5) ifølge krav 7, karakterisert ved at nevn te modul (72) også innbefatter en angivelse av minnebe-hov for utførelse av nevnte modul.8. System or terminal (1) or intelligent card (5) according to claim 7, characterized in that said module (72) also includes an indication of memory requirements for execution of said module.

9. System eller terminal (1) eller intelligent kort (5) i-følge krav 8, karakterisert ved at den virtuelle datamaskin (20) også innbefatter et middel (73) til innlasting av nevnte modul (72) og tolking av symbolene i denne.9. System or terminal (1) or intelligent card (5) according to claim 8, characterized in that the virtual computer (20) also includes a means (73) for loading said module (72) and interpreting the symbols therein .

10. System eller terminal (1) eller intelligent kort (5) i-følge krav 9, karakterisert ved at nevnte middel (73) til symbolinnlasting og tolking leser nevnte symboler i nevnte modul (72), og en unntakssituasjon fremsettes hvis det leses et symbol som ikke tilhører nevnte sett.10. System or terminal (1) or intelligent card (5) according to claim 9, characterized in that said means (73) for symbol loading and interpretation reads said symbols in said module (72), and an exception situation is presented if a symbol that does not belong to said set.

11. System eller terminal (1) eller intelligent kort (5) i-følge hvilket som helst av kravene 7 til 10, karakterisert ved at nevnte virtuelle datamaskin (20) innbefatter lesbart/skrivbart logisk-adresse-område (24) som har et oppbevaringssted for i det minste nevnte modul (72), hvor nevnte modul innbefatter en angivelse av hvor mye lesbart/skrivbart logisk-adresse-område (24) som er nødvendig for dens utførelse; og nevnte virtuelle datamaskin (20) også innbefatter middel for tildeling, ved innlasting av nevnte modul, av en mengde lesbart/ skrivbart logisk-adresse-område (24) i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/ skrivbare logisk-adresse-område (24) har definerte og beskyttede grenser.11. System or terminal (1) or intelligent card (5) according to any one of claims 7 to 10, characterized in that said virtual computer (20) includes a readable/writable logical address area (24) which has a storage location for at least said module (72), where said module includes an indication of how much readable/writable logical address area (24) is necessary for its execution; and said virtual computer (20) also includes means for allocating, when loading said module, a quantity of readable/writable logical address area (24) in accordance with said indication, where said allocated readable/writable logical address area (24) has defined and protected boundaries.

12. System eller terminal (1) eller intelligent kort (5) ifølge krav 11, karakterisert ved at det/den videre omfatter middel til fraordning av nevnte tildelte mengde lesbart/skrivbart logisk-adresse-område (24) ved avslutning av nevnte modul (72) .12. System or terminal (1) or intelligent card (5) according to claim 11, characterized in that it/it further comprises means for disorganizing said allocated amount of readable/writable logical address area (24) upon termination of said module (72).

13. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 9 til 12, karakterisert ved at nevnte andre enhet innbefatter middel til å tilveiebringe i det minste én programinstruksjon som er i stand til i det minste å modifisere nevnte dataprograms oppførsel på utførelses-tidspunktet, og etter at nevnte middel (73) til innlasting og tolking har lastet inn nevnte modul (72), og mens nevnte modul kjøres, laster og tolker nevnte middel til innlasting og tolking av nevnte i det minste ene programinstruksjon avhengig av forhåndsdefinerte sikker-hetsbetingelser; og nevnte utførelsesmiddel svarer på nevnte innlastede programinstruksjon slik den er tolket av nevnte virtuelle datamaskin (20), og utfører nevnte dataprogram med nevnte modifiserte oppførsel.13. System or terminal (1) or intelligent card (5) according to any one of claims 9 to 12, characterized in that said second unit includes means for providing at least one program instruction which is capable of at least modifying said computer program's behavior at the time of execution, and after said means (73) for loading and interpreting has loaded said module (72), and while said module is running, said means for loading and interpreting said at least one program instruction dependent on predefined security conditions; and said execution means responds to said loaded program instruction as interpreted by said virtual computer (20), and executes said computer program with said modified behavior.

14. System eller terminal (1) eller intelligent kort (5) ifølge krav 13, karakterisert ved at nevnte sikkerhetsbetingelse er tilveiebrakt gjennom en funksjon.14. System or terminal (1) or intelligent card (5) according to claim 13, characterized in that said security condition is provided through a function.

15. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 9 til 14, karakterisert ved at den/det videre omfatter lesbart/skrivbart logisk-adresse-område (24) som innbefatter i det minste én database som innbefatter i det minste én post, hvor nevnte modul (72) innbefatter en angivelse av den mengde ikke-initialisert lesbart/ skrivbart logisk-adresse-område (24) som er nødvendig for utførelse av nevnte modul (72); nevnte innlaster (73) tildeler den nødvendige mengde ikke-initialisert logisk-adresse-område (42) i overensstemmelse med nevnte angivelse; samt middel for tilgang til en post i nevnte database, hvor nevnte post i nevnte database bare er tilgjengelig gjennom nevnte modul (72), og nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti i nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område (42) som kan adresseres av nevnte brukerprogram.15. System or terminal (1) or intelligent card (5) according to any one of claims 9 to 14, characterized in that it/it further comprises a readable/writable logical address area (24) which includes at least one database which includes at least one record, wherein said module (72) includes an indication of the amount of uninitialized readable/writable logical address area (24) which is necessary for execution of said module (72); said loader (73) allocates the required amount of uninitialized logical address space (42) in accordance with said indication; as well as means for accessing a record in said database, where said record in said database is only accessible through said module (72), and said means of access provides a window into a relevant record in said database and copies said record into a lot in said uninitialized readable/writable logical address area (42) addressable by said user program.

16. Transaksjonshåndteringssystem, karakterisert ved at det omfatter en første utstyrsenhet og en andre utstyrsenhet, hvor første og andre utstyrsenhet er tilpasset til å kommunisere med hverandre, idet i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5); nevnte andre utstyrsenhet innbefatter middel til å tilveiebringe i det minste én programinstruksjon som er i stand til i det minste å modifisere oppførselen på utførelsestidspunktet for et dataprogram i nevnte første utstyrsenhet; nevnte første utstyrsenhet innbefatter en virtuell datamaskin (20), hvor nevnte virtuelle datamaskin (20) omfatter middel til innlasting og tolking av nevnte dataprogram, hvor nevnte middel til innlasting og tolking videre er tilpasset til å laste inn og tolke nevnte i det minste ene programinstruksjon avhengig av en forhåndsbestemt sikkerhetsbetingelse etter at nevnte middel til innlasting og tolking har lastet inn nevnte dataprogram, og mens nevnte dataprogram kjøres; og utførelsesmiddel til utfø-relse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon.16. Transaction handling system, characterized in that it comprises a first equipment unit and a second equipment unit, where the first and second equipment units are adapted to communicate with each other, at least one of said first and second equipment units being an integrated circuit card (5 ); said second equipment unit includes means for providing at least one program instruction capable of at least modifying the execution-time behavior of a computer program in said first equipment unit; said first equipment unit includes a virtual computer (20), where said virtual computer (20) comprises means for loading and interpreting said computer program, where said means for loading and interpreting is further adapted to load and interpret said at least one program instruction subject to a predetermined security condition after said loading and interpreting means has loaded said computer program, and while said computer program is running; and execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

17. Terminal (1) som omfatter en første utstyrsenhet til ut-førelse av en transaksjon med en andre utstyrsenhet og i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5), hvor nevnte andre enhet innbefatter middel til tilveiebringelse av i det minste én programinstruksjon som er i stand til i det minste å modifisere oppførselen på utførelsestidspunktet for et dataprogram i nevnte første utstyrsenhet, karakterisert ved at nevnte terminal (1) omfatter: nevnte første utstyrsenhet som innbefatter en virtuell datamaskin (20), hvor nevnte virtuelle datamaskin (20) omfatter middel til innlasting og tolking av nevnte dataprogram, hvor nevnte middel til innlasting og tolking videre er tilpasset til å laste inn og tolke nevnte i det minste ene programinstruksjon avhengig av en forhåndsdefinert sikkerhetsbetingelse, etter at nevnte middel til innlasting og tolking har lastet inn nevnte dataprogram, og mens nevnte dataprogram kjøres; samt utførelsesmiddel til utførelse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon.-17. Terminal (1) comprising a first equipment unit for carrying out a transaction with a second equipment unit and at least one of said first and second equipment units is an integrated circuit card (5), where said second unit includes means for the provision of at least one program instruction which is capable of at least modifying the behavior at the time of execution of a computer program in said first equipment unit, characterized in that said terminal (1) comprises: said first equipment unit which includes a virtual computer (20), where said virtual computer (20) comprises means for loading and interpreting said computer program, where said means for loading and interpreting is further adapted to load and interpret said at least one program instruction depending on a predefined security condition, after said means for loading and interpreting has loaded said computer program, and while said computer program is running; as well as execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.-

18. Selvstendig, bærbart intelligent kort (5) som innbefatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, hvor nevnte andre utstyrsenhet innbefatter middel til tilveiebringelse av i det minste én programinstruksjon som er i stand til i det minste å modifisere oppførselen på utførelsestids-punktet for et dataprogram i nevnte første utstyrsenhet, karakterisert ved at nevnte intelligente kort (5) omfatter: nevnte første utstyrsenhet som innbefatter en virtuell datamaskin (20), hvor nevnte virtuelle datamaskin (20) omfatter middel til innlasting og tolking av nevnte dataprogram, hvor nevnte middel til innlasting og tolking videre er tilpasset til å laste inn og tolke nevnte i det minste ene programinstruksjon avhengig av en forhåndsdefinert sikkerhetsbetingelse etter at nevnte middel til innlasting og tolking har lastet inn nevnte dataprogram, og mens nevnte dataprogram kjøres; samt utførelsesmiddel til utførelse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon .18. Self-contained, portable intelligent card (5) comprising a first equipment unit for carrying out a transaction with a second equipment unit, said second equipment unit comprising means for providing at least one program instruction capable of at least modifying the behavior at the time of execution of a computer program in said first equipment unit, characterized in that said intelligent card (5) comprises: said first equipment unit which includes a virtual computer (20), where said virtual computer (20) includes means for loading and interpreting said computer program, where said means for loading and interpreting is further adapted to load and interpret said at least one program instruction depending on a predefined security condition after said means for loading and interpreting has loaded said computer program, and while said computer program is running; as well as execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

19. System ifølge krav 16 eller terminal ifølge krav 17 eller intelligent kort (5) ifølge krav 18, karakterisert ved at nevnte sikkerhetsbetingelse er tilveiebrakt gjennom en funksjon.19. System according to claim 16 or terminal according to claim 17 or intelligent card (5) according to claim 18, characterized in that said security condition is provided through a function.

20. System eller terminal (1) eller intelligent kort (5) ifølge krav 19, karakterisert ved at i det minste én programinstruksjon er en første programinstruksjon, og nevnte første utstyrsenhet innbefatter en andre programinstruksjon som er i stand til i det- minste å modifisere nevnte dataprograms oppførsel på utførel-sestidspunktet, hvor nevnte første programinstruksjon innbefatter en henvisning til nevnte andre programinstruksjon; samt at nevnte middel til innlasting og tolking svarer på nevnte henvisning for å laste inn nevnte andre programinstruksjon, hvor nevnte utførelsesmiddel utfører nevnte dataprogram med nevnte modifiserte opp-førsel som bestemt gjennom nevnte andre programinstruksjon.20. System or terminal (1) or intelligent card (5) according to claim 19, characterized in that at least one program instruction is a first program instruction, and said first equipment unit includes a second program instruction which is capable of at least modifying said computer program's behavior at the time of execution, where said first program instruction includes a reference to said second program instruction; and that said means for loading and interpreting responds to said reference to load said second program instruction, where said execution means executes said computer program with said modified behavior as determined through said second program instruction.

21. System eller terminal eller intelligent kort (5) ifølge krav 20, karakterisert ved at nevnte dataprogram og nevnte første og andre programinstruksjon er skrevet i form av en strøm av symboler og motsvarende innebygde data, hvor hvert symbol er en kundetilpasset bytekode valgt fra et sett av kundetilpassede bytekoder.21. System or terminal or intelligent card (5) according to claim 20, characterized in that said computer program and said first and second program instructions are written in the form of a stream of symbols and corresponding embedded data, where each symbol is a customized byte code selected from a set of customized bytecodes.

22. System eller terminal (1) eller intelligent kort (5) ifølge krav 21, kara k/ t erisert ved at nevnte virtuelle datamaskin (20) vektoriserer nevnte strøm av symboler og nevnte innebygde data fra nevnte første og andre programinstruksjon inn i nevnte symbol-strøm i nevnte dataprogram.22. System or terminal (1) or intelligent card (5) according to claim 21, characterized in that said virtual computer (20) vectorizes said stream of symbols and said embedded data from said first and second program instruction into said symbol - current in said computer program.

23. System eller terminal (1) eller intelligent kort (5) ifølge krav 21 eller 22, karakterisert ved at i det minste strømmene av symboler i nevnte dataprogram og i det minst nevnte andre programinstruksjon begge blir transportert i en modul, idet hver modul innbefatter den relevante strøm av symboler sammen med de motsvarende innebygde data som er nødvendig for å utføre nevnte modul.23. System or terminal (1) or intelligent card (5) according to claim 21 or 22, characterized in that at least the streams of symbols in said computer program and in at least said second program instruction are both transported in a module, each module including the relevant stream of symbols together with the corresponding embedded data necessary to execute said module.

24. System eller terminal (1) eller intelligent kort (5) ifølge krav 23, karakterisert ved at nevnte modul også innbefatter en angivelse av det minne som er nødvendig for utførelse av nevnte modul.24. System or terminal (1) or intelligent card (5) according to claim 23, characterized in that said module also includes an indication of the memory that is necessary for execution of said module.

25. System eller terminal (1) eller intelligent kort (5) ifølge krav 23 eller 24, karakterisert ved at modulen i nevnte dataprogram også innbefatter en eksklusiv liste over i det minste én modifiserbar kontakt (60), hvor nevnte i det minste ene kontakt (60) definerer den posisjon i strømmen av symboler og innebygde data i nevnte dataprogrammodul til hvilken nevnte virtuelle datamaskin (20) vektoriserer nevnte første programinstruksjon.25. System or terminal (1) or intelligent card (5) according to claim 23 or 24, characterized in that the module in said computer program also includes an exclusive list of at least one modifiable contact (60), where said at least one contact (60) defines the position in the stream of symbols and embedded data in said computer program module to which said virtual computer (20) vectorizes said first program instruction.

26. System eller terminal (1) eller intelligent kort (5) ifølge krav 25, karakterisert ved at nevnte i det minste ene modifiserbare kontakt (60) i nevnte dataprogrammodul inneholder en utførelsesvektor for en standardoppførsel.26. System or terminal (1) or intelligent card (5) according to claim 25, characterized in that said at least one modifiable contact (60) in said computer program module contains an execution vector for a standard behavior.

27. System eller terminal (1) eller intelligent kort (5) ifølge krav 26, karakterisert ved at nevnte utførelsesmiddel utfører nevnte dataprogram med nevnte standardoppførsel hvis nevnte forhåndsdefinerte sikkerhetsbetingelse ikke tillater innlasting av nevnte i det minste ene programinstruksjon.27. System or terminal (1) or intelligent card (5) according to claim 26, characterized in that said execution means executes said computer program with said standard behavior if said predefined security condition does not allow loading of said at least one program instruction.

28. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 23 til 27, karakterisert ved at nevnte virtuelle datamaskin (20) innbefatter lesbart/skrivbart logisk-adresse-område, nevnte modul innbefatter en angivelse av den mengde lesbart/skrivbart logisk-adresse-område som er nødvendig for dens utførelse; og nevnte virtuelle datamaskin (20) også innbefatter middel for, ved innlasting av nevnte dataprogrammodul, å tildele en mengde lesbart/skrivbart logisk-adresse-område i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser; samt middel til fraordning av nevnte mengde lesbare/skrivbare logisk-adresse-område ved avslutning av nevnte dataprogrammodul.28. System or terminal (1) or intelligent card (5) according to any one of claims 23 to 27, characterized in that said virtual computer (20) includes a readable/writable logical address area, said module includes an indication of the amount of readable/writable logical-address space required for its execution; and said virtual computer (20) also includes means for, when loading said computer program module, to allocate a quantity of readable/writable logical address area in accordance with said indication, where said allocated readable/writable logical address area has defined and protected borders; as well as means for disorganizing said amount of readable/writable logical address area upon termination of said computer program module.

29. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 23 til 28, karakterisert ved at den/det videre omfatter lesbart/skrivbart logisk-adresse-område som innbefatter i det minste én database som innbefatter en flerhet av poster, hvor nevnte modul innbefatter en angivelse av den mengde ikke-initialisert lesbart/ skrivbart logisk-adresse-område som er nødvendig for ut-førelse av nevnte modul; nevnte middel til innlasting tildeler den nødvendige mengde ikke-initialisert logisk-adresse-område i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, i-det poster i nevnte database bare er tilgjengelig gjennom nevnte modul, hvor nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og for kopiering av nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres av nevnte brukerprogram .29. System or terminal (1) or intelligent card (5) according to any one of claims 23 to 28, characterized in that it/it further comprises readable/writable logical address area which includes at least one database which includes a plurality of records, where said module includes an indication of the amount of non-initialized readable/writable logical address area which is necessary for execution of said module; said loading means allocates the required amount of uninitialized logical address space in accordance with said indication; and a means of accessing a record in said database, in that records in said database are only accessible through said module, where said means of access provides a window into a relevant record in said database and for copying said record into a batch of said uninitialized readable/writable logical address area addressable by said user program.

30. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 16 til 27, karakterisert ved at nevnte sikkerhetsbetingelse innbefatter middel til verifisering av i det minste opprinnelsen og integriteten for data og programinstruksjoner i nevnte andre utstyrsenhet.30. System or terminal (1) or intelligent card (5) according to any one of claims 16 to 27, characterized in that said security condition includes means for verifying at least the origin and integrity of data and program instructions in said second equipment unit.

31. Transaksjonssystem til utførelse av transaksjoner mellom en første utstyrsenhet og en andre utstyrsenhet, karakterisert ved at nevnte system omfatter: en virtuell datamaskin (20) til tolking av et sett av kundetilpassede bytekodesymboler anvendt på den; hvor nevnte virtuelle datamaskin (20) innbefatter en virtuell prosessorenhet og et lesbart/skrivbart logisk-adresse-område; i det minste ett første brukerprogram som innbefatter en angivelse av den mengde lesbart/skrivbart logisk-adresse-område som behøves for dets utførelse, hvor i det minste ett første brukerprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett og motsvarende innebygde data; nevnte virtuelle datamaskin omfatter også: en innlaster til innlasting av nevnte i det minste ene første brukerprogram; og middel til tildeling av en første mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene første brukerprogram i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser.31. Transaction system for carrying out transactions between a first equipment unit and a second equipment unit, characterized in that said system comprises: a virtual computer (20) for interpreting a set of customized byte code symbols applied to it; wherein said virtual computer (20) includes a virtual processor unit and a readable/writable logical address space; at least one first user program that includes an indication of the amount of readable/writable logical address area needed for its execution, where at least one first user program is written as a stream of symbols selected from said symbol set and corresponding embedded data; said virtual computer also comprises: a loader for loading said at least one first user program; and means for allocating a first amount of readable/writable logical address area specifically for said at least one first user program in accordance with said indication, where said allocated readable/writable logical address area has defined and protected boundaries.

32. Terminal som omfatter en første utstyrsenhet til utfø-relse av transaksjoner med en andre utstyrsenhet, karakterisert ved at nevnte første utstyrsenhet omfatter: en virtuell datamaskin (20) til tolking av et sett av kundetilpassede bytekodesymboler anvendt på den; hvor nevnte virtuelle datamaskin (20) innbefatter en virtuell prosessorenhet og lesbart/ skrivbart logisk-adresse-område; i det minste ett første brukerprogram som innbefatter en angivelse av den mengde lesbart/skrivbart logisk-adresse-område som er nødvendig for dets utførelse, hvor nevnte i det minste ene første brukerprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett og motsvarende innebygde data; hvor nevnte virtuelle datamaskin (20) også innbefatter: en innlaster til innlasting av nevnte i det minste ene første brukerprogram; og middel til tildeling av en før-ste mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene første brukerprogram i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser.32. Terminal comprising a first equipment unit for carrying out transactions with a second equipment unit, characterized in that said first equipment unit comprises: a virtual computer (20) for interpreting a set of custom byte code symbols applied to it; wherein said virtual computer (20) includes a virtual processor unit and readable/writable logical address space; at least one first user program which includes an indication of the amount of readable/writable logical address area that is necessary for its execution, where said at least one first user program is written as a stream of symbols selected from said symbol set and corresponding built-in data; where said virtual computer (20) also includes: a loader for loading said at least one first user program; and means for allocating a first amount of readable/writable logical address area specifically for said at least one first user program in accordance with said indication, where said allocated readable/writable logical address area has defined and protected boundaries.

33. Selvstendig, bærbart intelligent kort (5) som omfatter en første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, karakterisert ved at nevnte første utstyrsenhet omfatter: en virtuell datamaskin (20) til tolking av et sett av kundetilpassede bytekodesymboler anvendt på den; nevnte virtuelle datamaskin (20) innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste ett første brukerprogram som innbefatter en angivelse av den mengde lesbart/skrivbart logisk-adresse-område som er nødvendig for dets utførelse, hvor nevnte i det minste ene første brukerprogram er skrevet som en strøm av symboler valgt fra nevnte symbolsett og motsvarende innebygde data; hvor nevnte virtuelle datamaskin (20) også innbefatter: en innlaster til innlasting av nevnte i det minste ene første brukerprogram; og middel til tildeling av en første mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene første brukerprogram i overensstemmelse med nevnte angivelse, hvor nevnte tildelte lesbare/skrivbare logisk-adresse-område har definerte og beskyttede grenser.33. Self-contained, portable intelligent card (5) comprising a first equipment unit for carrying out a transaction with a second equipment unit, characterized in that said first equipment unit comprises: a virtual computer (20) for interpreting a set of customized byte code symbols used on the ; said virtual computer (20) includes a virtual processor unit and readable/writable logical address space; at least one first user program which includes an indication of the amount of readable/writable logical address area that is necessary for its execution, where said at least one first user program is written as a stream of symbols selected from said symbol set and corresponding built-in data; wherein said virtual computer (20) also includes: a loader for loading said at least one first user program; and means for allocating a first amount of readable/writable logical address area specifically for said at least one first user program in accordance with said indication, where said allocated readable/writable logical address area has defined and protected boundaries.

34. System ifølge krav 31 eller terminal ifølge krav 32 eller intelligent kort (5) ifølge krav 33, karakterisert ved at det/den videre omfatter middel til uttrykkelig fraordning av nevnte første mengde lesbart/skrivbart logisk-adresse-område ved avslutning av nevnte i det minste ene program.34. System according to claim 31 or terminal according to claim 32 or intelligent card (5) according to claim 33, characterized in that it/it further comprises means for expressly disorganizing said first amount of readable/writable logical address area at the end of said i at least one program.

35. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 31 til 34, karakterisert ved at i det minste én av første og andre utstyrsenhet er et ICC.35. System or terminal (1) or intelligent card (5) according to any one of claims 31 to 34, characterized in that at least one of the first and second equipment units is an ICC.

36. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 31 til 35, karakterisert ved at nevnte første brukerprogram også innbefatter en første eksklusiv liste over i det minste én funksjon som kan eksporteres til andre brukerprogrammer, idet det videre omfatter middel til å gjøre nevnte i det minste ene funksjon tilgjengelig for andre programmer.36. System or terminal (1) or intelligent card (5) according to any one of claims 31 to 35, characterized in that said first user program also includes a first exclusive list of at least one function that can be exported to other user programs, it further comprises means for making said at least one function available to other programs.

37. System eller terminal (1) eller intelligent kort (5) i overensstemmelse med hvilket som helst av kravene 31 til 36, karakterisert ved at nevnte første brukerprogram er en første modul (72), og nevnte andre brukerprogrammer er andre moduler, hvor hver modul innbefatter i det minste en strøm av symboler valgt fra nevnte symbolsett, motsvarende innebygde data, en første eksklusiv liste over i det minste én funksjon som skal eksporteres samt en angivelse av den mengde lesbart/ skrivbart logisk-adresse-område som behøves for utførel-se av modulen.37. System or terminal (1) or intelligent card (5) in accordance with any one of claims 31 to 36, characterized in that said first user program is a first module (72), and said other user programs are other modules, each module includes at least a stream of symbols selected from said symbol set, corresponding embedded data, a first exclusive list of at least one function to be exported as well as an indication of the amount of readable/writable logical address area that is needed for execution see off the module.

38. System eller terminal (1) ifølge krav 37, karakterisert ved at nevnte første modul (72) innbefatter en andre eksklusiv liste som angir i det minste én andre modul som det skal importeres i det minste én funksjon fra, og nevnte innlaster (73) laster inn nevnte i det minste ene andre modul i overensstemmelse med nevnte andre liste ved innlasting av nevnte første modul.38. System or terminal (1) according to claim 37, characterized in that said first module (72) includes a second exclusive list which indicates at least one other module from which at least one function is to be imported, and said loader (73 ) loads said at least one second module in accordance with said second list when loading said first module.

39. System eller terminal (1) eller intelligent kort (5) i-følge krav 38, karakterisert ved at nevnte første modul avsluttes hvis nevnte i det minste ene andre modul som skal importeres, ikke blir lastet inn vellykket.39. System or terminal (1) or intelligent card (5) according to claim 38, characterized in that said first module is terminated if said at least one second module to be imported is not loaded successfully.

40. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 37 til 39, karakterisert ved at nevnte middel til tildeling tildeler nevnte første mengde lesbart/skrivbart logisk-adresse-område ved innlasting av første modul og bare tildeler en andre eller ytterligere mengde lesbart/skrivbart logisk-adresse-område for nevnte første modul i en enkelt utvidbar buffer, idet den begynner med en første adresse; og ved frigjøring av nevnte andre mengde lesbart/skrivbart logisk-adresse-område gjennom første modul, fraordner nevnte fraordningsmiddel nevnte andre mengde lesbart/skrivbart logisk-adresse-område og alle videre tildelinger ut over nevnte første adresse.40. System or terminal (1) or intelligent card (5) according to any one of claims 37 to 39, characterized in that said means of allocation allocates said first amount of readable/writable logical address area when loading the first module and only allocating a second or additional amount of readable/writable logical-address space for said first module in a single expandable buffer, starting with a first address; and by releasing said second amount of readable/writable logical address area through the first module, said allocation means allocates said second amount of readable/writable logical address area and all further allocations beyond said first address.

41. System eller terminal (1) eller intelligent kort (5) ifølge krav 40, karakterisert ved at nevnte fraordningsmiddel fraordner nevnte mengde lesbart/skrivbart logisk-adresse-område og alle videre tildelinger ut over nevnte første adresse ved avslutning av nevnte første modul.41. System or terminal (1) or intelligent card (5) according to claim 40, characterized in that said allocation means allocates said amount of readable/writable logical address area and all further allocations beyond said first address at the end of said first module.

42. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 37 til 41, karakterisert ved at nevnte lesbare/skriv bare logisk-adresse-område innbefatter i det minst én database som innbefatter i det minste én post, nevnte modul innbefatter en angivelse av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul, og poster i nevnte database bare er tilgjengelige via nevnte modul; nevnte innlaster tildeler den nødvendige mengde ikke-initialisert logisk adresse/plass i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, hvor nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres av nevnte brukerprogram.42. System or terminal (1) or intelligent card (5) according to any one of claims 37 to 41, characterized in that said read/write only logical address area includes in it at least one database that includes at least one record , said module includes an indication of the amount of non-initialized readable/writable logical address area that is necessary for the execution of said module, and entries in said database are only accessible via said module; said loader allocates the required amount of uninitialized logical address/space in accordance with said specification; and means for accessing a record in said database, where said access means provides a window into a current record in said database and copies said record into a portion of said uninitialized readable/writable logical address area that can be addressed by said user program.

43. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av kravene 34 til 42, karakterisert ved at nevnte fraordningsmiddel sletter enhver mengde tildelt lesbart/skrivbart logisk-adresse-område ved avslutning av nevnte første modul.43. System or terminal (1) or intelligent card (5) according to any one of claims 34 to 42, characterized in that said de-allocation means deletes any amount of assigned readable/writable logical address area upon termination of said first module.

44. Transaksjonssystem til utførelse av transaksjoner mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5), karakterisert ved at nevnte system omfatter: en virtuell datamaskin (20) til tolking av et sett kundetilpassede bytekodesymboler anvendt på den; nevnte virtuelle datamaskin (20) innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste én database som innbefatter i det minste én post og i det minste ett dataprogram som skal utføres av nevnte virtuelle datama skin (20), idet nevnte dataprogram er en modul (72) skrevet i form av en strøm av nevnte symboler valgt fra nevnte sett og innbefattende en angivelse av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul; en innlaster til innlasting av nevnte modul og til tildeling av den nødvendige mengde ikke-initialisert logisk adresse/område i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, idet poster i nevnte database bare er tilgjengelige gjennom nevnte modul, og nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres av nevnte brukerprogram.44. Transaction system for carrying out transactions between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card (5), characterized in that said system comprises: a virtual computer (20 ) for interpreting a set of custom bytecode symbols applied thereto; said virtual computer (20) includes a virtual processor unit and readable/writable logical address space; at least one database which includes at least one record and at least one computer program to be executed by said virtual computer (20), said computer program being a module (72) written in the form of a stream of said symbols selected from said set and including an indication of the amount of uninitialized readable/writable logical-address space necessary for execution of said module; a loader for loading said module and for allocating the required amount of uninitialized logical address/area in accordance with said specification; and means for accessing a record in said database, records in said database being only accessible through said module, and said means of access providing a window into a current record in said database and copying said record into a batch of said uninitialized readable/writable logical address area that can be addressed by said user program.

45. Terminal som omfatter en første utstyrsenhet til utfø-relse av transaksjoner med en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5), karakterisert ved at nevnte første utstyrsenhet omfatter: en virtuell datamaskin (20) til tolking av et sett kundetilpassede bytekodesymboler anvendt på den; nevnte virtuelle datamaskin (20) innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste én database som innbefatter i det minste én post og i det minste ett dataprogram som skal utføres av nevnte virtuelle datamaskin (20) , idet nevnte dataprogram er en modul (72) skrevet i form av en strøm av symboler valgt fra nevnte sett og innbefattende en angivelse av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul; en innlaster (73) til innlasting av nevnte modul (72) og til tildeling av den nødvendige mengde ikke-initialisert logisk adresse/område i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, idet poster i nevnte database bare er tilgjengelige gjennom nevnte modul, og nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres gjennom nevnte brukerprogram.45. Terminal comprising a first equipment unit for carrying out transactions with a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card (5), characterized in that said first equipment unit comprises: a virtual computer (20) for interpreting a set of custom bytecode symbols applied thereto; said virtual computer (20) includes a virtual processor unit and readable/writable logical address space; at least one database which includes at least one record and at least one computer program to be executed by said virtual computer (20), said computer program being a module (72) written in the form of a stream of symbols selected from said set and including an indication of the amount of uninitialized readable/writable logical-address space necessary for execution of said module; a loader (73) for loading said module (72) and for allocating the necessary amount of uninitialized logical address/area in accordance with said specification; and means for accessing a record in said database, records in said database being only accessible through said module, and said means of access providing a window into a current record in said database and copying said record into a batch of said uninitialized readable/writable logical address area that can be addressed through said user program.

46. Selvstendig, bærbart intelligent kort (5) innbefattende én første utstyrsenhet til utførelse av en transaksjon med en andre utstyrsenhet, karakterisert ved at nevnte første utstyrsenhet omfatter: en virtuell datamaskin (20) til tolking av et sett kundetilpassede bytekodesymboler anvendt på den; nevnte virtuelle maskin innbefatter en virtuell prosessorenhet og lesbart/skrivbart logisk-adresse-område; i det minste én database som innbefatter i det minste én post og i det minste ett dataprogram som skal utføres av nevnte virtuelle datamaskin (20), idet nevnte dataprogram er en modul (72) skrevet i form av en strøm av symboler valgt fra nevnte sett og innbefattende en angivelse av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul; en innlaster for innlasting av nevnte modul og for tildeling av den nødvendige mengde ikke-initialisert logisk adresse/område i overensstemmelse med nevnte angivelse; og middel til tilgang til en post i nevnte database, idet poster i nevnte database bare er tilgjengelige gjennom nevnte modul, og nevnte tilgangsmiddel tilveiebringer et vindu inn til en aktuell post i nevnte database og kopierer nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres gjennom nevnte brukerprogram.46. Self-contained, portable intelligent card (5) comprising a first equipment unit for performing a transaction with a second equipment unit, characterized in that said first equipment unit comprises: a virtual computer (20) for interpreting a set of customized byte code symbols applied thereto; said virtual machine includes a virtual processor unit and readable/writable logical address space; at least one database containing at least one record and at least one computer program to be executed by said virtual computer (20), said computer program being a module (72) written in the form of a stream of symbols selected from said set and including an indication of the amount of uninitialized readable/writable logical-address space necessary for execution of said module; a loader for loading said module and for allocating the required amount of uninitialized logical address/area in accordance with said specification; and means for accessing a record in said database, records in said database being only accessible through said module, and said means of access providing a window into a current record in said database and copying said record into a batch of said uninitialized readable/writable logical address area that can be addressed through said user program.

47. System ifølge krav 44 eller terminal ifølge krav 45 eller intelligent kort (5) ifølge krav 46, karakterisert ved at nevnte database blir momentanvalgt ved første innlasting av nevnte modul (72) .47. System according to claim 44 or terminal according to claim 45 or intelligent card (5) according to claim 46, characterized in that said database is momentarily selected upon first loading of said module (72).

48. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av de foregående krav 1 til 47, karakterisert ved at nevnte virtuelle datamaskin (20) er en stakkmaskin.48. System or terminal (1) or intelligent card (5) according to any of the preceding claims 1 to 47, characterized in that said virtual computer (20) is a stack machine.

49. System eller terminal (1) eller intelligent kort (5) ifølge krav 48, karakterisert ved at nevnte virtuelle datamaskin (20) er i det minste en to-stakkers maskin, hvor første stakk er en datastakk (27) og andre stakk er en returstakk (28).49. System or terminal (1) or intelligent card (5) according to claim 48, characterized in that said virtual computer (20) is at least a two-stack machine, where the first stack is a data stack (27) and the second stack is a return stack (28).

50. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av de foregående krav 1 til 49, karakterisert ved at nevnte virtuelle datamaskin (20) innbefatter et lokalt variabelt rammeminne (46), et rammepekerregister til lagring av en rammepeker (34) som peker på rammestarten i minne og et rammeendepekerregister (35) som peker på rammeenden i minne.50. System or terminal (1) or intelligent card (5) according to any one of the preceding claims 1 to 49, characterized in that said virtual computer (20) includes a locally variable frame memory (46), a frame pointer register for storing a frame pointer (34) which points to the frame start in memory and a frame end pointer register (35) which points to the frame end in memory.

51. System eller terminal (1) eller intelligent kort (5) ifølge krav 49 eller 50, karakterisert ved at nevnte data- og returstakker (27, 28) ikke er i et minne som kan adresseres direkte av nevnte dataprogram, men bare er tilgjengelige via stakkeoperasjoner definert gjennom symboler og tolket av nevnte virtuelle datamaskin (20).51. System or terminal (1) or intelligent card (5) according to claim 49 or 50, characterized in that said data and return stacks (27, 28) are not in a memory that can be directly addressed by said computer program, but are only accessible via stack operations defined through symbols and interpreted by said virtual computer (20).

52. System eller terminal ifølge hvilket som helst tidligere krav, karakterisert ved at nevnte første utstyrsenhet er en håndholdt enhet.52. System or terminal according to any previous claim, characterized in that said first equipment unit is a hand-held unit.

53. System eller terminal ifølge krav 52, karakterisert ved at nevnte håndholdte enhet innbefatter et ICC (Integrated Circuit Card/integrert-krets-kort) (5).53. System or terminal according to claim 52, characterized in that said hand-held unit includes an ICC (Integrated Circuit Card) (5).

54. System eller terminal ifølge hvilket som helst av kravene 1 til 53, karakterisert ved at nevnte andre utstyrsenhet omfatter et ICC (5) .54. System or terminal according to any one of claims 1 to 53, characterized in that said second equipment unit comprises an ICC (5).

55. System ifølge hvilket som helst foregående krav 1 til 54, karakterisert ved at nevnte første utstyrsenhet er en terminal (1).55. System according to any preceding claim 1 to 54, characterized in that said first equipment unit is a terminal (1).

56. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst av de foregående krav 1 til 55, karakterisert ved at både nevnte første og andre utstyrsenhet innbefatter ICC-er (5).56. System or terminal (1) or intelligent card (5) according to any of the preceding claims 1 to 55, characterized in that both said first and second equipment units include ICCs (5).

57. System eller terminal (1) eller intelligent kort (5) i-følge hvilket som helst foregående krav 1 til 56, karakterisert ved at transaksjonen omfatter i det minste én utførelse av følgende sekvens: a. opprettelse av kommunikasjonslenke mellom nevnte første og andre utstyrsenhet; b. valg av en anvendelse som innbefatter nevnte dataprogram og det tilknyttede datasett som definerer transaksjonen; c. • utførelse av nevnte anvendelse; og d. avslutning av transaksjonen.57. System or terminal (1) or intelligent card (5) according to any preceding claim 1 to 56, characterized in that the transaction includes at least one execution of the following sequence: a. creation of a communication link between said first and second equipment unit; b. selecting an application that includes said computer program and the associated data set that defines the transaction; c. • execution of said application; and d. closing of the transaction.

58. System eller terminal (1) eller intelligent kort (5) ifølge hvilket som helst foregående krav 1 til 57, karakterisert ved at transaksjonen er en finansiell transaksjon, og nevnte system er et hånd-teringssystem for finansielle transaksjoner.58. System or terminal (1) or intelligent card (5) according to any preceding claim 1 to 57, characterized in that the transaction is a financial transaction, and said system is a handling system for financial transactions.

59. Integrert-krets-kort karakterisert ved at det inneholder en programinstruksjon som er i stand til å modifisere oppførselen for et program som kjøres i systemet ifølge hvilket som helst av kravene 1 til 58, i en terminal (1) ifølge hvilket som helst av kravene 2 til 58 eller et intelligent kort (5) ifølge hvilket som helst av kravene 3 til 58.59. Integrated circuit card characterized in that it contains a program instruction capable of modifying the behavior of a program executed in the system according to any of claims 1 to 58, in a terminal (1) according to any of claims 2 to 58 or an intelligent card (5) according to any of claims 3 to 58.

60. Fremgangsmåte for utførelse av en transaksjon mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5); karakterisert ved at fremgangsmåten omfatter tilveiebringelse av i det minste én programinstruksjon i nevnte andre utstyrsenhet, hvilken er i stand til i det minste å modifisere oppførselen på utførelsestidspunktet for et dataprogram i nevnte første utstyrsenhet; innlasting og tolking av nevnte dataprogram, hvorved nevnte i det minste ene programinstruksjon blir lastet inn og tolket avhengig av en forhåndsdefinert sikkerhetsbetingelse mens nevnte dataprogram kjøres; og utførelse av nevnte innlastede og tolkede dataprogram med nevnte modifiserte oppførsel som svar på nevnte innlastede og tolkede programinstruksjon.60. Method for carrying out a transaction between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card (5); characterized in that the method comprises the provision of at least one program instruction in said second equipment unit, which is capable of at least modifying the behavior at the time of execution of a computer program in said first equipment unit; loading and interpreting said computer program, whereby said at least one program instruction is loaded and interpreted depending on a predefined security condition while running said computer program; and executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

61. Fremgangsmåte for utførelse av en transaksjon mellom en første utstyrsenhet og en andre utstyrsenhet, karakterisert ved at fremgangsmåten omfatter: tolking av i det minste ett brukerprogram skrevet som en strøm av bytekodesymboler valgt fra et sett av symboler og motsvarende innebygde data; innlasting av nevnte i det minste ene brukerprogram; tildeling av en første mengde lesbart/skrivbart logisk-adresse-område spesifikt for nevnte i det minste ene brukerprogram i overensstemmelse med en i nevnte brukerprogram inneholdt angivelse av den mengde lesbart/skrivbart logisk-adresse-område som behøves for dets utførelse; og defi-nering og beskyttelse av grensene for nevnte tildelte lesbare/skrivbare logisk-adresse-område.61. Method for performing a transaction between a first equipment unit and a second equipment unit, characterized in that the method comprises: interpreting at least one user program written as a stream of byte code symbols selected from a set of symbols and corresponding embedded data; loading said at least one user program; allocation of a first amount of readable/writable logical address area specifically for said at least one user program in accordance with an indication contained in said user program of the amount of readable/writable logical address area needed for its execution; and defining and protecting the boundaries of said allocated readable/writable logical address area.

62. Fremgangsmåte ifølge krav 61, karakterisert ved at den videre omfatter uttrykkelig fraordning av nevnte første mengde lesbart/skrivbart logisk-adresse-område ved avslutning av nevnte i det minste ene første brukerprogram.62. Method according to claim 61, characterized in that it further comprises express de-ordering of said first amount of readable/writable logical address area upon termination of said at least one first user program.

63. Fremgangsmåte for utførelse av et transaksjonssystem mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort (5), karakterisert ved at fremgangsmåten innbefatter: tolking av symbolene i en modul (72) skrevet i form av en strøm av nevnte symboler valgt fra et symbolsett; tildeling av en mengde ikke-initialisert logisk adresse/område i overensstemmelse med en angivelse i nevnte modul av den mengde ikke-initialisert lesbart/skrivbart logisk-adresse-område som er nødvendig for utførelse av nevnte modul (72); tilgang til en post i en database gjennom tilveiebringelse av et vindu inn til en aktuell post i nevnte database, idet poster i en database bare er tilgjengelige gjennom nevnte modul; og kopiering av nevnte post inn i et parti av nevnte ikke-initialiserte lesbare/skrivbare logisk-adresse-område som kan adresseres via nevnte modul.63. Method for implementing a transaction system between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card (5), characterized in that the method includes: interpreting the symbols in a module (72) written in the form of a stream of said symbols selected from a symbol set; allocation of an amount of uninitialized logical address/area in accordance with an indication in said module of the amount of uninitialized readable/writable logical address area necessary for execution of said module (72); access to a record in a database through the provision of a window into a current record in said database, records in a database being only accessible through said module; and copying said record into a portion of said non-initialized readable/writable logical address area that can be addressed via said module.

64. Fremgangsmåte for utførelse av en transaksjon mellom en første utstyrsenhet og en andre utstyrsenhet, hvor i det minste én av nevnte første og andre utstyrsenhet er et integrert-krets-kort ('5) , karakterisert ved at fremgangsmåten, omfatter: tilveiebringelse av en bærbar virtuell datamaskin (20) som omfatter en virtuell mikroprosessor og en driver for i det minste én inn/utenhet; tolking av et dataprogram i nevnte første utstyrsenhet ved bruk av nevnte bærbare virtuelle datamaskin (20); og utførelse av nevnte program som svar på nevnte tolkede program.64. Method for carrying out a transaction between a first equipment unit and a second equipment unit, where at least one of said first and second equipment units is an integrated circuit card ('5), characterized in that the method includes: provision of a portable virtual computer (20) comprising a virtual microprocessor and a driver for at least one input/output device; interpreting a computer program in said first equipment unit using said portable virtual computer (20); and executing said program in response to said interpreted program.