The invention described in the accepted parent specification
16 The accepted parent specification is entitled "Dynamic currency conversion for card payments systems". It describes the invention as relating to card payment systems for use in a multi-currency environment. The accepted parent specification says that the invention provides systems and methods for identifying an appropriate currency for individual transactions conducted using a card payment system. The systems include those relating to the use of credit cards, charge cards and debit cards. The context provided by the accepted parent specification is a transaction where the cardholder presents his or her card at the point of sale to a merchant for the payment for goods or services.
17 The accepted parent specification points out that, in general, transactions involving a card payment are conducted in the currency of the merchant. However, this is said to be inconvenient for cardholders travelling abroad if they are unsure of the exact value of the transaction in their own currency. Other disadvantages are discussed.
18 The accepted parent specification says that it would be advantageous if a cardholder could view and/or make payments in his or her home currency rather than the currency of the merchant with whom the transaction is being conducted. Further, the accepted parent specification says that it would be advantageous if the currency could be determined at the point of sale automatically, using only a payment card's details.
19 At the 2014 hearing, the applicant and the respondents advanced competing interpretations of the invention described in the accepted parent application. Before dealing with these competing interpretations, it is necessary for me to record, firstly, the role played by the accepted parent specification at the 2014 hearing and then, secondly, to note briefly some concepts and terms which were of significance and remain so.
20 When considering the successive and cumulative requirements of s 102(1) and s 102(2) of the Act in relation to an accepted complete specification that has already been amended (as is the case here), it is important to distinguish between the form of the complete specification as filed (meaning, as initially or originally filed) and the form of the (amended) complete specification that is sought to be further amended.
21 Notwithstanding the importance of this distinction, at the 2014 hearing the parties were prepared to treat the description of the invention in the accepted parent specification, and the description of the invention in the parent specification as filed, as materially the same.
22 Thus, for the purposes of the 2014 hearing and the appeal reasons, the accepted parent specification became the primary focus of the analysis of the invention as described.
23 As to concepts and terms, I refer, firstly, to the concept of a "Bank Identification Number" or BIN. Typically card schemes and card companies employ a numbering structure for cards to ensure consistency and efficiency in operations. This structure is governed by a set of agreed rules which must be followed by the issuer of the card (i.e., the bank, institution or card company that provides cards to consumers to allow them, as cardholders, to make purchases at merchants accepting that card) and by the acquirer (i.e., the bank, institution or card company that processes payments for the merchant). Typically the issuer will produce cards with a total number length of between 13 and 16 digits. Generally speaking, the first six digits of the card is the BIN. The last digit is a check digit, which is calculated using the other card digits. It provides error detection in transaction message processing. The digits from and including, say, the seventh digit up to and including the penultimate digit are the account numbers given by the issuer for the discrete cards that are issued.
24 Next, the accepted parent specification uses the terms "identifier code", "issuer code" and "issuer identifier code" when describing how an extracted code from the payment card details is used, according to the invention, for the purposes of automatically setting the currency for the transaction with the merchant. There is a lack of consistency and a consequent degree of confusion in the use of these terms in the accepted parent specification which is a source of difficulty in identifying the invention described. This provided the occasion for the parties to advance their competing interpretations of the invention described.
25 At [71]-[72] of the second appeal reasons, I summarised the applicant's interpretation as follows:
71 In substance, the applicant contends that the accepted parent specification discloses an invention which distinguishes conceptually between, on the one hand, an identifier code extracted from the payment card details and, on the other hand, an issuer code or issuer identifier code. The applicant contends that the accepted parent specification uses the terms issuer code and issuer identifier code interchangeably. The applicant contends that although, as a matter of fact, the identifier code and the issuer code (or issuer identifier code) may involve the same number of digits with the same numerical sequence, this is not necessarily the case. In implementing the invention, the respective lengths of the identifier code and the issuer code (or issuer identifier code) may vary. However, the person skilled in the art would recognise that, in order to implement the invention, the identifier code must be at least as long as the issuer code.
72 The applicant contends that the accepted parent specification describes the issuer code (or issuer identifier code) as an important component of the invention, called the bank reference table (the BRT). The BRT contains a list of issuer codes (or issuer identifier codes). Each issuer code (or issuer identifier code) is associated with a particular currency - the cardholder's currency. Thus, when the identifier code (which is extracted from the card) is mapped to an issuer code (or issuer identifier code) in the BRT, which associates the issuer code (or issuer identifier code) with a particular currency for the cardholder's account (i.e. the cardholder's currency), the cardholder's currency is set as the currency for the transaction. If the identifier code is not mapped to a corresponding issuer code (or issuer identifier code) in the BRT, the currency for the transaction will be the merchant's currency.
26 At [73] of the second appeal reasons, I summarised the then respondents' competing interpretation as follows:
73 In substance, the respondents contend that the term "issuer code" must be a code that determines the "issuer", and that the terms "identifier code", "issuer code" and "issuer identifier code" are used in the accepted parent specification interchangeably. According to the respondents, there is no conceptual difference between these codes. They are, for the purposes of the invention, one code. Moreover, this code is the issuer's BIN. The BIN is referred to elsewhere in the evidence, including in International Standard ISO/IEC 7812-2, as an Issuer Identification Number (IIN). As at the priority date, the BIN/IIN was the only known code "in the card payment industry" that identified the issuer of the card.
27 At [76] of the second appeal reasons, I recorded the fact that the respondents' witness, Mr Ingham, considered that the BRT of the alleged invention was nothing more than a BIN table. However, I noted that, in final submissions, the respondents did not advance that specific interpretation, but another interpretation, which I summarised as follows:
76 Mr Ingham considered the BRT of the alleged invention to be nothing more than a BIN table. However, in final submissions, the respondents did not advance that specific interpretation. The respondents' case is that the invention disclosed and described is one in which the issuer has determined that it will issue cards for one particular currency only, which will be "its" currency. The respondents accepted that there is a conceptual distinction between a BIN table and the BRT of the invention. Nevertheless, the respondents contend that the issuer code (or issuer identifier code) and the identifier code are one and the same thing, which is, in fact, the BIN that has been allocated to the issuer by a particular card scheme or card company. In this way, the invention is one in which, by reference to the BIN, expressed in the BRT, the associated currency is the issuer's currency, which is set as the currency for the transaction. Thus, on the respondents' case, if it be appropriate to speak of the cardholder's currency, that currency is the issuer's currency. By this reasoning, the respondents say that the invention, if there be one, is the method or system that automatically sets the currency for the transaction to the issuer's currency, which the respondents also described as the issuer's "domestic" or "home currency". It is not a method or system that accommodates a range of different currencies for cards issued by the one card issuer.
28 I then noted (at [77] of the second appeal reasons):
77 The respondents submitted that the key issue in dispute is whether, as they contend, the accepted parent specification (and, by implication, the parent specification as filed) discloses a method for automatically determining only the currency of the issuer (i.e. the issuer's domestic or home currency), based on the issuer's BIN or whether, as the applicant contends, the accepted parent specification (and, by implication, the parent specification as filed) discloses a method for automatically determining the currency of the cardholder (i.e. the currency of the cardholder's account with the issuer), which may be different to the domestic or home currency of the issuer. There is a further refinement to the applicant's contention, namely that the accepted parent specification (and, by implication, the parent specification as filed) discloses that, for a given range of card numbers assigned to an issuer, the issuer can, within the range, issue cards for different currencies, each card having its own associated currency, which is not necessarily the issuer's home or domestic currency.
29 I reached the following conclusions:
122 The accepted parent specification and the parent specification as filed each disclose and describe a payment card method or system in which the currency automatically set for the transaction is the currency associated with the card itself. If there is no currency associated with the card, the transaction will proceed in the merchant's currency.
123 The specifications use a variety of expressions, including "the currency of a cardholder", "the card issuer's currency", "the currency of payment of cardholder's accounts of the issuer", "the currency of the payment cardholder's account", "the currency of the cardholder's card", "the currency of a card", and "the cardholder's currency". The accepted parent specification also refers, in a number of places, to the card having "an associated currency". Despite the use of these various expressions, there is no doubt that the accepted parent specification and the parent specification as filed disclose and describe an invention in which only one currency is associated with the range of card numbers assigned to an issuer. Considered at this level of generality, it matters little whether the currency associated with the card is called, as the respondents contend, the issuer's currency or, as the applicant contends, the cardholder's currency, or something else.
124 I am not persuaded that the accepted parent specification or the parent specification as filed prescribe that the currency associated with the card must be the domestic or home currency of the issuer, although there are indications in each specification that this could be the alternative currency to the merchant's currency. Underpinning the respondents' submission that the alternative currency to the merchant's currency must be the domestic or home currency of the issuer is their related submission that the identifier code, the issuer code and the identifier issue code are conceptually the same and must be, in fact, the issuer's BIN.
125 For the reasons I have given above, I am satisfied that, at the priority date, the person skilled in the art would understand the accepted parent specification and the parent specification as filed as disclosing and describing a payment card method or system in which:
• the issuer code and the issuer identifier code are the same conceptual entity;
• the identifier code, on the one hand, and the issuer code/issuer identifier code, on the other hand, are conceptually distinct;
• the identifier code is not restricted to a BIN, and
• the issuer code/issuer identifier code is not restricted to a BIN.
126 Thus, at the priority date, the person skilled in the art would have understood that the payment card method or system is not one in which the currency associated with the transaction, and hence associated with the card, as an alternative to the merchant's currency, is necessarily the domestic or home currency of the issuer. It may be another currency.
127 Nevertheless, at the priority date, the person skilled in the art would have understood that there is only one currency for or associated with:
• the identifier code;
• the issuer code/issuer identifier code, and
• the range of card numbers assigned to the issuer,
and that this currency is the only alternative to the merchant's currency.