(12) United States Patent
`US 6,934,945 B1
`(10) Patent N0.:
`
` Ogilvy (45) Date of Patent: Aug. 23, 2005
`
`
`USOO6934945B1
`
`(54) METHOD AND APPARATUS FOR
`CONTROLLING COMMUNICATIONS
`
`(75)
`
`Inventor:
`
`Ian Charles Ogilvy, Manly (AU)
`
`(73) Assignee: Cardsoft, Inc., San Mateo, CA (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`AU
`EP
`EP
`WO
`
`W0
`W0
`
`.......... 717/139
`6,308,317 B1 * 10/2001 Wilkinson et al.
`FOREIGN PATENT DOCUMENTS
`
`2200088
`0456249
`0634718
`9212480
`
`9/1988
`11/1991
`1/1995
`7/1992
`
`3/1993
`9305599
`5/1994
`9410628
`OTHER PUBLICATIONS
`
`(21) Appl. No.:
`
`09/381,143
`
`(22) PCT Filed:
`
`Mar. 16, 1998
`
`(86) PCT No.:
`
`PCT/AU98/00173
`
`§ 371 (C)(1),
`(2), (4) Date: Oct. 22, 1999
`
`(87) PCT Pub. No.: WO98/41918
`
`PCT Pub. Date: Sep. 24, 1998
`
`(30)
`
`Foreign Application Priority Data
`
`Kiran Kumar Toutireddy, “A Testbed for Fault Tolerant
`Real—Time Systems”, Sep. 1996, pp. 1—120.*
`Ray Hookway, “Digital FXi32”, Feb. 1997,
`37—42.*
`
`IEEE, pp.
`
`Hamilton, “Java and the Shift to Net—Centric Computing”,
`P—31—39; Aug. 1996, Computer.
`
`* cited by examiner
`
`Primary Examiner—David Wiley
`Assistant Examiner—Phuoc Nguyen
`(74) Attorney, Agent, or Firm—Fleshner & Kim, LLP
`
`Mar. 19, 1997
`
`(AU) .............................................. PO9896
`
`(57)
`
`ABSTRACT
`
`Int. C1.7 ................................................ G06F 17/00
`(51)
`(52) US. Cl.
`........................... 718/1; 719/313; 719/310;
`719/315; 719/316
`(58) Field of Search .............................. 718/1; 719/310,
`719/313; 315; 316; 703/23; 26, 27; 709/2;
`201; 208, 219; 200; 713/201; 395/500
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`................. 718/1
`
`.............. 235/379
`
`8/1994 Hughes et al.
`5,336,870 A *
`12/1995 Bhaskar
`5,479,643 A
`9/1996 Tanaka et al.
`5,553,291 A *
`12/1996 Stevens
`5,590,281 A
`1/1998 Robinson .................... 709/202
`5,708,838 A *
`4/1998 Rosen ............... 705/39
`5,745,886 A *
`
`7/1999 McGarvey ............. 703/23
`5,926,631 A *
`..
`..... 709/203
`8/1999 Nguyen et al.
`5,931,917 A *
`
`8/1999 Stern et a1. ........... 713/201
`5,935,249 A *
`................... 709/201
`6,003,065 A * 12/1999 Yan et a].
`6,199,160 B1 *
`3/2001 Echensperger et al.
`..... 713/100
`
`The present invention relates to preparing and processing
`information to be communicated via a network or to or from
`
`other data carriers. For implementation of a novel “virtual
`machine” of the present invention, a minimal amount of
`hardware is required. Prior art virtual machines tend to slow
`down operation of the device as they interface between an
`application program and device drivers. The novel Virtual
`machine incorporates a virtual message processing means
`that
`is arranged to construct, deconstruct and compare
`messages and applied in the native code of the processor.
`The message instruction means directs and controls the
`message processor. Similarly, a protocol processor means
`governs and organs communications, under the direction of
`a protocol instruction means in the application. These ele-
`ments of the novel virtual machine increase the speed and
`efficiency and allow implementation of a practical device for
`use in communications, able to be implemented on different
`hardware having different BIOS/OS.
`
`17 Claims, 12 Drawing Sheets
`
`112
`
`VM PROCESSORS
`
`mmxuilnm:
` APPLICANDN
`
` (03
`
`
`ALLows HIS/7N6 ‘5/05',
`OR Hl/ DRIVERS
`
`
`HARDMRE Aflsmfld70A!
`LAYER,
`INNERFACE
`
`'05‘
`
`Petitioner First Data - Exhibit 1001 - Page 1
`
`

`

`US. Patent
`
`Aug. 23,2005
`
`Sheet 1 0f 12
`
`US 6,934,945 B1
`
`COMMUN/C‘A 770NS
`
`/N7"ERFACE
`
`
`
`COMMUNICATIONS
`
`L INES
`
`ACCOUN7
`
`fl DM/N/STRA TOR
`
`FIG. I
`
`Petitioner First Data - Exhibit 1001 - Page 2
`
`

`

`US. Patent
`
`Aug. 23,2005
`
`Sheet 2 0f 12
`
`US 6,934,945 B1
`
`708
`
`109
`
`710
`
`H!
`
`/
`
`107
`
`705'
`x 1%
`
`
`
`A
`
`PPL/C/i TION
`
`VM PROCESSORS
`
`H/iRDVi/ARE ABSTRACT/0N
`
`I 12
`
`104
`
`103
`
`102
`
`HAL
`
`701
`
`HW DRIVERS
`
`LA YER.
`//
`
`INTERFACE
`
`ALLOWS EXIST/N6 “is/05',
`OR Hl/ DRIVERS
`
`'05’
`
`HARDWARE
`
`FIG. I
`
`700
`
`FIG. 2
`
`Petitioner First Data - Exhibit 1001 - Page 3
`
`

`

`US. Patent
`
`Aug. 23,2005
`
`Sheet 3 0f 12
`
`US 6,934,945 B1
`
`(1) EVENT (EVENT DRIVEN STRUCTURE)
`‘CARDSW/PE’ DETECTED BY
`
`7’
`
`HW DR’VER‘S
`@
`(2) CALL BACK TO EVENT 77481.5 flNHAL)
`LOOKS UP SEQUENCE OF COMMANDS
`FOR CARDSWIPE EVENT: FROM INDEX
`
`TRACK 1 TRACKZ TRACKS
`CUSTN. PAN. EXPD. END.
`FIG 3
`' a
`
`3 @—
`(3) FUNCflON PROCESSOR CALLED UP TO
`(I, 2, o)
`COMMENCE IMPLEMENMWON 0F
`'HAprLE lD/LEC/‘ARD'
`0
`C MMANDS FOR CARD SMPE
`DHANDLE CARD,
`U
`Ldlvo ACT/ON’
`(4) SAVE WSTRL/Cr/ON /MPLEMEN7ED
`FIG. 313
`ll
`.,
`
`“
`INSTRUCTION
`DA TA
`DATA
`
`INSTRUCTION
`"
`
`FIG. 3C
`
`(S) FUNCTION PROCESSOR CAL LS up
`
`MESS/i GE PROCESSOR
`a
`
`(e) FUNCTION PROCESSOR CALLS up
`
`MESSAGE /N57RUC770N MMNS
`FOR CARD 6W/PE EVENT
`ll
`
`(7) MESSAGE PROCESSOR PLACES DATA
`PROM CARD INTO FIELDS AS D/RECIED
`
`BY MESSAGE /N$TRUCT/0N MEANS
`
`{L
`(8) NEXT FUNCTION/EVENT
`
`FIG. 3
`
`Petitioner First Data - Exhibit 1001 - Page 4
`
`

`

`US. Patent
`
`Aug. 23,2005
`
`Sheet 4 0f 12
`
`US 6,934,945 B1
`
`(1) EVENT.
`
`H41. DETECTZS EVENT
`
`IL
`
`(2) HAL ACT/VATES PROTOCOL
`PROCESSOR
`
`fl
`
`(3) PROTOCOL INSTRUCTIONS FE TCHED
`
`ll
`
`(4) PROTOCOL PROCESSOR IMPLEMENT6
`
`COMMUN/CA TIONS PROTOCOL IN
`
`ACCORDANCE WITH PROTOCOL
`
`/N5 TRUCT/ONS
`
`{L
`
`(5) NEXT FUNCTION/EVENT
`
`FIG. 4
`
`Petitioner First Data - Exhibit 1001 - Page 5
`
`

`

`US. Patent
`
`Aug. 23, 2005
`
`Sheet 5 0f 12
`
`US 6,934,945 B1
`
`0N4
`
`OM
`
`I
`
`quv‘kk\kutwt.
`kuflmw©ErgmlAmkmqmnvvovv,
`
`
`gExt2%ata;
`
`
`
`NEQZmmtmmmi4»mm:quEZDU«NZE
`EQQnTu‘O-Q2mlem.2%NSQZRWDUQMUQE
`
`
`
`.
`
`Petitioner First Data - Exhibit 1001 - Page 6
`
`
`

`

`US. Patent
`
`Aug. 23, 2005
`
`Sheet 6 0f 12
`
`US 6,934,945 B1
`
`
`
`\yGTmt
`«\kKQmltééagafi
`kTSQQR©NQvCEaEgg,EwlaEEQRQRS:
`©>§WEWQb%WXEOMQWQN200$XNQZOQUmO\QTZQO'2?sz
`
`02$ka30mmXNQZOXNI0“~th©E
`
`EQQKQQ-QZNanQ2cmm3$<kabmwawENwawt
`
`
`kSéka>313NQDNQS
`
`
`#2kam3:“23923litzkwxc
`
`EEmaRasmgak65amtm3,
`
`Petitioner First Data - Exhibit 1001 - Page 7
`
`
`

`

`US. Patent
`
`Aug. 23, 2005
`
`Sheet 7 0f 12
`
`US 6,934,945 B1
`
`\GZWQNSUmm:®
`a28%:So:Dwm§u§n§Sage:
`_min—“GR_NEKZ
`
`mo\0NON202O
`
`
`
`
`
`wmuwxqo‘«<39quZQRRQKRWQH
`
`532leEEvsmnm
`
`
`mzthuu‘OEklmmjmQZmSQEDmmwmllbm.D
`
`NON292®
`
`EEIu.Eb:RunvaDkaQONQRQ
`kl®\0\O4.3K>\m$§M093‘Dku‘mwO
`
`qmmsgm.960H825mummsgmv
`NEE0E30
`xmi0[€me0
`
`NQ>£©
`
`
`
`@Q36SEQ
`
`\0EggEgo
`
`RCAN823tQZE
`
`
`
`
`
`NQQE9x93mmTKDWOQMNQZETMQ
`
`kMUE
`
`Petitioner First Data - Exhibit 1001 - Page 8
`
`

`

`US. Patent
`
`39
`
`5
`
`1B549,439,6SU
`
`\V
`
`nEEZEQ©.Mxfinfiqmwsuwwo
`
`w_q«EAAmzxzQ30uEv?$8.AmTAAAAAAAAAAAAQAAAQAzwm
`
`TRAAAAAmtm$.56oTQCfiozw5%umwum.sEzimkwnmuE«Em,xxx:0_:3293
`m$5383o_35%LEQm
`
`
`NkmdqtlEQWQ3mmQQTOBQQN
`kzxwxnxfflklusQZN¥Q§vvO.AAAAAWZEK
`
`
`3&28.mztmWAAAAAAAAAAAQm2:moat
`
`
`32wzmh2‘WE«fl«EmmiSofiam2«om.
`
`AAAAAAAAAAAAAANEEkm:
`
`AAAAAAAAAAAAQMESKQQT
`
`Petitioner First Data - Exhibit 1001 - Page 9
`
`

`

`US. Patent
`
`Aug. 23, 2005
`
`Sheet 9 0f 12
`
`US 6,934,945 B1
`
`$9
`
`N?B
`
`
`
`
`
`«mockKER«ooopSomxfilllll.
`
`
`
`BQQxEmQ«8%meI.....
`
`48$le
`E5%me
`EE48$kakumqmm,©kthSEAAmummevv0
`
`ExmEaim,km“,0
`
`«08psz«008mememmsmkp
`
`
`
`@SEWSQE«803%368%.3v
`
`O\
`
`QL
`
`L
`
`Petitioner First Data - Exhibit 1001 - Page 10
`
`
`
`
`
`NES<QOUDKQQK”FUNK
`
`
`

`

`US. Patent
`
`Aug. 23, 2005
`
`Sheet 10 0f 12
`
`US 6,934,945 B1
`
`808%.“
`
`89%8mg:
`
`3&8me
`
` LEmQkmm,OQQQQKDQKkUNdmm,@kEQNECAANkquQvvO
`
`
`kmm,OQQWREQU
`
`80qu932
`
`DQme,
`
`Petitioner First Data - Exhibit 1001 - Page 11
`
`

`

`US. Patent
`
`Aug. 23,2005
`
`Sheet 11 0f 12
`
`US 6,934,945 B1
`
`FIELD | FIELD | FIELD
`
`
`
`DATA LOCATION maxim—70; TION
`
`
`
`DAT/i REPRESENM T/0N695CII, BINARKETC) \
`
`FORM/47’
`
`TEST FUNC7'ION
`
`LINE & COLUMN
`
`SUBSTITUNON LIST
`
`F/G. II
`
`Petitioner First Data - Exhibit 1001 - Page 12
`
`

`

`US. Patent
`
`Aug. 23, 2005
`
`Sheet 12 0f 12
`
`US 6,934,945 B1
`
`5£C770N 5EC770N SEC7'ION
`
`A/NEZ’ILX
`470A
`
`COMM/4N05
`
`FIG. I20
`
`I
`I
`i
`L
`MsgmNSM/ER)
`i—
`1
`LHMEOUflm) RETRYC?) J:
`
`—_'— :::__i'—__
`
`I"
`Ii
`llM53 MNOTHERg'
`._.__ _ _ _ _ __
`
`SECTION I
`130
`
`132
`
`SECTION I, LINE3
`130
`/3/
`
`SECTIONZ
`
`FIG. /2b
`
`Petitioner First Data - Exhibit 1001 - Page 13
`
`

