Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/14—Payment architectures specially adapted for billing systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/20—Point-of-sale [POS] network systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/381—Currency conversion
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

• the present invention relates to a card-based system that can offer a user (e.g. a payment card holder) an alternative currency for payment.
• a user e.g. a payment card holder
• a typical transaction terminal system for example an automatic teller machine, a point of sale terminal, a workstation of the like, will offer transactions in a currency local to the transaction terminal system. However, sometimes users would wish to make a transaction in an alternative currency.
• DCC service providers receive card account range update files from Card Schemes via their respective DCC acquirers, e.g., an Account Billing Currency File from VISA and Account Range File (GCMS Table IP0040T1) from MASTERCARD.
• card account range update files contain information to assist DCC Acquirers and their respective DCC service providers to correctly determine the cardholder's billing currency such as:
• the first stage is DCC service eligibility detection. This is a step in a process when it is determined whether the card holder of a card is eligible to benefit from a DCC service, that is, if the card of the cardholder issued in a currency other than the local currency for a front-end payment acceptance device, such as Point-of-Sale (POS) terminal or payment web-page for e-Commerce transactions.
• POS Point-of-Sale
• the card number can be validated with this information to confirm if the card is eligible for DCC service.
• the certain card range may be issued in a country in a currency different from the currency normally associated with a given country or the country's default national currency.
• a corporate card may be issued in one country in a currency different from the default national currency for that country.
• the second stage is DCC billing currency code look-up stage.
• DCC billing currency code look-up stage one known approach is to use a portion of the card number to perform a look up for the corresponding Billing Currency Code, and to determine ah appropriate exchange rate to be offered for the DCC service. Instead of maintaining the full range for look-up,
• WO/01/04846 discloses an approach that includes identifying an issuer identifier code from a payment card number and comparing this to entries in a table containing issuer identifier codes and a corresponding currency code to determine an operating currency for association with a card transaction.
• the transaction terminal system comprises an input interface to receive payment carrier data for a payment carrier, including at least a payment carrier number for the payment carrier.
• a communications interface is provided to connect to a remote host system.
• Range storage defines payment carrier number ranges, wherein the payment carrier number ranges define at least one of: a plurality of first consolidated payment carrier number ranges for which an assigned billing currency is a reference currency for the transaction terminal system, or a plurality of second consolidated payment carrier number ranges for which an assigned billing currency is not the reference currency for the transaction terminal system.
• At least one consolidated payment carrier number range is defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers associated with a given currency to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers associated with the given currency.
• Transaction terminal system processing means is operable to compare at least part of an input payment carrier number and the first and/or second payment carrier number ranges to determine whether an input payment carrier number falls within a payment carrier number range for which an assigned billing currency is the reference currency for the transaction terminal system or within a payment carrier number range for which an assigned billing currency is not the reference currency for the transaction terminal system.
• the processing means determines that the input payment carrier number does not fall within a payment carrier number range for which an assigned billing currency is the reference currency for the transaction termmal system, and/or where it is determined input payment carrier number falls within a payment carrier number range for which an assigned billing currency is not the reference currency for the transaction terminal system, the processing means transmits a rate request message that identifies at least part of the payment carrier number to the host system to identify a billing currency for the payment carrier and a billing currency conversion rate; and receives a rate response message from the host system identifying the payment carrier billing currency and the billing currency conversion rate.
• the host system comprises a host communications interface to connect to a transaction terminal system.
• Billing currency storage defines, for each of a plurality of billing currencies, a plurality of consolidated payment carrier number ranges for which an assigned currency is the billing currency, wherein at least one consolidated payment carrier number range is defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers associated with the billing currency to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers associated with the given currency.
• Currency conversion rate storage identifying conversion rates between currencies.
• Host system processing means is responsive to receipt of a rate request message from the transaction terminal system identifying at least part of a received payment carrier number.
• the processing means compares at least part of the input payment carrier number to the payment carrier number ranges defined in the billing currency storage to identify in which payment carrier number range the received payment carrier number lies, identifies a billing currency associated with that received payment carrier number and identifies a currency conversion rate between a reference currency for the transaction terminal system that sent the rate request message and an identified billing currency for the payment carrier number.
• the processing means generates a rate response message to be sent to the transaction terminal system identifying the payment carrier billing currency and the billing currency conversion rate.
• a dynamic currency conversion system can include at least one such transaction terminal system and at least one such host system.
• a further aspect of the invention provides a computer system operable to generate consolidated payment carrier number ranges for such a transaction terminal system and/or such a host system.
• the computer system comprises storage for received payment carrier number ranges, each payment carrier number range being defined by a range of consecutive payment carrier numbers extending from a lowest payment carrier number for the payment carrier number range to a highest payment carrier number for the payment carrier number range.
• Processing means is operable to consolidate received payment carrier number ranges to generate a consolidated payment carrier range, in order to generate at least one consolidated payment carrier number range defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers.
• Storage is provided for the consolidated payment carrier number ranges.
• a method of operating such a transaction terminal system can comprise: an input interface receiving payment carrier data for a payment carrier, including at least a payment carrier number for the payment carrier and transaction terminal system processing means comparing at least part of an input payment carrier number and first and/or second consolidated payment carrier number ranges to determine whether an input payment carrier number falls within a payment carrier number range for which an assigned billing currency is the reference currency for the transaction terminal system or within a payment carrier number range for which an assigned billing currency is not the reference currency for the transaction terminal system.
• the transaction terminal storage holds at least one of a plurality of first consolidated payment carrier number ranges for which an assigned billing currency is a reference currency for the transaction terminal system, or a plurality of second consolidated payment carrier number ranges for which an assigned billing currency is not the reference currency for the transaction terminal system, where at least one consolidated payment carrier number range is defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers associated with a given currency to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers associated with the given currency.
• the method further includes transmitting a rate request message that identifies the payment carrier number to the host system to identify a billing currency for the payment carrier and a billing currency conversion rate and receiving a rate response message from the host system identifying the payment carrier billing currency and the billing currency conversion rate.
• a method of operating such a host system can comprise receiving, at a host communications interface, a rate request message from a transaction terminal system.
• Host system processing means can respond to receipt of a rate request message from the transaction terminal system identifying a received payment carrier number by comparing at least part of an input payment carrier number to consolidated payment carrier number ranges defined in billing currency storage to identify in which payment carrier number range the received payment carrier number lies, and to identify a billing currency associated with that received payment carrier number.
• the billing currency storage defines for each of a plurality of billing currencies, a plurality of consolidated payment carrier number ranges for which an assigned currency is the billing currency, wherein at least one consolidated payment carrier number range is defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers associated with the billing currency to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers associated with the given currency.
• the method can further include the host system processing means identifying a currency conversion rate between a reference currency for the transaction terminal system that sent the rate request message and an identified billing currency for the payment carrier number from currency conversion rate storage identifying conversion rates between currencies, and generating a rate response message to be sent to the transaction terminal system identifying the payment carrier billing currency and the billing currency conversion rate.
• a method of controlling such a computer system to generate consolidate payment carrier number ranges can comprise: storing in computer system storage, received payment carrier number ranges, each payment carrier number range being defined by a range of consecutive payment carrier numbers extending from a lowest payment carrier number for the payment carrier number range to a highest payment carrier number for the payment carrier number range.
• Processing means of the computer system consolidates received payment carrier number ranges to generate at least one consolidated payment carrier number range defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers.
• the consolidated payment carrier number ranges are stored in computer system storage.
• aspects of the invention can be implemented by one or more computer program products comprising program code operable to carry out such methods.
• the comprise program product can include a computer readable medium or carrier carrying the program code.
• Figure 1 is a schematic block diagram illustrating an example of a configuration of a card payment system providing dynamic currency conversion.
• Figure 2 is a block diagram illustrating an example of a transaction terminal system.
• Figure 3 is a block diagram illustrating an example of a dynamic currency conversion host system.
• Figure 4 is a flow diagram illustrating the generation of range tables for use in transaction terminal system of Figure 2 and the host system of Figure 3;
• Figure.5 illustrates in more detail part of the process of generating the range tables.
• Figure 6 is a flow diagram illustrating part of the operation of the transaction terminal system of Figure 2;
• Figure 7 is a flow diagram illustrating part of the operation of the host system of Figure 3.
• Example embodiments of the invention are described hereinafter that aim to provide efficient use of network bandwidth and storage utilisation by consolidating payment carrier number ranges to generate a consolidated payment carrier number range defined by a lowest payment carrier number from a first, lower, range of consecutive payment carrier numbers to a highest payment carrier number from a second, higher, range of consecutive payment carrier numbers.
• FIG. 1 is a schematic block diagram illustrating an example system employing payment carriers in the form of a payment card system 100.
• a payment card for convenience as common form of payment carrier.
• a payment card could be credit, debit, or other form of payment card.
• the means to effect the payment may be other than a card.
• PDAs personal data assistants
• the payment card may be replaced by another form of payment carrier, for example a mobile telephone, a PDA, or the like that is configured to conduct payment transactions, for example by appropriate software and a mechanism for transferring information to and from a payment terminal system (for example in a contactless manner).
• references to a payment card are to be interpreted as an example of a payment carrier.
• FIG. 1 illustrates a transaction terminal system (or transaction station system) 10 that includes card payment functionality and additionally includes dynamic currency conversion (DCC) system functionality.
• the transaction terminal system 10 can be configured as a point of sale terminal located, for example, in the premises of a retailer, or may, for example, be an automated teller machine.
• the transaction terminal system 10 can include one or more interfaces for receiving card payment and purchase details.
• the transaction terminal system 10 is in
• the transaction terminal system 10 As a part of processing a card payment, the transaction terminal system 10 generates a payment authorisation request message 20.
• a communications network for example via the Internet, a telephone network or another network
• a computer system 12 of a bank that provides banking services for the retailer hereinafter referred to as an acquirer bank system 12.
• the transaction terminal system 10 As a part of processing a card payment, the transaction terminal system 10 generates a payment authorisation request message 20.
• the acquirer bank system 12 can include one or more computers.
• the acquirer bank system 12 can be operable to receive the payment authorisation request message 20 from the transaction terminal system 10 and to return an authorisation response message 30 in due course to the transaction terminal system 10.
• the acquirer bank system 12 is further in communication via a communications network (for example via the Internet, a telephone network or another network) with a network 14 of computer systems of a payment card operator (hereinafter referred to as the scheme network system 14).
• a communications network for example via the Internet, a telephone network or another network
• the scheme network system 14 a network 14 of computer systems of a payment card operator
• the acquirer bank system 12 is operable to analyse a payment authorisation request message 20 received from the transaction terminal system 10 to determine an appropriate scheme network system 14 for the card concerned and to forward a payment authorisation request message 22 to the appropriate scheme network system 14.
• the scheme network system 14 can be operable to receive the payment
• the scheme network system 14 is further in communication via a communications network (for example via the Internet, a telephone network or another network) with a computer system 16 of a financial institution that issued the payment card (hereinafter referred to as the issuing financial institution system). Although only one issuing financial institution system 16 is shown in Figure 1, the scheme network system 14 can be in communication with respective issuing financial institution systems 16 for respective issuing financial institutions.
• the scheme network system 14 can be operable to analyse the received payment authorisation request message 22 to identify the issuing financial institution that issued the payment card. The scheme network system 14 is then operable to forward a payment authorisation request message 24 to the issuing financial institution system 16 concerned, and to receive a response message 26 from the issuing financial institution system 16.
• the issuing financial institution system 16 can be operable to receive the payment authorisation request message 24, to process the authorisation request by comparing the details of the payment request to records held for the payment card concerned, and then to transmit an appropriate authorisation response message 26 to the scheme network system 14.
• the authorisation response message includes various details including confirmation as to whether the payment is authorised or not.
• the authorisation response message 26 is then forwarded via the scheme network system 14, the acquirer bank system 12 to the transaction terminal system 10.
• rate request and rate response messages passed between the transaction terminal system 10 and the DCC host system 18 to determine whether a DCC operation is to be performed.
• the transaction terminal system 10 can be operable to transmit an authorization request message or a financial presentment request message or a financial presentment advice message or clearing message (e.g. for the card holder's home or billing currency message) to the issuing financial institution 16 via the acquirer bank system 12 and the scheme network systems 14.
• an authorization request message or a financial presentment request message or a financial presentment advice message or clearing message e.g. for the card holder's home or billing currency message
• FIG. 2 is a schematic block diagram of an example of a transaction terminal system 10.
• the example transaction terminal system 10 illustrated in Figure 2 includes one or more processors 40, storage 42 (which can include volatile and non-volatile memory and storage), for the storage of programs and data.
• Figure 2 illustrates that the storage 42 can include, for example, a card processing application forming a card processing (CP) application module 44, a DCC application forming a DCC module 46 and reference country and/or currency information 48, a local currency card file 49 that identifies cards that have been issued in a currency local to the terminal and/or a foreign currency table 47.
• CP card processing
• DCC DCC module
• reference country and/or currency information 48 a local currency card file 49 that identifies cards that have been issued in a currency local to the terminal and/or a foreign currency table 47.
• the storage 42 can contain other applications and data.
• the reference country/currency information 48 can be held, for example as an ISO country code and an alpha currency code and/or a numeric currency code in a file in the storage 42 or in a register.
• the local currency file 49 is implemented as a range table, generated in manner to be described with reference to Figure 4.
• the local currency file 49 identifies one or more ranges of payment card numbers that have been issued by banks and other financial institutions with the local currency of the transaction terminal system 10 as the billing currency for the payment card, whereby the user (card holder) for a payment card having a number in the one or more ranges in the local currency file would not be eligible for dynamic currency conversion.
• Individual entries in the local currency file can include fields such as, for example, one or more of the following fields for:
• an alpha local currency code e.g. a 2-3 character alpha ISO currency code
• numeric local currency code e.g. a 3 -digit numeric ISO currency code
• a local country code e.g. an ISO country code
• the foreign currency file 47 is implemented as a range table, generated in manner to be described with reference to Figure 4.
• the foreign currency file 49 identifies ranges of payment card numbers that have been issued by banks and other financial institutions with a currency other than the local currency of the transaction terminal system 10 as the billing currency for the payment card, a payment card having a number in the one or more ranges in the foreign currency file would be eligible for dynamic currency conversion.
• Individual entries in the foreign currency file can include fields such as, for example, one or more of the following fields for:
• alpha foreign currency code e.g. a 2-3 character alpha ISO currency code
• numeric foreign currency code e.g. a 3-digit numeric ISO currency code
• a country code e.g. an ISO country code
• Figure 2 also represents, schematically, a keyboard/keypad 50, a scanner 52 and a card reader 54.
• the keyboard/keypad 50 can be keyboard/keypad with separate keys, or can be configured as a touch screen keyboard/keypad and can be used for the input of numerical and/or other characters as appropriate.
• the scanner 52 can, for example be a bar code scanner, an RFI tag scanner or the like.
• the card reader 54 can be configured to read data from a payment card.
• the card reader 54 can be a magnetic stripe reader, a chip card reader, a contactless reader for a contactless payment card, an RFI tag reader, etc., as appropriate.
• the card reader 54 can also be operable to write information to a suitably configured payment card.
• the transaction terminal system 10 can also be configured with an appropriate interface to interact with other sorts of payment carriers (for example mobile telephones or PDAs), for example using contact-based or contactless data exchange to receive data from a payment carrier and/or to transmit information to a payment carrier.
• Figure 2 further represents, schematically, a display 56, a printer 58 and a communication interface 62.
• the display 56 can be a numeric display, an alphanumeric display, an image display, etc. as appropriate to display input data and/or messages to assist the user (e.g. a payment card holder) and/or a retailer/merchant in operation of the transaction terminal system 10.
• the printer can be used for printing purchase receipts and/or other information.
• the communications interface 60 enables communications via one or more communications channels 62 from the transaction terminal system 10 to the DCC host system 18, either directly or via an intermediate network (not shown).
• the transaction terminal system 10 is an automated teller system or a point of sale system.
• the transaction terminal system 10 could also be in the form of a workstation connected to the Internet.
• the transaction terminal system 10 may also be fully or partially integrated into the transaction system of a hotel, theatre, retail establishment, or the like.
• Figure 3 is a schematic block diagram of an example of a DCC host system 18.
• the example DCC host system 18. illustrated in Figure 3 includes one or more processors 70, storage 72 (which can include volatile and non- volatile memory), for the storage of programs and data.
• Figure 3 illustrates that the storage 72 includes one or more DCC programs forming a DCC module 76 and one or more data tables including a billing currency file 75, currency conversion, or exchange rate tables 74, a country to currency table 77 and a default currency table 73. It should be noted that the storage 72 can contain other applications and data.
• the billing currency file 75 can, for example, be in the form of a billing currency file (BCF 75) generated in manner to be described with reference to Figure 4 that can have entries that can include various fields, including, for example, fields for:
• alpha billing currency code e.g. a 2-3 character alpha ISO currency code
• numeric billing currency code e.g. a 3-digit numeric ISO currency code
• the exchange rate tables 74 can contain information from which current exchange rate data can be extracted.
• a header entry in the exchange rate table can include various fields, including for example, one or more of the following fields for:
• a base currency code (e.g., using an ISO currency code);
• a country code (e.g., using an ISO country code);
• a file sequence number (e.g., 001 , unless more than one file for the date);
• a volume in the exchange rate tables 74 can include various fields, including, for example, one or more of the following fields for:
• Individual exchange rate entries in the exchange rate tables 74 can include various fields, including, for example, one or more of the following fields for:
• an alpha currency code e.g., an ISO standard 3 character alpha code
• numeric currency code e.g., an ISO standard 2-3 character numeric code
• a Euroband indicator e.g. a flag to indicate whether the currency is a Euroband currency
• an exchange rate (e.g., a rate of exchange rounded to 4 decimal places);
• a merchant FX-rate category e.g., to indicate FX-rate risk profile for merchant
• a valid from date e.g., the date from which the exchange rate is valid
• a valid from time e.g., the time on that date from which the exchange rate is valid
• a valid to date e.g., the date after which the exchange rate is not valid
• a valid to time e.g., the time on that date after which the exchange rate is not valid
• markup percentage value e.g., percentage value to mitigate exchange rate risk
• markup precision value e.g., to indicate a markup decimal place precision
• a final field in the exchange rate tables 74 can include various fields, including, for example, one or more of the following fields for:
• a country to currency table 77 is used to map between a country and its official currency. Typically one official national currency is associated with per country, but there may be multiple countries associated with one official national currency, e.g. EURO.
• the country to currency table is arranged by country and each entry for a country identifies an official national currency associated therewith.
• each entry can include one or more fields including, for example, one or more of the following fields:
• a country code e.g., an ISO country code
• an alpha currency code e.g., an ISO standard 3 character alpha code
• numeric currency code e.g., an ISO standard 2-3 character numeric code
• the default currency table 73 can be used to identify a default currency to be used for a transaction.
• the default currency table 73 can include, for example, a mapping between a non-supported DCC currency indicated in the billing currency file and a default supported DCC currency and can be used in certain circumstances to identify a default DCC currency to be used when a payment card is used that was issued for a currency that is not supported by the transaction terminal system 10 and/or the dynamic currency conversion system. It can also be used in certain circumstances to identify a default DCC currency to be used for a payment card that is not issued for the local currency for the transaction terminal system 10.
• the default currency table 73 is arranged by input currency (e.g.
• each entry can include one or more fields including, for example, one or more of the following fields:
• an alpha input currency code e.g., an ISO standard 3 character alpha code
• numeric input currency code e.g., an ISO standard 2-3 character numeric code
• alpha default currency code e.g., an ISO standard 3 character alpha code
• Figure 3 also represents, schematically, a keyboard 78 and a display 80.
• the keyboard 78 can be keyboard with separate keys, or can be configured as a touch screen keyboard and can be used for the input of numerical and/or other characters as appropriate.
• the display 80 can be a numeric display, an alphanumeric display, an image display, etc. as appropriate to enable an operator to view system data.
• Figure 3 further illustrates a printer 82 and a communications interface 84.
• the printer can be used for printing system data.
• the communications interface 84 enables communication via one or more communication channels 86 with the transaction terminal system 10 and the acquirer bank system 12, either directly or via intermediate networks (not shown).
• Figure 4 is a flow diagram illustrating an example of a process for generating the local and foreign currency files 49 and 47 of Figure 2 and the billing currency file 75 of Figure 3.
• the process 100 starts at 110.
• the process 100 can be performed by the processor (s) of the DCC host system 18, or can be performed by a separate computer system.
• the processor for convenience, where reference is made to the "system” performing the steps of the method, it is to be understood that this refers to the processor(s) of the DCC host system 18, or a separate computer system, as appropriate, performing those steps.
• the system receives account files from a scheme operator.
• the account files can be in the format for example, or card account range update files as described in the introduction.
• the present method provides a way of consolidating this range information in a manner that enables the generation of look up tables that can be used in an efficient manner to identify a currency code that is associated with a given card number, without needing to store all of the range information provided by the scheme operators.
• step 114 the system is operable to sort the ranges according to the consecutive account ranges based, for example, on the lower values of the card account ranges (i.e., the numbers in the left hand column of Table 1 below).
• the files can be sorted with the consecutive ranges of card numbers ordered in numerical order based on the lower values of the card account ranges. If, as mentioned in the introduction, the range information supplied by the scheme operator separates the BIN number for the account range low and account range high values, then the BIN can be added as higher significant digits to the account range low and account range high numbers and then the sort can be performed.
• the result of step 114 can, for example be files ordered as shown in Table 1 for currency code 036, with appropriate sets of ranges for other currency codes.
• the card account range update files contain information which can include, for example, for each entry in the range, the lowest point in an account range, a highest point in an account range and a card holder billing currency code.
• a number of the higher order digits identify a range of card numbers issued by a given financial institution and the remaining lower order digits identify individual card numbers within the range of card numbers.
• the part of the card numbers (i.e. the number of higher order digits) used uniquely to identify a currency code associated with a financial institution may comprise a variable number of digits, not just the 5 or 6 digits of the traditional Bank Identification Number (BIN). This is due to the way that the number ranges are allocated by the scheme operators, and takes into account factors such as, for example, the varying sizes of financial institutions. Currently, for example, rather than 5 or 6 digits, it may take up to 11 digits to identify a range of consecutive card numbers that are allocated to a given currency code for a given financial institution.
• BIN Bank Identification Number
• step 116 the system consolidates account ranges for a given billing currency to provide consolidated ranges having consecutive payment card numbers from a lowest card account number to a highest card account number in the range for a given billing currency.
• the consolidation of step 116 results in information about respective bank identification numbers being lost in the ranges. However, this does not matter as the bank identification numbers are no longer relevant to the organisation of the consolidated ranges.
• the present invention is based on the realisation that the identification of the individual financial institutions is not relevant to the process of determining eligibility for DCC and also for identifying appropriate billing currencies to perform a DCC operation.
• the consolidation performed in step 116 can be performed in multiple passes, as illustrated, for example, in Figure 5.
• Figure 5 illustrates the reordered ranges represented as a file 166-0-0 for the ranges of card numbers (e.g., for the ranges as shown in Table 1 are all associated with the currency code 036).
• a first pass 116-1 the ranges of the initial file 166-0-0 can be re-ordered using zero tolerance. In other words, the ranges can be re-ordered looking for a zero gap between the high end of one range and the low end of another range.
• This consolidation means that consecutive ranges of card numbers associated with a same currency can be consolidated into one larger range.
• one or more selected digits of the card numbers can be ignored (e.g., the four lowest significant bits), if it is known that these do not contribute to the card number ranges allocated to the financial institutions.
• the result of the first pass is a consolidated file 166-0-1 in which consecutive ranges are merged.
• the ranges of the file 166-0-1 can be re-ordered using a first tolerance.
• the ranges can be re-ordered looking for a given or configurable gap (e.g., 10%) between the high end of one range and the low end of another range.
• a given or configurable gap e.g. 10%
• adjacent ranges of card numbers in file 166-0-1 that are separated by a gap less than 10% of the number of card numbers in the adjacent ranges and with same associated currency code can be consolidated into one larger range.
• one or more selected digits of the card numbers can be ignored (e.g., the four lowest significant bits), if it is known that these do not contribute to the card number ranges allocated to the financial institutions.
• the result of the second pass is a consolidated table 166-0-1.
• the further pass can optionally be repeated a selectable number of times to further reduce the number of ranges within the file 166-0-1 based on the distribution of card number ranges to provide an appropriate compression of the range table 1 6-0- 1.
• Additional consolidation can be provided by an additional pass 116-3 in which a determination is made as to whether a range of card numbers for any other card scheme (e.g., from the files 166-N-O) falls between adjacent ranges in the file 166-0-1. If no ranges fall within between an adjacent pair of ranges, then these can be further
• the additional pass 116-3 can be repeated a selectable number of times or until, for example, until no further consolidation is possible (i.e., all adjacent pairs of ranges have an intervening range for another currency code).
• steps 116-2 and 1 16-3 can each be performed zero, one or more times. In other words, one or both of steps 116-2 and 116-3 can be omitted.
• Table 3 illustrates an example of the reduced content of a table 166-0-1 following such a consolidation process as described with reference to Figure 5.
• Table 1 it should be noted that Table 3 gives an example illustration of such information, it being understood that the actual data shown is constructed for purpose of illustration only.
• the system in step 118, the system generates range files for the transaction terminal systems including, for any given transaction terminal system, both consolidated ranges which are applicable to the currency for that local transaction terminal system.
• the format of the range files can be chosen to minimise the number of digits needed to identify the ranges concerned. In one example, a number of most significant digits needed to identify the upper and lower numbers in the range is used.
• range files are then transmitted to the transaction terminal systems to be stored in the local currency file 49.
• range files can also be generated for those ranges of card numbers which do not correspond the local or reference currency allocated to a given transaction terminal.
• the consolidated ranges for card account numbers not corresponding to the local or reference currency for the transaction terminal system can be transmitted to the transaction terminal system and can be stored in the foreign currency file 47.
• only the local currency file 49 is transmitted to a given transaction terminal system, the foreign currency file 47 being populated in addition or instead of the local currency file as an option in an alternative embodiment.
• billing currency files are generated for the host system to include all of the consolidated ranges with the corresponding billing currencies for the respective ranges being stored in the billing currency file 75 of the DCC host system 18 shown in Figure 3.
• the billing currency files can be generated using a format such as described above with respect to step 118.
• the billing currency file entry, as well as identifying an account range and a billing currency code can also include an indication as to whether the billing currency is a supported currency for the DCC system,
• the process 100 terminates at step 122.
• a terminal transaction system 10 can be provided with a local currency file 49 and/or a foreign currency file 47.
• the purpose of the local currency file and/or the foreign currency file is to determine whether a payment card used at the transaction terminal system a billing currency which corresponds to a reference currency for the transaction terminal system as stored in the reference country/currency record 48. This determination can either be performed in a positive manner, by
• the local currency file 49 will contain less entries (that is less ranges) than the foreign currency file 47, a transaction terminal system will normally only be provided with a local currency file 49.
• the currency concerned is determined by comparison of at least a part of a payment card number to a said of one or more ranges of card numbers to which would be assigned a given billing currency, in some embodiments, it may be that the foreign currency file 47 is in fact smaller than the local currency file 49. In such a case, a foreign currency file 47 could be provided instead of the local currency file 49.
• a local currency file 49, and not a foreign currency file 47 is provided in the transaction terminal system 10.
• FIG. 6 is a flow diagram illustrating part of the operation of the transaction terminal system of Figure 2.
• the process 200 starts at 210.
• the payment card number (or Personal Account Number PAN) is received from the payment card by input of that payment card number at the transaction terminal system.
• the payment card number can be entered in any conventional matter by manual input, by reading information from a magnetic stripe, by reading from a chip held on the payment card or by a contact less transfer of data from a payment card (or in each case from another form of payment carrier).
• step 214 at least a part of the payment card number is compared to the range file (that is to the local currency file 49) to identify whether the payment card number falls within the range or ranges identified as ranges of card numbers for which the billing currency is the same currency as the reference for the transaction tenninal system.
• the comparison of the payment card number to the respective ranges can be performed in any appropriate manner, for example using a conventional binary search algorithm, which enables a particular value (that is the payment card value) rapidly to be identified as being within one of the available ranges.
• the part of the payment card number that is compared is an amount needed to identify whether the payment card number falls within the relevant ranges.
• the first ten leading digits of the payment card number are compared.
• another set of digits can be compared, or indeed the whole payment card number can be compared, as long as the digits that are compared are sufficient to identify whether the payment card number falls within the relevant range(s) or not.
• a rate request is sent to a host system to identify a currency that could be offered for dynamic currency conversion, and an appropriate exchange rate for that conversion.
• the processing by the host system is described with reference to Figure 7.
• a rate response is received from the host system. It is assumed that the rate response identifies a currency that can be offered to a user for dynamic currency conversion, and also identifies the exchange rate to be used.
• the transactional terminal system computes an offer to be made to the user for dynamic currency conversion.
• the transaction terminal system uses a transaction amount input by means of one or more of the input mechanisms provided at the transaction terminal system, and the exchange rate identified in the rate response message.
• the transactional terminal system is operable to offer to the user the option of proceeding with purchase in the reference currency for the transaction terminal system, or in the DCC currency which can be offered along with an indication of the applicable exchange rate and the value of the transaction in the DCC currency computed at the offered exchange rate.
• the DCC currency which can be offered will typically be the billing currency for the payment card. However, in certain circumstances, the DCC currency offered may be a different currency.
• the currency offered is not the billing currency, but is, for example, a default currency
• the information provided to the user will indicate this fact to the user so that the user is in a position to make an objective decision as to whether to accept DCC offer or not.
• the DCC offer can be made by displaying the appropriate data on a display of the transaction terminal system, by means of an audio output, by putting a document, or in any other appropriate manner.
• step 224 the transaction is conducted in the DCC currency offered to the user.
• step 216 the currency of the payment card is the same as the reference currency of the transaction terminal, or at step 224 the user declines to accept the DCC offer.
• step 226 the transaction is conducted in the reference, or local, currency of the transaction terminal system. The transaction is then conducted in the appropriate currency as indicated at 226 or 228, and the process terminates 230.
• FIG. 7 is a flow diagram illustrating the aspects of the operation of the DCC host system 18 on receiving a rate request from a transaction terminal system.
• the process 300 starts at 310.
• the rate request message is received from the transaction terminal system.
• the rate request message identifies, among other data, at least a part of the payment card number, an identification of the transaction terminal from which the rate request message was sent, (to identify routing information for returning a reply), and optionally a transaction amount.
• the billing currency file 75 contains ranges of card numbers consolidated to include consecutive ranges of those card numbers, associated with specific billing currencies.
• the comparison process performed in step 314 can be conducted in any appropriate manner. For example, an associative lookup could be performed to identify whether the received card payment number is greater than a lower end of a range of numbers, or lower than the higher end of a range of numbers, to identify that the card number lies within that range. In the event of a positive comparison between a particular range and the card number, the billing currency can then be identified from the billing currency file.
• the part of the payment card number that is compared is an amount needed to identify whether the payment card number falls within the relevant ranges.
• the first ten leading digits of the payment card number are compared.
• another set of digits can be compared, or indeed the whole payment card number can be compared, as long as the digits that are compared are sufficient to identify whether the payment card number falls within the relevant range(s) or not.
• the billing currency file can also include an indication of currencies which are supported by the DCC system.
• a determination can be made whether the billing currency of a payment card is a billing currency which is supported by the DCC system. If the billing system is not supported, then optionally, in step 318, a default currency corresponding to the billing currency can be identified in a default currency table.
• the default currency table includes mappings from identified billing currencies to default currencies. In step 320, the default currency is set as the DCC currency.
• the billing currency becomes the DCC currency.
• the reference currency can be identified from the rate request message received from a transaction terminal system either directly in that the reference currency is contained within the rate request from the transaction terminal system or, for example, from transaction terminal country data which can then be used to access a country to currency translation table (not shown) to identify a reference currency, and then an exchange rate from the reference currency to the DCC currency is accessed in the rate tables 74.
• the host system is operable to generate a rate response message and to send the rate response message to the transaction terminal system that issued the rate request, using the identifier of the transaction terminal system and/or addressing information contained within the rate request message.
• the process terminates at step 328.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Finance (AREA)
• Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Economics (AREA)
• Development Economics (AREA)
• Marketing (AREA)
• Technology Law (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
• Cash Registers Or Receiving Machines (AREA)
• Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Priority Applications (7)

Applications Claiming Priority (2)

Publications (1)

Family

ID=42228419

Family Applications (1)

Country Status (11)

Families Citing this family (6)

Citations (5)

Family Cites Families (8)

• 2010
  • 2010-03-26 GB GB1005126A patent/GB2478993A/en not_active Withdrawn
• 2011
  • 2011-03-17 AU AU2011231801A patent/AU2011231801A1/en not_active Abandoned
  • 2011-03-17 WO PCT/EP2011/054035 patent/WO2011117134A1/en active Application Filing
  • 2011-03-17 BR BR112012024332A patent/BR112012024332A2/pt not_active Application Discontinuation
  • 2011-03-17 SG SG2012069985A patent/SG184180A1/en unknown
  • 2011-03-17 JP JP2013500435A patent/JP5854527B2/ja active Active
  • 2011-03-17 CN CN2011800260681A patent/CN102906775A/zh active Pending
  • 2011-03-17 EP EP11712498A patent/EP2553640A1/en not_active Withdrawn
  • 2011-03-17 MY MYPI2012700674A patent/MY162596A/en unknown
  • 2011-03-17 KR KR1020127027974A patent/KR20130012071A/ko not_active Application Discontinuation
• 2012
  • 2012-09-26 CL CL2012002682A patent/CL2012002682A1/es unknown

Patent Citations (6)

Also Published As

Similar Documents

Legal Events