NO985803L

NO985803L - Bµrbart, sikkert transaksjonssystem for programmerbare, intelligente utstyrsenheter

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: HUP0001822A3; SI9720049A; TR199802675T2; AU3263097A; EA199900060A1; BR9710009A; PL330930A1; GB9613450D0; EP0907936A2; CZ423598A3; TW355776B; HRP970354A2; ZA975748B; IL127533A0; NZ333384A; NO985803D0; WO1997050063A3; AU716558B2; SK176698A3; CA2257641A1

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.

Description

BÆRBART, SIKKERT TRANSAKSJONSSYSTEM FOR PROGRAMMERBARE, INTELLIGENTE UTSTYRSENHETER

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 .

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.

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.

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

som inneholder tolkeprogrammet, og gjør derfor transaksjonen

uavhengig av vertsprosessoren i terminalen. Det er imidlertid ikke beskrevet noen fremgangsmåte for sikkerhetskontroll for å utelukke potensielt farlige underrutiner.

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++.

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.

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 .

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.

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.

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.

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.

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.

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.

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.

Det er å foretrekke dersom den bærbare virtuelle datamaskin er en stakkmaskin, da dette gir kjørehastighet og kompakthet.

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.

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.

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.

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.

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.

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

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.

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.

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.

Videre kan den herværende oppfinnelse også tilveiebringe en

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-

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

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.

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.

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.

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.

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.

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.

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.

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.

Vedlegg gir symbolkodene og standardunntakssituasjonene.

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.

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.

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

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

være ett eller flere vedlikeholdskort som kan benyttes til oppdatering av anvendelsene lagret i terminalen 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.

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.

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.

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.

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.

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.

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.

(DIOCTL) tillater terminal-avhengige aspekter ved I/O-enheter å defineres som innebygde funksjoner.

Terminal valgte tjenester (TSS) innbefatter anvendelser slik som betalingstjenestefunksjoner og biblioteker som støtter

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.

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).

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

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.

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).

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.

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.

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

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.

I overensstemmelse med den herværende oppfinnelse er det bare én data- og returstakk 27, 28 tilknyttet VM-en 20. Data- og

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

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.

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.

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.

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.

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.

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.

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.

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.

3. Rammeminne 4 6 som håndteres av rammesymbolene.

4. Valgfritt: utvidbart minne 45, som inneholder én eller flere buffere som er tildelt dynamisk under programutfø-relse.

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.

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.

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.

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.

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

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.

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

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.

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.

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 å

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

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.

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.

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:

"Flyktige" databaser hvis innhold ikke behøver bevares mellom modulinnlastinger eller over en strømutkopling i terminalen 1 hvor databasen befinner seg.

"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.

"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.

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.

- 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

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.

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.

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.

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

"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ø-

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.

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.

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.

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.

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.

Etikett En to bytes streng, hvis numeriske verdi i stor-enden er TLV-etiketten.

Type En enkelt byte som angir styringsinformasjon.

Reservert En byte som må initialiseres til null av kompilatoren 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 .

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.

Dataene tilordnet en TLV-definisjon blir utlagt for bruk

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.

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.

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:

resultat = 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.

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:

resultat = 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-

ende-byteorden.

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).

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.

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.

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 .

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.)

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.

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.

Å 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-

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

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.

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.

En modul som ønsker å begrense tilgang til hvilke kontakter

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