`

`US 6,934,945 B1
`
`1
`METHOD AND APPARATUS FOR
`CONTROLLING COMMUNICATIONS
`
`From a first, general aspect, the present invention relates
`to a method and apparatus for preparing and processing
`information to be sent or received via a network. A network
`
`in this instance may be implemented as data carried either
`over communications lines and/or stored on smart cards (or
`other data carriers) and physically transported.
`From a second, more specific aspect, the present inven-
`tion relates to a method and apparatus for controlling remote
`payment transactions, particularly, but not exclusively, for
`controlling remote payment transactions where a persons
`account is credited and/or debited from a remote location in
`exchange for goods/services cash or credit, or where account
`information is accessed remotely to enable approval of a
`transaction.
`
`Devices for carrying out remote payment transactions are
`well-known. These “payment terminals” include EFTPOS,
`credit card payment terminals, etc.
`The most common function of payment terminals is to
`remotely access a persons account information and either
`carry out a transaction, such as crediting or debiting the
`account, or, particularly in the case of credit card payment
`terminals, to check the users account to ensure that there are
`sufficient funds to cover a transaction. Note that although
`credit card terminals do not necessarily remotely credit or
`debit the users account (the credit/debit transaction usually
`being carried out by a separate paper bill trail) and merely
`provide the information that the users account is sufficient to
`cover the transaction, such payment
`terminals still fall
`within the ambit of the present
`invention and the term
`“transaction” as used herein includes the operation of
`remotely checking the users account to “ok” a transaction.
`A payment terminal may, for example, provide for the
`following basic operations:
`(1) Input of information which is required to enable
`access to a customers account. The information is most often
`
`read from a magnetic stripe on a credit card or bank card or
`the like, or a smart card. In addition to reading details from
`a card a personal identification number (PIN) or the like
`code may also be required.
`(2) Obtain access to the customers account. This is
`usually done by remote communication with a processing
`device holding the person’s account data, usually on bank
`premises and remote from the payment terminal. Usually,
`information on the customers account input to the payment
`terminal will need to be transmitted for verification and to
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`enable access to the account. Also a money amount will
`usually need to be input
`to the payment
`terminal and
`transmitted over the communications line. At least some and
`
`50
`
`perhaps all of the transmitted data may be encrypted for
`security purposes and the payment terminal is therefore, in
`such a case, required to have means (3) providing encryp-
`tion.
`
`(4) The payment terminal may need to be able to receive
`communications over the remote line from the processor
`accessing the customers account, ie. to provide an “answer”
`to the payment device regarding the user transaction. The
`answer may include information that an account debit/credit
`has taken place (eg. EFTPOS) or merely an approval that the
`customer has enough money in his account to enable a
`transaction (some credit card payment terminals). Again,
`this transmitted information may be encrypted and, if so,
`will require translation (5) in the payment terminal.
`(6) To provide an indication that the transaction request
`is approved or that a transaction has occurred, by display or
`
`55
`
`60
`
`65
`
`2
`printer, for example. Displays may also be required to
`prompt an operator or customer to input information, e.g.,
`input your PIN “Input Amount”.
`There are many different brands of payment terminal,
`utilising many different software and hardware arrange-
`ments. This gives rise to a number of problems.
`Any account acquirer (eg. bank) will generally have their
`own operating requirements as to how remote payment
`trans-actions will be handled. The account acquirer may
`purchase a series of payment terminals which have been
`configured by a manufacturer to the acquirer’s requirements.
`These payment terminals will then be licensed or rented or
`more often supplied at no charge to merchants (e.g., retail
`stores, garages, restaurants). Multiple account acquirers may
`require access to their customers accounts via a single
`payment
`terminal. That is, one particular merchant may
`operate payment terminals which provide access to custom-
`ers accounts at other account acquirers (e.g., other banks).
`Because of different requirements of different acquirers for
`handling of remote payment transactions, the payment ter-
`minal must be arranged to operate to satisfy the different
`requirements.
`The terminal owner (often a principle acquirer) will have
`the terminal appropriately arranged and programmed by the
`terminal manufacturer to satisfy the requirements of all
`account acquirers utilising the terminal. Payment terminals
`may need to contain several programs and select the appro-
`priate program depending on the card to be processed or on
`an operator selection.
`It is often the case that the terminal owner may need to
`have the operation of the payment device amended to, for
`example, enable it
`to operate for an additional account
`acquirer, or to satisfy changed requirements for a particular
`account acquirer. Because of the different hardware/software
`architectures available, any operational alterations generally
`the require the input of the terminal supplier or manufac-
`turer. The supplier/manufacturer will be required to repro-
`gram the terminal or amend the hardware in order to carry
`out the alterations and they will usually be the only person
`who has the appropriate knowledge. The terminal owner is
`thus tied to the particular supplier/manufacturer of the
`particular brand of payment terminal.
`It is often the case that, the terminal owner may over time
`obtain different brands from different manufacturers and for
`
`operational alterations may need to return the particular
`brand to each separate manufacturer. Over time, manufac-
`turers may go out of business, in which case the payment
`terminals made by that particular manufacturer may be
`unsupported and any alteration may be difficult to achieve,
`or at least will require the input of a skilled person having
`detailed knowledge of the programming and/or hardware of
`the redundant manufacturer’s devices.
`
`Being tied to a particular manufacturer for a particular
`brand therefore causes cost,
`time and trouble when any
`operational alterations are required. There is therefore a
`reluctance to carry out operational alterations, which some-
`times means that requirements of various account acquirers
`are not fully satisfied. When an operational alteration does
`have to be carried out, it is costly. If a manufacturer goes out
`of business, the terminal owner may be left with nobody to
`alter the operation of his payment
`terminals, or indeed
`maintain the payment terminals. The present system is costly
`and inflexible.
`
`Apayment terminal device usually includes a micropro-
`cessor and a number of peripheral units (e.g., card reader,
`display, printer, communications interface, etc) controlled
`by the processor. A payment terminal device usually com-
`
`Petitioner First Data - Exhibit 1001 - Page 14
`
`

`

`US 6,934,945 B1
`
`3
`prises hardware, an operating system or a BIOS and is ready
`to accept an application for that arrangement. Or the device
`may be supplied with an interpreter to accept the applica-
`tions.
`terminals, a new
`To alter the operation of payment
`application must be created. This can be time consuming,
`costly and as the programming will be different for different
`types of devices, which may have different hardware
`arrangements as well, and must be carried out separately for
`each different type of device (i.e., different reprogramming
`operations must be carried out for different devices even
`where the same operational alterations may be required).
`The programming alterations are not “portable” between
`different types of devices.
`The most time critical aspects of operation of a remote
`payment
`terminal
`involve the building up and breaking
`down of “messages” and the formulation and operation of
`communications. By “messages” is meant, for example,
`information data which is required to be input to the device
`or communicated or displayed in order to enable carrying
`out of a remote payment transaction, and includes informa-
`tion to be communicated to the bank, e.g., customers card
`number, customers PIN, amount of transaction, etc; dis-
`played information such as “Please Input Amount”; infor-
`mation to be read from a customers magnetic stripe card or
`smart card and manipulated by the device e.g., card number,
`expiry date, etc. The operation of payment
`terminals is
`greatly concerned with the collection, rearrangement and
`communication of this message data to enable a remote
`payment transaction.
`In conventional devices, each time a message is con-
`structed or deconstructed, the operation of the machine will
`be handled by the application program. To change operation
`of the machine, the application must be changed. This is
`laborious, and gives rise to problems, as discussed above.
`The technique of creating a virtual processor (or in this
`case microprocessor) is well known and referred to as an
`interpreter. This allows programs to operate independent of
`processor. With the newer technique of also creating virtual
`peripherals then the whole is referred to as a “virtual
`machine”.
`
`Avirtual machine is computer programmed to emulate a
`hypothetical computer. Different
`incompatible computers
`may be programmed to emulate the same hypothetical
`computer. Any computer programmed to emulate the hypo-
`thetical computer will thus be capable of executing pro-
`grams for the virtual computer. This creates a complete
`portable environment for program operations.
`A problem with virtual machines is emulation is slower
`than normal program execution. For some applications this
`performance penalty is a significant problem.
`The above problems and disadvantages which have been
`discussed specifically in relation to devices configured to
`process payment transactions also would apply to devices
`configured to prepare and process any information to be sent
`or received via a network, not restricted to payment trans-
`action information.
`
`the present invention provides a
`From a first aspect
`communications device which is arranged to process mes-
`sages for communications, comprising a virtual machine
`means which includes a virtual function processor and
`function processor instructions for controlling operation of
`the device, and a virtual message processor which is
`arranged to be called by the function processor and which is
`arranged to carry out the task of assembling, disassembling
`and comparing messages, whereby when a message is
`required to be handled by the communications device the
`message processor is called to carry out the message han-
`dling task.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`“Communications” includes transport of data via a data
`carrier such as a smart card.
`
`By messages we mean a sequence of data comprising
`usually a plurality of information fields to be communicated.
`The message processor means is preferably translated
`into the native code of the microprocessor in each hardware
`device on which the virtual machine is to be implemented.
`The message processor instructions are preferably virtual
`instructions to be expressed only in the language defined by
`the message processor means- and thus never requiring
`translation to any real hardware processor.
`The message processor means in at least a preferred
`embodiment provides two specific advantages over conven-
`tional arrangements
`1) Faster Operation. The processor (executing as native
`code) operates at full microprocessor speed overcoming the
`problem of slow emulation speed for message related func-
`tions.
`
`2) Faster, simpler programming. The instructions for the
`message processor preferably consist of actual message
`“descriptions”. The programmer need only describe the
`message content, all data conversion, manipulation and
`processing is automatically performed based on the message
`description. This is a more intuitive and compartmentalised
`approach which preferably leads to faster programming with
`less errors.
`
`The protocol processor means is preferably a program
`module the specific function of which is to control and select
`the sequence of message processor operations in relation to
`messages received and transmitted.
`The protocol processor means is preferably translated
`into the native code of the microprocessor in each hardware
`device on which the virtual machine is to be implemented.
`The protocol processor instructions are Virtual instructions
`expressed only in the language defined by the protocol
`processor means and thus never requiring translation to any
`real hardware processor. The protocol processor means
`provides two specific advantages over conventional arrange-
`ments:
`
`1) Faster Operation. The processor (executing as native
`code) preferably operates at full microprocessor speed over—
`coming the problem of slow emulation speed for protocol
`related functions.
`
`2) Faster, simpler programming. The instructions for the
`protocol engine preferably consist of an actual diagram of
`the message flow. To change message flow or sequence, the
`programmer can modify an intuitive diagram, all multi-
`processing and other complications are handled automati-
`cally. This more intuitive and compartmentalised approach
`leads to faster programming with less errors.
`In a preferred embodiment, therefore, a device in accor-
`dance with the present invention includes a virtual machine
`including virtual processors which are specifically arranged
`to control message construction, deconstruction, comparison
`and to control the communication of information, both for
`reception from a network and transmission to a network.
`These operations can therefore be carried out at speed,
`overcoming the problems with known virtual machines and
`interpreters, which tend to operate slower than convention-
`ally programmed devices. The virtual machine therefore
`lends itself particularly to applications relating to
`communications, such as payment
`terminal devices and
`other devices in which message pro-cessing and communi-
`cation comprise a significant proportion of the operation of
`the device. In payment terminals, for example, a payment
`terminal including a virtual machine having the message
`processor means and protocol processor means can operate
`
`Petitioner First Data - Exhibit 1001 - Page 15
`
`

