NZ549154A - System for determining currency for a card transaction - Google Patents

Abstract

A computer implemented method for determining the transaction currency to be used in a transaction between a card holder and a merchant is disclosed. The method includes the steps of obtaining the card number, which includes a Bank Information Number (BIN), and sequentially selecting a currency from a list of available currencies and comparing the BIN with a list of numbers associated with the selected currency. The comparisons continue until a match is found and the transaction currency is determined or there are no more currencies on the list to search, in which case the currency of the merchant is used in the transaction.

Description

10052295788* ;5 4 915 ^ ;PATENTS FORM NO. 5 Our ref: WEJ506347NZPR ;NEW ZEALAND PATENTS ACT 1953 COMPLETE SPECIFICATION ;TRANSACTION SYSTEM ;We, Pure Commerce Pty Limited an Australian Company of Suite 145, National Innovation Centre, Australian Technology Park, Eveleigh, 1430, New South Wales, Australia hereby declare the invention, for which we pray that a patent may be granted to and the method by which it is to be performed, to be particularly described in and by the following statement: ;Intellectual Property Offie'i of N.Z. ;1 1 AUG 2006 ;RECEIVED ;-1 - ;300603609_1 .DOC.WEJ.qakld ;5 TITLE ;Transaction System ;10 ;FIELD OF INVENTION ;This invention relates to electronic payment cards like debit and credit cards and electronic payment networks that manage electronic transfer of funds between different entities or accounts. ;15 ;BACKGROUND ;Known Payment Card system and Computers and Networks essential for such systems are 20 outlined below. This is followed by a brief overview of the State of Art for the specific card system application to which the invention relates. ;THE BUSINESS OF PAYMENT CARDS ;25 ;Payment Cards ;Payment Cards of the type shown in Figures electronic money, the money which a person 30 borrows (Credit Cards). A typical credit card view). ;Payment Terminals ;35 ;A typical Payment Terminal is shown in Figure 3. It has a mechanism 2 that allows the Payment Card to be swiped, so the Card information can be read into the processing centre of the computer i-—————________ ;INTELLECTUAL PROPERTY OFFICE OF N.2. ;19 SEP 2006 ;RECEIVED ;1 and 2 are well known. They are an embodiment of already has (Debit Cards) or the money a person is shown in Figure 1 (front view) and Figure 2 (rear ;as a security check, and some other buttons to facilitate the progression and management of payment transactions. All these buttons, together with the card swiping mechanism represent the "Input" of the Payment Terminal, not quite unlike the Keyboard and Mouse of a personal Computer. There is a small LCD screen 4 built into this device for displaying essential messages. This screen represents the "Output" of the Payment Terminal, again not quite unlike the screen of a personal Computer. Apart from the Power Cable, this terminal device has another electric cable emanating somewhere from it, this is the "Wire". All communication with the Acquirer occurs via this Wire. Modern Payment Terminals can communicate wirelessly, the Radio Link being the invisible "Wire". ;In this document a Payment Terminal is not limited to a device having the physical appearance of the device shown in the picture. Any programmable computing device that has necessary Input, Output and remote communication mechanism, passes security requirements, and is approved by the Acquiring Bank or Acquiring Network (Acquirer, please see below) will constitute a Payment Terminal. ;Track2 ;The information related to the card is stored in a series of magnetic tracks on the magnetic stripe behind the card, not quite unlike you store music on cassettes, albeit digitally. Of them, Track 2 is most important from transaction processing point of view. This is how a typical Track 2 on a Payment Card looks like : ;4123456789987654=09091010000030600000? ;The portion in front of the "=" represents card number, "=" is just a delineator, 0909 represents the expiry date of the card (September 2009). The train of digits behind is security information required by bank to verify its authenticity. ;At the commencement of a transaction, when the Card is swiped, the entire track2 information is read into the memory of the computer, and Card Number and Expiry Date are extracted from it and some validation checks are run. This always happens, without exception. The Card Number is available in the Payment Terminal Computer at this point of time, and the programmer can do whatever he or she wants with it. ;2 ;Merchant ;Merchant, in the context of Payment Card Business represents the agency that accepts Payment Card as a mode of making payments, and has the means to handle such payments. ;Acquirer ;Payment Cards are issued and accepted globally. The merchant needs a local agency to handle all types of Cards, regardless of their origin. They need a single agency to settle with them all their transactions. This role is filled by an Acquirer, typically a Bank. The Merchant's Payment Terminal connects electronically with the local Acquirer, and pushes all the Card Transactions into the Acquirer's Payment Network for Authorization and subsequent Settlement (see below). ;issuer ;An Issuer is a Card Scheme member, typically a Bank, that sells or issues Payment Cards to individual customers. ;Card Schemes ;Card Schemes like MasterCard and VISA are well known. They are responsible for creation of various schemes, specifications, processing networks, management of transaction operations, settlement of funds between different parties, enforcement of policies and procedures etc. They motivate Banks and other financial businesses to become their members and sell Payment Cards branded by them. ;To ensure uniqueness of a Card Number at a global level, Card Schemes divide the total available set of numbers into different ranges or intervals, and allow members to issue card numbers within those intervals only. It is the issuing member's responsibility to ensure uniqueness within its own range. Typically a Credit Card Scheme would use the most significant 6 digits (i.e. the first 6 digits of the card number) to manage allocation between its members, and leave the rest of the digits for the members to manage themselves. The six digit number, representing the most significant six digits of a payment card is called Bank Information Number or BIN. Card Schemes have been pre-allocated the first couple of digits, and they have to manage their BINs subject to this constraint. ;3 ;Thus VISA cards must begin with first two digits between 40 and 49, a MasterCard must begin with first two digits between 51 and 55. This still leaves the Card Schemes with tens of thousands of BINs for allocation amongst their members, and hundreds of thousands or millions of numbers are available against each BIN for allocation to Payment Card Holders. ;Card Schemes regularly (typically annually) compile a directory of information about all the member Banks and distribute it among them. These directories contain complete information about the name, location, contact details and allocated BINs for various members. BINs are always country specific and this is the rule. While a multinational bank may be issued multiple BINs for use in a particular country, it may not use a particular BIN in multiple countries. ;ETSL ;Electronic Transactions Services Limited or ETSL is a joint venture of several New Zealand banks, it manages the common EFTPOS network of those banks in New Zealand on their behalf. ;ISO 8583 ;ISO 8583 is the message exchange protocol that drives or underlies virtually all Payment Networks in the world. This protocol specifies exactly what kinds of transactions are possible, the parameters that need to be exchanged between various parties, and how they should be formatted. ;The following refers to the 2003 edition of ISO 8583, from the Annex F, "Summary of Changes made to IS08583:1993". It is apparent that it holds good for 1993 edition, and possibly for earlier editions, although the article numbers might be different. ;Article 6.2.3 of ISO 8583 - this code specifies that the Amount shall be expressed in the Currency of the associated Currency Code element. Article 6.2.4 specifies how Conversion Rate element should be specified. It is because of the presence of these fields that ISO 8583 based networks have always been capable of doing Multi-Currency transactions. This is the reason why it has always been possible to do Currency Exchange with Payment Card transactions using this standard, even if manually. ;4 ;Acquirers don't always implement the entire specification on their local networks, primarily for economic reasons. However, in choosing their subset for implementation, they need to understand the entire specification to make sure the interface with the external global Card Scheme Network doesn't break down. Each and every single item has to be thoroughly analysed before inclusion or exclusion excluding in the local specification to make sure mandatory items don't get left out for Global interfacing. ;ETSL, derived its internal specification from ISO 8583 so Multi-currency in the context of payment Card processing has been part of the New Zealand electronic transaction processing field since as early as 1989. ;Electronic Payment Network ;A schematic organization (simplified version), of a Global Payment Network is shown Figure 4. Payment Terminals 20 and ATMs 21 owned or licensed by banks are linked up with the Bank's processing Centre 24 via phone lines, or wirelessly as shown in the Figure. The Bank's Processing Centre links up with Card Scheme Networks 26 via special computers called Routing Hosts 25. In fact the Card Scheme Networks shown in the picture (clouds) are just collections of thousands of such Routing Hosts. These Routing Hosts contain BIN versus Issuer mappings, so that they can send different transactions to appropriate Issuers e.g. issuing Bank A, issuing Bank B (refer to the other end of cloud in Figure 4, near the bottom). Once a transaction hits the Issuer Host, it is authorized there, and the result is sent back (via the Card Scheme network). The collection of all Payment Terminals and ATMs linked up with a Bank constitute the Bank's Local Network. Three such networks are shown in this picture. These networks link up with the Global Card Schemes Network via Routing Hosts as shown. Sometimes Banks team up to create a joint local network, and joint interface with the Global Network, like ETSL in New Zealand. ;Authorization and Settlement ;Authorization is the process whereby a transaction request is sent to the Card Issuer, and an approval received. The idea is to establish availability of funds in the Payment card account. It may be followed by a Settlement request which results in the Card Holder account getting debited. The Equivalent amount is paid by the Issuer to the Card schemes, who pay it to the Acquirer who ;5 ;in turn pays it to the Merchant. The Card Holder sees this debit in her (typically) monthly bill from the Card Issuer. ;How a standard Payment Card Transaction progresses ;A standard payment card transaction progresses as follows: ;The Card is swiped at the Payment Terminal and Card Number and Expiry are entered into Terminal's processing area. If the magnetic stripe of the Card is worn out, or the terminal swiper doesn't work, the Card Number and Expiry Date can be keyed in to the Terminal. ;The amount of transaction is entered into the Terminal. ;The Terminal casts the transaction information into requisite format and sends it to the Acquirer. ;The Acquirer Host looks at the Card information, and determines the Card Scheme (as mentioned before, the first two digits of the card number contain this information). ;The Acquirer Host pushes the transaction into the Card Scheme Network. ;The Routing Host in the Scheme's Network looks at the BIN of the Card Number, and identifies the Issuer of the Card (as noted before, since BINs are country specific, this identification embodies the country specific branch of the Issuer, for example Citibank Hong Kong, or Citibank Australia etc, not just Citibank). ;The Card Scheme Network sends the transaction to the Issuer Host. ;The Issuer Host checks to see if funds are available, and if yes, approves the transaction. ;The Issuer Host sends the result of the transaction to Card Scheme Network, which in turn sends it to the Acquirer Host, and it eventually reaches the Merchant payment Terminal. ;The transaction result displays on the terminal, and the transaction receipt prints. The customer is asked to sign it as a means of authentication, unless he entered some kind of PIN number in the course of the transaction. ;From the above, it can be seen that mechanisms for BIN isolation from the Card Number and to determine the Country of the Card Issuer from a BIN versus Issuer mapping in course of an electronic payment transaction's progression are inherently present in any Payment Card System. This particular use of BIN versus Issuer mapping on the fly is referred to in the remainder of this document as "the known mechanism". ;In the context of New Zealand, BIN versus Issuer/Country mapping was present in the part of Payment System within its geographical boundaries from the time that the first international card transaction was routed out of this country. Thus, the known mechanism has been used in New Zealand since that time. ;Computers and Networks ;Programmable Computing Devices ;Programmable Electronic Computer or Computer for short, is a device that includes an electronic processor for processing electronically represented information, and circuitry to store, hold and run computer programs, and mechanisms to manage information input from and output into the external environment. A computer application or program includes all the information processing instructions (which the electronic processor "understands") needed to accomplish a task. ;The size of program and amount of information a computer can handle depends on the size of memory it has (usually expressed in megabytes or MB or Gigabytes or GB etc). The speed of program execution depends on the speed of its Processor (usually expressed in Megahertz or MHz or Gigahertz or GHz). ;A layperson's notion of "Computer" generally coincides with and is limited to that white metallic box that sits on her study table, or below it, and is called a PC or Mac or Apple or just Computer. What that person often doesn't know is that the handheld Payment Terminal used for entering PIN code (for example in the supermarket), or the ATM used for drawing cash, or the PDA or the Smart Phone on his or her person all belong to the same genre as "Ordinary Computer". Importantly, they are all programmed similarly. As the present invention relates to software development for Payment Terminals, hardware distinctions may be disregarded. ;The Information Processing Framework ;Computers are Information Processing Machines. From a usage point of view, this is an all-inclusive and complete characterization of computers, so innovation in usage of computers must lie either in new processing methods or the processing of new information. ;The method of processing information on a computer is usually encapsulated in a series of steps called an algorithm. Thus a new method of processing information, regardless of whether it creates a new type of computer application or improves upon an existing application, must express itself in a new algorithm. ;Furthermore, to run a particular method or algorithm on a particular piece of information, that information may have to be organized in a particular way. Thus an algorithm encompasses the organization of the information (or data structure) it runs on. ;The information the present invention relates to is about the relationship between payment card numbers and their respective currencies of operation. The fact that country of origin can be determined from card number has been well known information since the inception of electronic card payment systems. As noted before, this information is (and always has been) regularly disseminated to member banks like Citibank, BNZ, HSBC etc. Non-member payment network operators also understand this relationship very well. Card Currency is usually the same as currency of the country in which the card is issued, occasionally it is different, but is known to the issuing banks in any case. ;8 ;A relationship between Information Organization and Algorithms : An Information Processing Algorithm requires or assumes a particular organization of information it runs on. Conversely, a particular organization of information embodies all algorithms that may run on it. ;Thus the sets of Algorithms that run on distinct organizations of same information are mutually disjoint as shown in figure 7. Organization (of Information) A has algorithms a1, a2,... associated with it, Organization B has got algorithms b1, b2... that run on it. ;Flowcharts are a powerful pictographic technique for communicating steps of a process embodying sequence, flow and decision making. Each rectangular box represents a step, an arrow represents sequence or flow from one step to another, and a diamond shaped box represents a decision. ;Flowcharts are not exclusively used for computer related processes. Almost any process, whether executed by humans or machines, can be expressed in a flowchart, in as much as any process can be expressed in terms of sequence of steps and decisions. Flowcharts often achieve better clarity compared to prose, can be and are often used for detailing processes, not necessarily with an aim to computerize them. Flowcharting is a written language, with its own "alphabet", syntax and semantics, powerfully suited to represent processes that occur in time. ;Whereas a Method represents a set of steps, a Process is a method in execution, and a Flowchart is a pictorial representation of a process. For a large application or process, it may be difficult to capture all the information in a single Flowchart. This situation is dealt with by creating Flowcharts at several levels. Thus there is a top level Flowchart that captures steps of the big process at a coarse level, each step itself being a process in its own right. Then a separate Flowchart may be created for each step. This process is repeated until the steps are sufficiently atomic and there is no possibility of ambiguity as to the intention of the designer. ;There is often no difference between a Flowchart representing an existing manual process, and one representing proposed computerization of it, the two representations being semantically identical, and differing only in terminology. For example the Flowchart of Figure 8a represents the step of finding the meaning of a word, probably as part of a larger human process like "reading a book". The Flowchart of Figure 8b represents the same step in terms of manually searching a (paper) dictionary, whereas the Flowchart of Figure 9 represents a computer version of it, so the ;9 ;computer will handle the search. The Flowcharts of Figures 8a, 8b and 9 are strictly identical in terms of semantic of a step as part of a process. ;As a result, it is not possible to present the Flowchart of Figure 8b as inventive over the Flowchart of Figure 8a, or present the Flowchart of Figure 9 as inventive over the Flowchart of Figure 8b. It doesn't, however, mean that the act of computerizing a dictionary lookup couldn't possibly be inventive. The "Search word in the File" step in Figure 9, for example, could be inventive in itself. For example, it may include a method of storing the dictionary in a File, that is more efficient than usual, resulting in saving in disk space and memory (RAM). Or it may involve a new more efficient algorithm that not only results in saving Disk space and Memory, but is faster in execution. ;In the context of Figures 8a, 8b and 9 the act of loading the dictionary on the Computer achieves nothing unless something is done with it. No doubt it is new information for the Computer, it probably didn't exist there before, but it is not new information intrinsically. To achieve something with this well known information, something must be done with it. If new information is not introduced into the semantic of a process or step, then inventiveness must necessarily lie in the information processing algorithm for this process or step. ;Layers of Complexity and Abstraction ;Computers are enormously complex machines. The Digital Communication Networks are complex as well. The combination, sometimes called a Compunication Network, is even more complex. It would be nearly impossible for anyone to understand every detail of it. Indeed, it would be a difficult task to master every detail of any particular layer of it. ;There is a very powerful concept, which occurs in the field of Information Technology over and over again, that of layering or slicing. A difficult task is divided into thin layers or slices, and each layer is allowed to be managed independently of others. Seen in terms of technology, it means the sum total of all of technology should be so divided into layers that each layer can be managed separately. In people terms, this means people can specialize in different layers, and manage them. The reason it is layers, rather than chunks for example, is that it allows complexity, the inevitable result of advancement, to grow in one direction, but be contained in others. There is one ;10 ;more reason, computers and digital networks are about information processing and its flow. Both tasks are well suited to layering, both within themselves and between them. ;The boundaries between layers are joint responsibilities, technology or people on both sides of a boundary must manage it jointly, so they both need to understand it well. The complexity of a particular layer is hidden within it, and is managed by technology or people specializing in it. At the boundary, everything is abstracted out to something simple that is visible from outside of this layer. Thus a person outside a layer only needs to deal with the abstraction for that layer, he doesn't need to look beyond. This abstraction is of the nature of a contract or a promise, often expressed in terms of a communication protocol. ;This is illustrated with an example shown in Figures 5 and 6. ;Figures 5 and 6 illustrate a particular organization of a computer in layers. In this example there are three layers, namely Hardware, Operating System and Applications. The Operating System abstracts out everything concerning Hardware, the applications really don't know what's going on inside the Operating System or further below. The Operating System manages all data input and output. Furthermore, there are layers within the Operating System which abstract the Local (this computer) distinctly from the Remote (another computer on a network of computers). And then there are easy to follow addressing schemes to specify where in Local or which Remote etc. Thus from the application point of view, storing a file locally (output to local disk etc) is no different from sending it to another remote computer (output to a remote computer), the same application will do the job, by simply specifying where the output should go. ;Client Server ;This is a computing paradigm in which computation occurs at a different computer (server) from where its output is consumed (client). When a internet user visits a web site, the users computer is the client, it "consumes" the output of the computer that created a web page (server, or web server). ;Host ;11 ;Simply put, a Host is the Server machine in Client Server, exactly as one would expect. ;Electronic Payment Networks ;Electronic Payment Networks, from a computer perspective, link up and represent collections of a range of (human) user interface devices like EFTPOS devices, Automatic Teller Machine (ATMs), Web Payment Pages etc with transaction processing and accounting systems of Payment Card Schemes like Visa and MasterCard and Banks like American Express or Bank of New Zealand. The afore-mentioned human interface devices are collectively called Terminal Devices. ;Terminal Devices could be real, as in case of ATMs which need to dispense cash, or virtual, like Web Payment Pages. This distinction arises from the fact that for real devices, the terminal transaction management hardware and software is located locally, whereas for virtual devices, it is elsewhere on the network. A Terminal Device may have features from both varieties wherein part of the terminal side of transaction computing occurs on the device, the rest occurs elsewhere on the network (background devices). As noted above most real Terminal Devices (on Electronic Payment Networks), regardless of size, shape and appearance, and background devices, are programmable electronic computers. Similarly most Virtual Terminal Devices are driven remotely by programmable electronic computers. ;The terminal devices manage human user interaction and electronic communications to capture all the information required for processing a transaction, send this information electronically to the card scheme or bank's accounting system, and convey the result to the human user at the end of the transaction. ;State of the Art ;New Zealand patent number 517105 discloses a method and a system of computer aided currency exchange for electronic payment cards. The term dynamic in the term "Dynamic Currency Conversion" refers to automating the currency conversion step stated to be entirely ;12 ;manual before the application was filed. Therefore, NZ 517105 is about computerization of the currency conversion step. ;The information organization disclosed in NZ 517105 is more or less industry standard and the implied algorithm is a simple search through that information. ;The normal steps for processing a Payment Card transaction with currency exchange are : ;1 .Obtain the Payment Card from the Customer. ;2.Swipe the Payment Card on the Card Reader to extract the track 2 data. Alternatively enter the Card Number manually. ;3.Determine the Card Currency from the Card for potential Exchange Transaction. ;4a.If Card is determined to be foreign, convert local amount into foreign amount. ;4b.Solicit Customer Choice. ;5.Process the payment transaction in the Choice Currency and print Receipt. ;Steps 1, 2 and 5 always occur, regardless of whether currency exchange is involved or not (step 5 ;defaults to merchant's local currency in this case). With manual currency exchange, steps 3 and 4 ;are performed manually, and are candidates for computerization. Step 4b, in fact stays manual even after computerization, in the sense that the operator has to prompt the customer to express choice by pressing a button somewhere. To computerize steps 3 and 4a, one has to; ;Put the BIN versus Currency map somewhere on the computer or the network; ;Put the Currency versus Conversion Rate map somewhere on the computer or the network; ;And then a search through these files must be performed while the transaction is in progress, so that the currency of the card can be determined on the fly, and automatically offer a choice to the customer. ;The information relating to card prefixes or BINs and corresponding currency symbols is generally organized in terms of tables similar to the following : ;456789 AUD 432198 GBP ;13 ;567890 EUR ;The above table means that if a card number starts with 456789, it was issued by an Australian Bank, so choice should be offered in Australian Dollars. Similarly, if the card number starts with 432198, the choice should be offered in British Pounds, and if it starts with 567890, in Euros, and so on and so forth. ;Card Schemes often issue entire ranges of BINs to large banks. For example, all BINs in the range 432198 to 432210 might belong to a single British bank. So rather than having 13 consecutive entries for GBP, we can have a single range entry as follows : ;456789 AUD 432198-210 GBP ;567890 EUR ;This table, with mixed single entries and range entries is more efficient than the previous table in terms of saving in storage space and speed of search. ;In view of the fact that there are hundreds of thousands of such entries to be loaded on the terminal, a lot of memory space must be reserved for it. And in view of the fact that these entries have to be searched through while a transaction is in progress, good computing power is required to ensure there is no latency in the progress of the transaction. While these issues are not very important on high powered server and desktop machines with memory space running into gigabytes, and processor speeds running into several gigahertz, they become important issues for standard hand held terminals routinely seen in shopping malls. ;A variety of techniques are commonly employed. The known technique of using BIN ranges accomplishes a saving in memory space and enhanced speed of execution, but only up to a point. ;14 ;Most hand-held devices currently in use have got only a few megabytes of memory to accommodate all of program and information files. BIN files have grown rapidly in recent years and don't fit into standard devices anymore even with range optimization included. Locating these files on remote server machines on the network is one option, but this has its own problems. Payment Terminals are usually linked up with Payment Networks using dial-up networking. They dial into the acquirer host on the payment network every time a new transaction is requested and then hang up. If BIN and Exchange Rate files were to be located on the network as well, the terminal will need to dial twice, once into the Currency Exchange Service Provider, for the currency exchange steps (steps 3 and 4a above), and then into the Acquirer Network for Authorization. This will cause unacceptable latency, and would be an unacceptable solution. ;OBJECT OF THE INVENTION ;It is an object of the present invention to provide a card transaction method or system which at least provides a useful alternative to existing transaction methods or systems. ;Alternatively, it is an object of the invention to provide an improved dynamic currency conversion (DCC) method or system. ;BRIEF SUMMARY OF THE INVENTION ;Accordingly in one aspect the invention consists in a method of determining a transaction currency for a card transaction between a card holder and a merchant, the method including the steps of: ;a) obtaining the card number; ;b) selecting a currency from a plurality of available currencies; ;c) searching a set of prefixes associated with the selected currency to determine whether a prefix of the card number is included in the set; ;d) if a prefix of the card number is included in the set, then determining the selected currency as the transaction currency; ;15 ;e) if a prefix of the card number is not included in the set, then selecting a further currency from the plurality of available currencies; ;f) repeat steps c) - e) until a prefix of the card number is found or until there are no more available currencies; ;g) if a prefix of the card number is not found after step f, then determining the currency of the merchant as the transaction currency. ;The available currencies are preferably selected in a predetermined order. ;Preferably the order of selection is determined from the number of previous transactions performed for each currency. ;The method may include the step of allowing the cardholder to confirm the transaction currency. ;The method preferably includes the step of providing the cardholder with an opportunity to instead proceed with the transaction in the currency of the merchant after the selected currency has been determined as the transaction currency. ;Preferably the transaction amount is provided to the customer in the transaction currency prior to completion of the transaction. ;Preferably the method includes the steps of using an exchange rate to calculate a transaction amount in the transaction currency, and providing the transaction amount to the customer prior to completion of the transaction. ;In a further aspect the invention broadly consists in a system for determining a transaction currency for a card transaction between a cardholder and merchant, the system including one or more processors programmed and operable to perform the method as set forth in any one of the preceding statements. ;16 ;Further aspects of the invention will become apparent from the following description. DRAWING DESCRIPTION ;One of more embodiments of the invention will be described below with reference to Figure 7 the accompanying drawings. The drawings referred to on this document may be briefly described as follows: ;Figure 1 is a front view of a credit card ;Figure 2 is a rear view of a card of Figure 1 ;Figure 3 is a perspective view of a card payment terminal ;Figure 4 is a schematic diagram of a Global Payment Network ;Figure 5 is a schematic diagram showing Application, operating system and Hardware layers of a computer in the context of a "save file locally" command ;Figure 6 is another representation of Figure 5, but in the context of a "save file remotely" command ;Figure 7 is Venn diagram of information organized as organisation A and organisation B, and algorithms a1 - a4 and bi - b4 associated with each organisation. ;Figure 8 & b are flow charts depicting a manual process. ;Figure 9 is a flow chart depicting the process of Figures 8a and 8b but performed by computer. ;Figure 10 is a flow chart illustrating operation of the present invention ;17 ;The present invention provides new organization of BIN information, and a new algorithm, so that all the necessary computing will occur on the hand terminal, and there will be no storage or latency issues. The new data organization will allow up to 50% saving in space and the new algorithm will allow up to 80% improvement in response time for leading currencies (for the conversion step). ;The present invention provides a specific organization of card number prefix information BIN (which may simply be information), a specific search algorithm for this information and a specific network or server process to assist the algorithm. ;BIN organization ;The prefixes or BINs should be logically organized as follows in: ;AUD: ;41235678 458908 4445551 ... ;GBP: ;51235778 458908 5446551 ... ;EUR: ;4321356 44332189 431786-431792 ... ;BWP : ;4431366 54336789 451967 ;Thus there is a set of prefixes or BINs associated with each of a number of available currencies which are supported by a terminal or system ;This organization has the following properties : ;18 ;a) Prefixes or BINs are organized in terms of individual currencies, not as a table of BIN to currency mappings, but the reverse of it in terms of whole lists or groups for individual currency BINs. ;b) In terms of size, BINs can be 6 digits, or 7 digits ..., any number deemed suitable can be chosen c) Prefixes or BIN ranges can be included in lists d) The individual currency lists may be ordered in terms of the number of previous foreign currency transactions, for each currency processed by the merchant or by the relevant terminal or network mode from highest number to lowest in decreasing order. Thus if the maximum number of foreign transactions for any particular merchant a group of merchants occur in AUD, it is on top of the list. If the British Pound is second, then it comes second on the list and so on and so forth. ;Algorithm ;The present invention proposes the following algorithm for the Currency identification step (step 3 described in "State of Art" above ). The algorithm pre-supposes existence of BIN information as outlined above and is performed in the context of a card transaction between a cardholder (I.e. someone using a card such as a credit card) and a merchant. ;In a preferred embodiment of the invention, the steps are : ;a) Align the list of supported currencies in the same order as in the supplied BIN information. ;b) Request Card Number from Input. ;c) Commence search through the BIN information. ;d) Assume the card currency is first currency on the list. ;e) Search through the list of variable sized card prefixes for this currency stored in a suitable data structure. ;f) If a match is found, return the assumed currency. ;g) Repeat the last three steps for all the currencies listed in the BIN information. ;h) Return local currency if no match found. ;The above steps are captured in the Flowchart of Figure 7. ;As can be seen, the method above many also simply be used to determine whether the card is a "foreign" card or local card. ;19 ;The foreign currency determination algorithm enshrined in the above DCC sub-process involves a two dimensional reverse search. It is two dimensional because it spans a list of supported currencies, and for each such currency, it spans a list of variable length card prefixes. It is a reverse search because rather than searching for a foreign currency for a given card prefix, it hypothesizes the card belongs to a particular currency and then proceeds to establish or negate the hypothesis. ;Server Process ;The Server Process consists of analysis of the accumulated customer data on a daily, or weekly or monthly basis, any suitable period may be chosen. The usage rate of conversion for different currencies is determined, and BIN information is re-organized as necessary. ;Embodiments ;The prefix or BIN information so organized may be stored anywhere on the network, but as pointed out before, this is especially useful for locating within small memory footprint handheld terminals. The Algorithm would normally run on the Payment Terminal as well, though it can run anywhere else for whatever reason. The Server Process may run within the Payment Network or outside of it. ;It should be noted that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications may be made without departing from the spirit and scope of the present invention as set forth in the accompanying claims and without diminishing its attendant advantages. It is, therefore, intended that such changes and modifications be included within the present invention. ;20 *