(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.

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.

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.

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 :

- kode som symboler

- initialiserte data

- ikke-initialisert datatildeling

- databasedefinisjoner

- TLV-definisjoner

- kontaktliste

- modulers innbyrdes avhengighet

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.

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.

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:

- Posisjonen for utvidbart-minne-pekeren, rammepekeren,

og rammeendepekeren.

- Innholdet i hele den gjeldende kontaktliste.

- TLV-ene registrert i TLV-etikettnavnelisten.

- Andre interne data som VM-implementeringen trenger for å håndtere aktiveringen og utføringen av moduler.

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

disse moduler.

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

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.

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.

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.

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.

- Innholdet i hele den gjeldende kontaktliste.

- TLV-ene registrert i TLV-etikettnavnelisten.

- Andre interne data som VM-implementeringen behøver for å styre aktiveringen av kortmoduler.

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.

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

umiddelbart før modulutførelse.

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.

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.

VEDLEGG

1. Symboldefinering

1.1 Oversikt

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.

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.

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.

1.1.1 Forth-funksjoner for EPICode-symboler

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;

- Spesielle betegnelser, etter behov

A ANS Forth ord (innbefattet alle valgfrie

ordsett)

C Kompilatordirektiv; må brukes inne i en

definisjon

G Generisk Forth ord (i vanlig bruk, f.eks.

Forth Interest Group, men ikke i ANS Forth).

H Verts(kompilator)ord, som både kan og ikke kan bidra med symboler til målet.

- Likeverdig(e) EPICode-symbol(er)

1.2 Regler

1.2.1 Nummerformater

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.

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.

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

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).

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.

1.2.3 Adresser

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.

1.3 Datatypifisering

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.

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.

Tabell 1: Datatypeprefikser

1.4 Aritmetikk

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.

Lagreoperasjoner hvis mållager er mindre enn størrelsen på den overførte verdi, vil lagre verdien avkuttet til målområ-dets bredde.

Divisjonsoperasjoner er symmetriske; dvs, avrunding skjer alltid mot null uansett tegn.

1.5 Primærsymboler

Symboler blir inndelt i flere logiske sett av bekvemmelig-hetshensyn og er vist i separate avsnitt nedenfor. Alle sym-bolverdier er i heksadesimal.

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.

1.5.1 Operasjonssett

00 NOOP

( )

Ingen handling iverksatt.

04 BFETCHS

( addr - num )

Hent en 8 biters byte fra den gitte adresse, hvor tegn forlenger den.

08 LIT

f -x ;

Returner cellen som følger i rekken, som da-ta.

09 LITC