`

`US 6,934,945 B1
`
`5
`satisfactorily speedwise. The virtual machine can be imple-
`mented on any hardware, BIOS/OS arrangement and there-
`fore facilitates portability of programs.
`Implementation of such a virtual machine on payment
`terminal devices of different brands enables operation of the
`payment terminal devices or brands to be altered merely by
`altering application commands generic to all brands. Each
`brand is seen by the application as the same virtual machine.
`The virtual machine preferably also includes a function
`processor means arranged to control overall virtual machine
`action in response to operator or other external events, and
`also preferably includes function processor instructions
`which are arranged to provide directions for operation of the
`function processor means.
`The function processor means is preferably a program
`mod-ule the specific function of which is to control and
`select general operations of the device not specially con-
`trolled by the message and protocol processor means.
`The function processor means is preferably translated
`into the native code of the microprocessor in each hardware
`device on which the virtual machine is to be implemented.
`The function processor instructions are preferably virtual
`instructions to be expressed only in the language defined by
`the function processor means- and thus never requiring
`translation to any real hardware processor.
`In the preferred embodiment,
`the “application” will
`therefore comprise instructions for the message, protocol
`and function processor means. The instructions for the
`function processor means may include such prior art mod-
`ules as a function event schedular and function selector.
`
`Although the present invention is particularly applicable
`to application in payment terminals, it is not limited to such
`applications. The invention can be applied in any device
`where advantages are likely to be achieved for the arrange-
`ment and control of communications.
`With the advent of the Internet and other extensive
`
`communications networks, it is believed that the operation
`of computers, such as PCs, will become more and more
`oriented towards acting as “servers” and/or “browsers”. In
`other words, a major function of PCs connected to a
`network will be to operate either as a server, providing
`information and/or programs to the network for access by
`other parties, or as a “browser” for obtaining information/
`programs available on the network and operating on them.
`It is likely, in fact, that PCs will be asked to operate as both
`a’server and a browser. This operation will not merely be
`restricted to the Internet, but for any network, even Local
`Area Net-works.
`
`The applicant also believes that many other classes of
`devices may be connected to a network. For example in the
`future a home video cassette recording machine could be
`connected to the Internet (along with other devices) allowing
`remote programming from a browser device. An example of
`the use of this would be a worker upon learning of a
`requirement to stay at the office late and miss a favourite
`show could access their home VCR from the office and
`
`pro-gram it.
`Telephone calls will eventually be digital and most likely
`use the Internet as the digital network. Like the VCR, this
`does not mean all phones would need a qwerty keyboard and
`colour display. They will both represent other classes of
`Internet connected devices- not requiring the exact same
`configuration as PCs.
`The present
`invention facilitates the production of a
`small, economical device which is particularly arranged to
`deal with communications,
`to build, compare and decon-
`struct message information. Such a device is novel maybe
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`
`termed a Specialised Network Access Computer (SNAC).
`The applicants believe that a SNAC could emerge as a class
`of device allowing data entry and control
`through the
`Internet where a smaller, more economical device than a
`conventional PC is appropriate. In a preferred embodiment,
`the device is implemented utilising a virtual machine having
`a message processor and a protocol processor as discussed
`above. In the preferred embodiment, the software of the
`device can be considered to include three layers of virtual
`machine software (the HW drive layer,
`the Hardware
`Abstraction Layer, and the Virtual Machine Processor layer)
`and a software application. All layers other than the Virtual
`Machine Processor Layers are well established by prior art.
`A payment
`termi-nal can be used substantially without
`alteration as the hardware component of the device. A
`hardware abstraction layer (HAL) is a set of routines pro-
`viding a common application program interface (API) to
`exercise the operating system, BIOS or hardware drivers.
`HAL consists of routines to either (a) implement the
`functionality not provided by the underlying operating
`system, BIOS or hardware drivers, but needed for the
`common API, and (b) translation of parameters and adjust-
`ments of functionality required to adapted underlining OS,
`BIOS routines for the routines specified by the common API.
`Such a SNAC can be applied in many different types of
`communication application over a network.
`The present invention also facilitates the production of
`devices which incorporate a snac as a functional element of
`the device. Such devices could include both devices collect-
`ing information for transmission over a network such a pay
`telephones, particularly those equipped with smart card
`facility, or devices receiving information from a network
`such as the futuristic VCR or even washing machine.
`Preferably, message instructions and protocol instruc-
`tions may be developed on a convenient device such as a PC
`or general purpose computer, utilising a development tool in
`accordance with another aspect of the invention.
`From a further aspect, the present invention provides a
`development tool for developing message instructions for
`providing directions for operation of a message processor
`means to be implemented in a virtual machine as discussed
`above, the development tool comprising a processing appa-
`ratus arranged to receive data input by a user to build
`message instructions for the message processor means.
`The arrangement is preferably driven by a graphical user
`interface based program which provides various screens and
`fields for the user to input data relating to message instruc-
`tions.
`The message instructions are preferably subsequently
`converted to code and downloaded into the device which is
`
`to employ them with the virtual machine. From a further
`aspect the present invention provides a development tool for
`developing protocol instructions for directing operation of a
`protocol processor means to be implemented with the virtual
`machine as discussed above, the development tool compris-
`ing processing means arranged to receive data input by a
`user to build protocol instructions.
`The arrangement
`is preferably a program which is
`arranged to build protocol instructions from the data input
`by the user. The program is preferably graphical user inter-
`face based and provides screens and fields to facilitate data
`input for the protocol instructions.
`Protocol instructions and message instructions can there-
`fore be built on a PC and downloaded to device where the
`
`virtual machine is to be implemented.
`A tool has also preferably been provided for developing
`function processor instructions, along the lines of the tool for
`the protocol processor instructions and message protocol
`instructions.
`
`Petitioner First Data - Exhibit 1001 - Page 16
`
`