Claims (10)

5 WHAT WE CLAIM IS

1. A computer implemented method of determining a transaction currency for a card transaction between a card holder and a merchant, the method including the steps of: 10 a) obtaining the card number; b) selecting a currency from a plurality of available currencies; c) searching a set of prefixes associated with the selected currency to determine whether a 15 prefix of the card number is included in the set; d) if a prefix of the card number is included in the set, then determining the selected currency as the transaction currency; 20 e) if a prefix of the card number is not included in the set, then selecting a further currency from the plurality of available currencies; f) repeat steps c) - e) until a prefix of the card number is found or until there are no more available currencies; 25 g) if a prefix of the card number is not found after step f, then determining the currency of the merchant as the transaction currency.

2. A computer implemented method as claimed in claim 1 wherein the available currencies are 30 selected in a predetermined order.

3. A computer implemented method as claimed in claim 2 wherein the order of selection is determined from the number of previous transactions performed for each currency. 35

4. A computer implemented method as claimed in any one of the preceding claims including the step of allowing the cardholder to confirm the transaction currency. INTELLECTUAL PROPERTY OFFICE OF N.Z. - 6 NOV 2006 RECEIVED •21

5. 5. A computer implemented method as claimed any of the preceding claims including the step of providing the cardholder with an opportunity to instead proceed with the transaction in the currency of the merchant after the selected currency has been determined as the transaction currency. 10

6. A computer implemented method as claimed in any one of the preceding claims including the step of providing the transaction amount to the customer in the transaction currency prior to completion of the transaction.

7. A computer implemented method as claimed in claim 6 including the step of using an 15 exchange rate to calculate a transaction amount in the transaction currency, and providing the transaction amount to the customer prior to completion of the transaction.

8. A system for determining a transaction currency for a card transaction between a cardholder and merchant, the system including one or more processors programmed and operable to perform 20 the method as set forth in any one of the preceding claims.

9. A computer implemented method of determining a transaction currency for a card transaction between a card holder and a merchant substantially as herein described with reference to Figure 10. 25

10. A system for determining a transaction currency for a card transaction between a cardholder and merchant substantially as herein described. END OF CLAIMS INTELLECTUAL PROPERTY OFFICE OF N.Z. - 6 NOV 2008 RECEIVED 22