( - 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.

OA LITD

( - 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 .

OB LITU

( - 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.

0C PLIT

( -u ;

Returner den byte som følger i rekken. Byten blir nullutvidet til 32 biter.

OD NLIT

( — num )

Returner den byte som følger i rekken, nullutvidet til 32 biter og deretter negert.

OE HLIT

( - u )

Returner 2-bytesverdien som følger i rekken. Verdien er nullutvidet til 32 biter.

10 HLITC

( - 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.

11 SLITD

( 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.

12 HLITD

( - 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.

13 SLITU

( - 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.

14 HLITU

( - 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.

15 ADDLIT

( Xi- X2 )

Legg dataene i cellen som følger i rekken, til Xi, hvilket gir x2.

16 SADDLIT

( Xj- X? )

Legg en litteral fra den fortegnsbestemte énbytesverdi som følger i rekken, til Xi, hvilket gir x2.

19 SUBLIT

( x,-x?;

Trekk dataene i cellen som følger i rekken, fra Xi, hvilket gir x2.

IA SSUBLIT

(X/—x?-t )

Trekk den fortegnsbestemte énbytesverdi i rekken fra Xi, hvilket gir x2.

1C VSUBLIT

( d - d lit )

Trekk den fortegnsbestemte åttebytesverdi i rekken fra dobbeltnummeret d.

ID SMULLIT

( num — num* lit )

Multipliser num med den fortegnsbestemte énbyteslitteral som følger i rekken.

1E SDIVLIT

( num — num/ lit )

Divider num med den fortegnsbestemte énbyteslitteral som følger i rekken.

21 DIVU

( U/U - u3)

Divider u; med u? (ikke-fortegnsbestemt), hvilket gir u3.

3A SHRU

( u - u»l)

Logisk skift u høyre én bit, idet det settes inn en null-bit.

NB: SETxx-operatørene utfører en sammenligning med null, hvor flagget settes opp alt etter resultatet av denne sammenligning.

42 SETGE

( num - flag )

Returner TRUE (korrekt) dersom num > 0 (fortegnsbestemt).

45 SETLE

( num - flag )

Returner TRUE hvis num < 0 (fortegnsbestemt) .

4 8 CMPGEU

( u.Uj- flag )

Sammenlign de ikke-fortegnsbestemte verdierUjogUo og returner TRUE dersom ui<>>u2.

4C CMPGE

( nummum?— flag )

Sammenlign de fortegnsbestemte verdier num;

og num? og returner TRUE hvis numi> num2.

4 F CMPLE

( numinum2- flag )

Sammenlign de fortegnsbestemte verdier num;

og num? og returner TRUE hvis numj< num2.

Følgende symboler gir tilgang til rammelageret.

50..53 PFRFETCH2...PFRFETCH5

( — num )

Kortformekvivalenter av SFRFETCHn (s.d.), hvor n er 2..5. Mulige datatypeoverstyringer innbefatter: SL, SB, UB.

54..5F TFRFETCH12...TFRFETCH1

( — num )

Kortformekvivalenter av SFRFETCHn (s.d.), hvor n er -12..-1. Mulige datatypeoverstyringer innbefatter: SL, SB; UB

60.. 63 PFRSTORE2...PFRSTORE5

( - num )

Kortformekvivalenter for SFRSTORE n (s.d.), hvor n er 2..5. Mulige datatypeoverstyringer innbefatter: SL, SB

64..6F TFRSTORE12...TFRSTORE1

( num — )

Kortformekvivalenter for SFRSTORE n (s.d.), hvor n er -12..-1. Mulige datatypeoverstyringer innbefatter: SL, SB

7 0 SFRFETCH

( — 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

71 SFRSTORE

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

SL, SB.

7 2 FRFETCH

( num )

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.

7 3 FRSTORE

( 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.

7 4 SFRADDR

( - 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

75 FRADDR

( - 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.

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.

8C UNDER

( X1X2—XiXiX2)

Dupliker det andre element i stakken.

9C ZERO

( - 0 )

La verdien 0 være igjen i stakken.

9D ONE

( - 1 )

La verdien 1 være igjen i stakken.

9E MINUSONE

( - - 1 )

La verdien -1 være igjen i stakken.

AO INDEX

( addrLnum addr2)

Multipliser num med 4 og legg addr} til gitt addr2.

A2 EDOCREATE

( — 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.

A3 EDOCLASS

( 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.

A4 DOCREATE

( - 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 .

A5 DOCLASS

( — 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.

A6 ECALL

( )

Etterfulgt av en celle i rekken, kaller opp prosedyren som benytter denne celle som en fortegnsbestemt byte-adressedifferanse inn til kodeområde.

A7 SCALL

( )

Etterfulgt av en byte i rekken, kaller opp den prosedyre som benytter denne byte som en fortegnsbestemt byte-adressedifferanse inn til kodeområde.

A8 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.

AB SMAKE FRAME

( 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.

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.

Dersom det ikke er mulig å bygge en ramme av den ønskede størrelse, vil det bli fremsatt en FRAME_STACK_ERROR (rammestakkefeil).

AC MAKEFRAME

( 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

SMAKEFRAME for ytterligere detaljer.

AD RELFRAME

(<->)

Tilbakefør rammepekeren til dens tidligere verdi og frigjør den aktuelle ramme.

1.5.2 Grensett

Disse symboler innbefatter de vanlige stakkmaskin-grenoperatører pluss kjøretidene for Forth-ordene DO ?D0 LOOP +LOOP LEAVE I og J.

AF EBRA

(<->)

Forgren hver gang. Fire-bytes adressedifferanse i rekken.

BO EBZ

( num — )

Forgren hvis num = 0. Fire-bytes adressedifferanse i rekken.

Bl EBNZ

( num — )

Forgren hvis num 0. Fire-bytes adressedifferanse i rekken.

B2 SBRA

(<->)

Kort forgrening. Fortegnsbestemt byte-adressedif f eranse .

B3 SBZ

(num —)

Kort forgrening hvis num = 0. Fortegnsbestemt byte-adressedifferanse.

B4 SBNZ

( num — )

Kort forgrening hvis num * 0. Fortegnsbestemt byte-adressedifferanse.

B5 BRA

(<->)

Ubetinget forgrening. Fortegnsbestemt toby-tes adressedifferanse.

B7 BNZ

( num — )

Forgren hvis num * 0. Fortegnsbestemt toby-tes adressedifferanse.

1.5.3 Datatype- og kodesideoverstyringer

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.

Cl SBYTE

( )

Fortegnsbestemt byte.

C2 UBYTE

r -

Ikke-fortegnsbestemt byte.

C5 SLONG

( )

Lang fortegnsbestemt, 32 biter.

C6 ULONG

( )

Lang ikke-fortegnsbestemt, 32 biter.

1.5.4 Kontakthåndteringssyrnboler

D2 DOSOCKET

(

Etterfulgt av en byte (0..63) i rekken, hvilken angir det nødvendige funksjonsnummer. Stakkeeffekten bestemmes av funksjonen knyttet til kontakten.

D3 IDOSOCKET

( 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.

1.5.5 Kontrollsett

E6 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.

E7 CLASSPROC

( )

Under innlasting markerer CLASSPROC inngan-gen til klassehåndteringskode. Benyttes til kompileringsbistand og kan implementeres som en NOOP.

F9 SYSFUNC

( )

Et sideutvidelsestegn behandlet som den før-ste byte i et sekundært symbol. Kaller opp

ken. Det støttede sekundær-symbolsett er å

finne i avsnitt 1.7. Stakkeeffekten bestem-

mes gjennom den angitte rutine.

1.6 Kontakter

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.

F9 91 SETSOCKET

( 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-

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-

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.

D2 00 SETPLUGCONTROL

( xp - )

Lagrer utførelsespekeren xp for en bruker-skrevet prosedyre som vil bli kjørt av SETSOCKET for å fastslå om kontakten kan plugges.

Handlingen i denne prosedyre (som her kalles PLUGCONTROL for illustrasjonsformål) må væ-

re :

( 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.

En standardhandling for PLUGCONTROL er installert gjennom den Virtuelle Maskin for å returnere FALSE for alle verdier av u, hvorved alle kontakter tillates plugget.

D2 03 OSCALLBACK

( 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.

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).

D2 04 EPICALLBACK

( 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.

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.

1.7 SYSFUNC inn/ut-sett

Dette sett definerer funksjonene som er tilgjengelige via SYSFUNC-symbolet, hvilket virker som et grensesnitt som er gjort generelt for underliggende operativsystemrutiner.

1.7.1 Enhetstilgang

Hver enhet er tilordnet et eget enhetsnummer. Status ior-koder er enhetsavhengige, bortsett fra at en ior-kode 0 alltid indikerer vellykket.

F9 00 DKEY

( dev — echar )

Les et tegn fra innenhet dev.

F9 01 DKEYTEST

( dev - flag )

Returner TRUE hvis et tegn er klar til å le-

ses fra innenhet dev.

F9 02 DEMIT

( char dev )

Overfør char til utenhet dev.

F9 03 BEEP

( 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.

F9 04 DREAD

( 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.

F9 05 DWRITE

( addr len dev — ior )

Skriv en streng til utenhet dev, hvorved det returneres en enhetsavhengig ior.

F9 0 6 DSTATUS

( 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.

F9 07 DIOCTL

( 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.

F9 08 OUTPUT

( 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

OUTPUT.

F9 09 DWRITESTRING

( 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.

F9 OA GETOP

( - 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.

F09 OB SETOP

{ 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.

F9 OC FORMFESD

( dev - )

Utfører en enhetsavhengig "nytt ark"-handling slik som "slett skjermbilde" (terminaldis-play) eller "ny side" (skriver) på enhet dev.

F9 OD CR

( dev - )

Utfører en enhetsavhengig "ny linje"-handling på enhet dev.

F9 OE SETXY

( numinum2dev )

Utfører en enhetsavhengig "sett absoluttposi-sjon"-handling på enhet dev ved å benytte num!som x-ordinaten og num2som y-ordinaten.

1.7.2 Tidshåndtering

Standard Forth-ord.

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.

F9 20 CHOOSELANG

( 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.

F9 21 CODEPAGE

( 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.

F9 22 LOADPAGE

( 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 .

F9 23 INITMESSAGES

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.

F9 24 LOADMESSAGES

( 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 .

F9 25 GETMESSAGE

(num — c-addr len)

Returnerer strengparametere for melding-num. Etterhengende mellomromstegn fjernes fra strengens lengde Jen.

F9 27 UPDATEMESSAGES

( 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.

F9 28 MESSAGESIZE

( - len )

Returnerer standard meldingslengde for denne terminal.

F9 2 9 TYPEMESSAGE

( addr len — )

Skjermviser den gitte streng i terminalens me1dings1inj e.

1.7.4 Håndtering av ICC-kort

Symboler i denne gruppen tilveiebringer en mekanisme til håndtering av lesere for kort med integrerte kretser (ICC).

F9 30 INITCARD

( num — ior )

Velger ICC-leser-num, hvor num er 0 eller 1.

F9 31 CARD

( 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.

Bufferen c- addri leni må inneholde:

Fire-bytes standard ISO-hode (Klasse, Instruksjon, Pl, P2) .

Valgfrie data ( lengde etterfulgt av lengdebyte, hvor lengde kan være 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.

F9 32 CARDON

( 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.

F9 33 CARDOFF

(<->)

Slå av strømmen på ICC. Dette utføres når al-le transaksjoner er fullført.

F9 34 CARDABSENT

( - flag )

Returner TRUE hvis det ikke er et ICC-kort i leseren, ellers returneres FALSE.

1.7.5 Magnetstripehåndtering Symboler i denne gruppe tilveiebringer en mekanisme til håndtering av magnestripeenheter.

F9 38 FROMMAG

( 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.

F9 39 TOMAG

( 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.

1.7.6 Modemhåndtering

Symboler i denne gruppe tilveiebringer en mekanisme for håndtering av modemenheten.

F9 4 0 MODEMCALL

( numinum2num3num^num5C-addr len — ior )

Kaller opp et nummer som bruker et internt terminalmodem.

numiog num? angir den inn- og ut-linjehastighet som skal benyttes (fra 75 til 19200 baud). De faktiske støttede hastigheter er implementeringsbestemt.

num3angir paritet (0 = ingen, 1 = ulik, 2 = lik) .

nvni4angir antall biter som skal benyttes (7 eller 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.

F9 41 MODEMHANGUP

( - ior )

Denne funksjon benyttes til å avslutte den pågående modemøkt.

F9 42 TOMODEM

( c-addr len - ior )

Send strengen i c- addr len i en opprettet mo-demøkt .

F9 4 3 FROMMODEM

( 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.

F9 4 4 MODEMBREAK

( - ior )

Denne funksjon sender et brudd i den oppkop-lede modemøkt.

1.7.7 Håndtering av svarteliste

Symboler i denne gruppe tilveiebringer en mekanisme for å håndtere svartelistefilen.

F9 48 INITBLACKLIST

r -

Denne funksjon initialiserer svartelisten til tom tilstand.

F9 49 BLACKLISTINSERT

( c-addr len — flag )

Denne funksjon setter inn en oppføring i c-addr len i listen, hvilken opprettholdes i sortert orden.

Denne funksjon må benyttes ved oppdatering av listen.

Det returnerte flag er FALSE hvis oppføringen var vellykket (oppføringen ikke ble funnet i den eksisterende liste, og listen ikke var full).

F9 4A INBLACKLIST

( 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.

Det returnerte flag er FALSE hvis nummeret

ble funnet.

F9 4B BLACKLISTDELETE

( c-addr len — flag )

Denne funksjon sletter en oppføring i listen

hvor c- addr len er nøkkelen til den oppføring som skal slettes. Den kan være opptil 18 byte lang.

Det returnerte flag er FALSE hvis slettingen

var vellykket (oppføringen ble funnet).

1.7.8 Støtte for sikkerhetsalgoritmer

Symboler i denne gruppen gir støtte til initialisering og bruk av sikkerhetstjenester.

F9 50 INITSECALGO

( c-addr len num - flag )

c- addr er adressen til initialiseringsbuffer,

og len er dens lengde. Inn-parameteren (-parametrene) for hver algoritme kan varie-

re, men en nøkkel skal vanligvis overføres til denne initialisering. flag er FALSE hvis initialisering var vellykket.

F9 51 SECALGO

( 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.

flag er FALSE hvis behandling foregikk vellykket.

1.7.9 Terminal tjenester

F9 58 POWERLESS

( - flag )

Returnerer FALSE hvis det er nok strøm til å fullføre den pågående transaksjon.

1.7.10 Databasetjenester

Nedenstående symboler tilveiebringer en mekanisme til håndtering av databaser.

F9 61 DBMAKECURRENT

( a- addr — )

Lag databasen hvis DPB er i a- addr i den aktuelle database.

F9 62 DBSIZE

( - len )

Returnerer størrelsen på postbufferen som tilveiebringer vinduet inn til den aktuelle post i den aktuelle database.

F9 63 DBFETCHCELL

( num, — num?)

Returnerer 32-biters verdien num?fra cellen i den celleinnrettede byte-adressedifferanse numii den aktuelle post i den aktuelle database .

F9 64 DBFETCHBYTE

( num — char )

Returnerer én-bytesverdien char fra byte-adressedif f eransen num i den aktuelle post i den aktuelle database.

F9 65 DBFETCHSTRING

( 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.

F9 66 DBSTORECELL

( numinum?— )

Lagrer 32-bit-verdien numii cellen i den celleinnrettede adressedifferanse num?i den aktuelle post i den aktuelle database og oppdaterer databaseposten.

F9 67 DBSTOREBYTE

( char num - )

Lagrer 1-byte-verdien char! inntil byten i adressedifferanse num i den aktuelle post i den aktuelle database og oppdaterer databaseposten .

F9 68 DBSTORESTRING

( addr leni num len2— )

Lagrer høyst len^-byte av bytesekvensen i

addr inntil adressedifferanse-num i den aktu-

elle post i den aktuelle database og oppdate-

rer databaseposten. Hvis leni er mindre enn len2lblir målet i databasepostbufferen fylt med mellomromstegn til len2.

F9 69 DBINITIALIZE

(<->)

Initialiserer den aktuelle database til bare nuller og setter "aktuelle" og "tilgjengelige" postnummer i databasen (se DBRECNUM og DBAVAIL) til 0.

F 9 6A DBRECNUM

( - U )

Returnerer det aktuelle postnummer.

F9 6B DBCAPACITY

( - u )

Returnerer det totale antall poster som den aktuelle database kan inneholde.

F9 6C DBAVAIL

( - num )

Returnerer postnummeret for den neste tilgjengelige post i den aktuelle fil.

F9 6D DBADDREC

(<->)

Legg en post i slutten av den aktuelle database til postnummeret gitt av DBAVAIL.

F9 6F DBSELECT

( num — )

Velg post-num i den for øyeblikket valgte database.

F9 7 0 DBMATCHBYKEY

( 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.

Dette symbol kan bare brukes med en Ordered (bestilt) database .

F9 71 DBADDBYKEY

( 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.

Dette symbol kan bare benyttes med en Ordered (bestilt) database .

F9 72 DBDELBYKEY

( 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.

F9 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.

F9 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.

1.8 TLV-håndtering

Symbolene beskrevet i dette avsnitt tilveiebringer TLV-håndtering og tilgangsfunksjon.

1.8.1 Støtte til strengbehandling

F9 78 PLUSSTRING

( 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.

F9 79 CPLUSSTRING

( 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.

F9 7A MINUSTRAILING

( 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.

F9 7B MINUSZEROS

( 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.

F9 7C STORECOUNT

( 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.

1.8.2 Tilgang til TLV-buffer

F9 8 0 TLV

( num — c-addr len fmt )

Returner tilgangsparametrene for den TLV hvis etikett er num. Dette kan generere en unntakssituasjonskode UNDEFINED_TLV (ikke definert TLV).

F9 81 TLVFETCH

( 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.

F9 82 TLVSTORE

( 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.

F9 83 TLVBITFETCH

( 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.

F9 84 TLVBITSTORE

( 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å.

1.8.3 TLV-behandling

F9 8 5 PARSETLV

( 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.

F9 8 6 PLUSDOL

( 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.

P9 87 PLUSTLV

( 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.

F9 8 9 TLVSTATUS

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

1.8.4 TLV-sekvenstilgang

F9 8A STOREBCD

( 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.

F9 8B FETCHBCD

( 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.

F9 8C STOREBN

( 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.

F9 8D FETCHBN

( 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.

F9 8E STORECN

( 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.

F9 8F FETCHCN

( 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.

F9 90 TLVFETCHNAME

( c-addri— 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.

F9 91 TLVFETCHLENGTH

( 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.

1.9 Modulhåndtering

Nedenstående symboler gir rom for lagring og utførelse av EPICode-moduler i den virtuelle datamaskin.

F9 AO EXECUTEMODULE

( c-addr len — flag )

Last inn en modul fra modulkatalogen ved å benytte AID-en angitt gjennom c- addr len. Unntakssituasjonen

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".

F9 Al INITMODULEBUFFER

(<->)

Gjør klar for innhenting av en ny modul.

F9 A2 MODULEBUFFERAPPEND

( c-addr len — )

Føy innholdet i bufferen angitt gjennom c- addr og Jen til modul innhent ingsbu f f er en . Unntakssituasjon

CANNOT_ADD_T0_M0DUL (kan ikke tilføye til modul) blir fremsatt hvis modulbufferen ikke er blitt klargjort, eller hvis modulbufferens kapasitet er overskredet.

F9 A3 REGISTERMODULE

( 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.

F9 A4 RELEASEMODULEBUFFER

(<->)

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 .

F9 A5 DELETEMODUL

( c-addr len — flag )

Slett modulen hvis AID er angitt gjennom c- addr len, fra mo-dulregisteret. fiag er null hvis operasjonen var vellykket.

F9 A6 MODULEINFO

( 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.

F9 A7 LOADCARDMODULE

( 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.

F9 A8 MODULESCHANGED

( - 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 .

1.10 Håndtering av utvidbart minne

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.

F9 BO EXTEND

( 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.

F9 Bl BEXTEND

( 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.

F9 B2 RELEASE

( 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).

Ytterligere symboler:

F9 BO DSCHECK

( u - flag ) Kontroller at det i det minste finnes u

dataceller igjen i datastakken. Returner

FALSE hvis dette er tilfellet, ellers TRUE.

F9 Bl RSCHECK

( u - flag )

Kontroller at det i det minste finnes u

dataceller igjen på returstakken. Returner FALSE hvis dette er tilfellet, ellers TRUE.

1.11 Sikkerhetskommandoer

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.

F9 56 SECALGOBEGIN

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

Dette behandler data ved bruk av algoritmen

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

hvis databehandling kan med hell innledes.

F9 57 SECALGOEND

(- ior)

Denne funksjon returnerer en ior som viser:

0 = databehandling vellykket gjennomført; -1 = databehandling pågår; 1 = databehandling mislykket.

Unntakssituasjonskoder

Dette avsnitt innbefatter alle koder som benyttes som påstander for standardfunksjonen THROW for unntakssituasjonshåndte-ring.

Følgende tabell viser ANS-Forth-kodene benyttet i EPIC-kj erner.

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.

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.

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) .

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.

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.

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.

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.

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.

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.

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.

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.

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) .

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.

14. System eller terminal (1) eller intelligent kort (5) ifølge krav 13, karakterisert ved at nevnte sikkerhetsbetingelse er tilveiebrakt gjennom en funksjon.

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.

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.

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

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 .

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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) .

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.

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).

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.

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).

52. System eller terminal ifølge hvilket som helst tidligere krav, karakterisert ved at nevnte første utstyrsenhet er en håndholdt enhet.

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).

54. System eller terminal ifølge hvilket som helst av kravene 1 til 53, karakterisert ved at nevnte andre utstyrsenhet omfatter et 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).

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).

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.

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.

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.

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.

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.

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.

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.

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.