`

`US 6,934,945 B1
`
`7
`Limited hardware provided by such a device as a pay-
`ment terminal or other SNAC device does not lend itself to
`
`development and testing of applications programs. Although
`the finalised application must
`run on the hardware,
`to
`develop and test an application it is more convenient to be
`able to utilise a more user-friendly device, such as a PC or
`general purpose computer.
`From a further aspect, the present invention provides a
`communications device including a virtual machine means
`including a protocol processor means arranged to organise
`communications to and from the device and protocol pro-
`cessor instruction means arranged to provide directions for
`operation of the-protocol processor means.
`From a further aspect,
`the present invention provides
`means for emulating a virtual machine on a PC or other
`general purpose computer, the virtual machine comprising a
`message processing means and function processor as dis-
`cussed above. The virtual machine is arranged to operate on
`the PC or other general purpose computer so that instruc-
`tions developed for the machine can be tested.
`Similar emulation is preferably provided for the protocol
`processor means.
`Emulation can therefore be used to test payment terminal
`or other SNAC application programs.
`The present invention yet further provides a method of
`programming a device for processing communications,
`comprising the steps of loading a processing means of the
`device with a virtual machine which includes a virtual
`
`function processor and function processor instructions for
`controlling operation of the device, and a virtual message
`processor which is arranged to be called by the function
`processor and which is arranged to carry out the task of
`assembling, disassembling and comparing messages,
`whereby when a message is required to be handled by the
`Add communications device the message processor is called
`to carry out the message handling task.
`The method of programming preferably also includes the
`step of loading the processor means of the device with a
`protocol processor means arranged to organise communica-
`tions to and from the device, and protocol processor instruc-
`tions arranged to provide directions for operation of the
`protocol processor means.
`The present invention yet further provides a computer
`memory storing instructions for controlling a computing
`device to implement a virtual machine means which
`includes a virtual function processor and function processor
`instructions for controlling operation of the device, and a
`virtual message processor which is