Electronic Tax-Free Shopping Ltd v Fexco Merchant Services

Federal Court of Australia|2015-02-06|Before: Yates J

TES J DATE OF ORDER: 6 FEBRUARY 2015 WHERE MADE: SYDNEY

By no later than 4.00 pm on 13 February 2015, the parties bring in agreed draft orders giving effect to these reasons and providing for all additional steps necessary to bring the appeal in NSD 1517/2007 into readiness for hearing. Note: Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011. IN THE FEDERAL COURT OF AUSTRALIA NEW SOUTH WALES DISTRICT REGISTRY GENERAL DIVISION NSD 2247 of 2011

ON APPEAL FROM THE COMMISSIONER OF PATENTS BETWEEN: ELECTRONIC TAX-FREE SHOPPING LIMITED

AUSTRALIA AND NEW ZEALAND BANKING GROUP LIMITED ACN 005 357 522

JUDGE: YATES J DATE OF ORDER: 6 FebrUARY 2015 WHERE MADE: SYDNEY

By no later than 4.00 pm on 13 February 2015, the parties bring in agreed draft orders giving effect to these reasons and providing for all additional steps necessary to bring the appeal in NSD 1517/2007 into readiness for hearing. Note: Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011.

IN THE FEDERAL COURT OF AUSTRALIA NEW SOUTH WALES DISTRICT REGISTRY GENERAL DIVISION NSD 1517 of 2007

ON APPEAL FROM THE COMMISSIONER OF PATENTS BETWEEN: ELECTRONIC TAX-FREE SHOPPING LIMITED

JUDGE: YATES J DATE: 6 FEBRUARY 2015 PLACE: SYDNEY

IN THE FEDERAL COURT OF AUSTRALIA NEW SOUTH WALES DISTRICT REGISTRY GENERAL DIVISION NSD 2247 of 2011

ON APPEAL FROM THE COMMISSIONER OF PATENTS BETWEEN: ELECTRONIC TAX-FREE SHOPPING LIMITED

AUSTRALIA AND NEW ZEALAND BANKING GROUP LIMITED ACN 005 357 522

JUDGE: YATES J DATE OF ORDER: 6 FEBRUARY 2015 WHERE MADE: SYDNEY

REASONS FOR JUDGMENT 1 There are two appeals before the Court. They relate to three decisions of a delegate of the Commissioner of Patents (the delegate and the Commissioner, respectively). 2 The first appeal (NSD 1517 of 2007) is from a decision of the Commissioner given by the delegate on 13 July 2007. This decision upheld oppositions to patent application 763008 (the parent application). 3 The second appeal (NSD 2247 of 2011) is from two decisions of the Commissioner given by the delegate on 22 November 2011. These decisions refused amendments to: the complete specification filed in respect of the parent application, which had been advertised as accepted on 10 July 2003 (the accepted parent specification), and the complete specification filed in respect of patent application 2003252928 (the divisional application), which had been advertised as accepted on 15 November 2007 (the accepted divisional specification). 4 The parent application and the divisional application are for standard patents. 5 Each appeal is brought pursuant to s 104(7) of the Patents Act 1990 (Cth) (the Act). It is to be noted that the provisions of the Act relevant to this proceeding are those that existed prior to the amendments made by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (Cth). 6 In order to understand the relationship between the two appeals and the scope of the present hearing, it is necessary to descend to some detail concerning the procedural history of the matter.

procedural history 7 The first applicant, Mainline Corporate Holdings Limited (Mainline), filed the parent application on 1 September 1999. This was a PCT application, based on the filing of PCT/IE1999/000088: see s 88 of the Act. The parent application claims priority from Irish patent application 990584 filed on 12 July 1999. 8 Mainline filed the divisional application, as a divisional application of the parent application, on 10 October 2003: see s 79B of the Act. The divisional application also claims priority from the Irish application. 9 There is no dispute between the parties that 12 July 1999 is the priority date for the claims of the accepted parent specification and the claims of the accepted divisional specification. 10 Following acceptance of the parent application on 10 July 2003, three notices of opposition to the application were filed. The opponents were the three original parties in the first appeal. Those oppositions were successful on a number of grounds (the first decision). However, rather than refusing the parent application, the delegate allowed Mainline 60 days from the date of the decision to propose suitable amendments to overcome the adverse findings he had made. In this connection, the delegate was not prepared to hold that there was no patentable subject matter disclosed in the accepted parent specification that could not legitimately be brought into the claims by amendment. 11 On 3 August 2007, Mainline commenced the first appeal, as it was required to do if it wished to preserve its right to appeal to the Court: see O 58, r 4(2) of Federal Court Rules 1979 (Cth). 12 Mainline also accepted the delegate's invitation to file amendments. It filed a statement of proposed amendments on 5 September 2007. On 6 September 2007, the first appeal was, by consent of the parties, stayed until such time as the allowability of the proposed amendments was determined by the Commissioner. On 28 November 2008, leave to amend, as proposed, was granted by the Commissioner. The proposed amendments were advertised on 18 December 2008. 13 In the meantime, in a letter dated 22 May 2008, the Commissioner foreshadowed a re-examination of the divisional application on the basis that material raised in the oppositions to the parent application warranted that course. The re-examination was undertaken. On 24 November 2008, in the course of the re-examination, Mainline proposed a number of amendments to the accepted divisional specification. On 28 May 2009, leave to amend, as proposed, was granted by the Commissioner. The proposed amendments were advertised on 11 June 2009. 14 Following the advertising of proposed amendments to the accepted parent specification, five notices of opposition were filed. These were filed by the first respondent to the first appeal (which had changed its name to Fexco Merchant Services), the second respondent in the first appeal (First Currency Choice Pte Ltd), the third respondent in the first appeal (Travelex Outsourcing Pty Ltd), National Westminster Bank plc, and Australia and New Zealand Banking Group Limited. 15 Following the advertising of the proposed amendments to the accepted divisional specification, five notices of opposition were filed by the same parties who opposed the proposed amendments to the accepted parent specification. 16 The oppositions to the proposed amendments to the accepted parent specification and the accepted divisional specification were heard at the same time and determined on the same date, in separate reasons (the second decision and the third decision, respectively). 17 On 13 December 2011, Mainline commenced the second appeal. 18 Since these events, Mainline has assigned the parent application and the divisional application to Electronic Tax Free Shopping Limited (ETFS), which was joined as second applicant in each appeal on 16 December 2013. 19 On 4 May 2012, I made an order to the effect that all issues of construction of the accepted parent specification to be determined in the first appeal, insofar as and to the extent that those issues also concern the determination in the second appeal of the allowability of the proposed amendments, be heard and determined: separately from and before all other issues in the first appeal (including all other issues of construction of the accepted parent specification that might arise for the purpose of determining the first appeal), and together with the second appeal, with evidence in one appeal being taken as evidence in the other appeal. 20 The first appeal was otherwise stayed pending determination of the second appeal. 21 Thus, the focus of these reasons is the allowability of the proposed amendments to the accepted parent specification and the accepted divisional specification. To the extent that this question involves matters of construction that are common to the first appeal and the second appeal, the Court's findings on these matters apply to the determination of the first appeal. 22 Since the joinder of ETFS as second applicant in each appeal, Mainline has taken no active role in the proceedings. Indeed, it did not appear at the hearing of the second appeal or at that part of the hearing of the first appeal to which these reasons relate. Since the hearing, but before publication of these reasons, Mainline was removed as a party to each appeal and ETFS was substituted as the sole applicant in each appeal. For this reason, it is convenient to refer to ETFS as, simply, the applicant. 23 On 13 June 2013, First Currency Choice Pte Ltd advised the Court that, as fifth respondent in the second appeal, it intended to take no active part in that appeal for so long as the other respondents were defending that appeal. It stated that it would submit to any order made or judgment given by the Court in the second appeal as defended by the other respondents, save in relation to the question of costs. 24 The other respondents in the first appeal and in the second appeal, although represented by separate firms of solicitors, adopted a common position on the issues that arise for present determination and appeared at the hearing with common senior and junior counsel. Given this approach, it is not necessary to distinguish between the respondents in these reasons.

Witnesses 25 The respondents called David Ingham to give evidence at the hearing. Currently, Mr Ingham is a director of Ingham CS Pty Ltd, which provides strategic solutions to a range of financial institutions. He holds the degrees of Bachelor of Economics from the University of New England and Master of Business Administration from Macquarie University. He attended a Senior Executive Program at the London School of Economics in 2005. 26 Mr Ingham said that, over the past 20 years, he has worked for "a number of major banks, Australia's preeminent retailers and, more recently, as a provider of commercial and corporate strategic advice to a range of financial institutions, with a focus on card and payment systems in particular on credit, debit and charge cards". 27 Mr Ingham joined Westpac Banking Corporation (Westpac) in 1995 and was involved in the implementation of an activity-based costing project and a review of existing process standards for the bank's retail and operations network, including its card payment operations. This required Mr Ingham to review and understand domestic and international transaction process flows for "transactions occurring on Westpac issued cards and for transactions being acquired by Westpac". 28 From February 1997 to June 1999, Mr Ingham held the position of Senior Manager Operations, Card Products Group. His primary role was to develop and implement the operational strategies and efficiencies of this group. This included: overall responsibility for the operations of the card services delivered to the retail market by Westpac, including responsibility for the processing of both domestic and international card transactions; responsibility for the technology infrastructure supporting the cards business, the development of new systems, and technology to facilitate business and strategic advances; responsibility for business continuity, card production, and systems control and support, and industry representation at MasterCard, Visa and Bankcard committees. 29 Mr Ingham made clear in his evidence that his role was to ensure that the card payment network operated in accordance with Westpac's business rules and requirements. The working groups with which he was involved included representatives from Westpac's Information Technology team, who had responsibility for implementing the technical aspects of the new systems, including writing software to implement those systems. Mr Ingham was not involved in that particular activity. 30 From June 1999 to November 2002, Mr Ingham was Head of Operations, Commercial Services for Credit Union services Corporation (Australia) Ltd. 31 Mr Ingham made three affidavits that were read at the hearing. His evidence included what he described as "general knowledge in relation to card payment systems including for use in multi-currency environments and, in particular, methods for identifying an appropriate currency for individual transactions conducted using a card payments system (including systems for charge, debit and credit cards)" in Australia before the priority date. His evidence also included his understanding of the invention described and claimed in the parent specification as filed and the accepted parent specification, as well as the invention disclosed and described by the proposed amendments. Furthermore, he expressed an opinion about whether the amendments "sufficiently described the invention such that, based on the knowledge available to [him] and others in the card payment industry as at the [priority date], [he] would be able to perform the invention as claimed". 32 The applicant called John Mylordis to give evidence at the hearing. Mr Mylordis is the managing director of Nex Maxima Pty Ltd, which provides software and system design, engineering and development services. He holds the degrees of Bachelor of Science and Bachelor of Engineering from the University of New South Wales. 33 Since 1989, through his company, Mr Mylordis has undertaken 25 projects for the Commonwealth Bank of Australia. One of the largest projects was the development of Quickline 5, an electronic payment and accounting system for the bank's business clients. This system enabled businesses to perform a range of different transactions, including the back-end processing of credit card transactions. Mr Mylordis was the chief engineer on this project, with responsibility for the design of the user interface and software architecture. More recently, Mr Mylordis has worked with a number of other clients in the financial sector, including St George Bank, Westpac, AON Insurance, Wizard Home Loans and GE Money. 34 Mr Mylordis was provided with copies of the parent specification as filed, the accepted parent specification and the proposed amendments to the accepted parent specification. He gave evidence of his understanding of the invention described in each of these documents. He also gave evidence about "how [he] would go about implementing the method described in the documents" as at the priority date. 35 No objection was taken to the evidence in chief of either witness, although the parties reserved the right to make submissions as to the weight to be given to each witness' evidence. Each witness was cross-examined. 36 The respondents submitted that Mr Ingham is "a person skilled in the art", particularly having regard to the fact that the alleged invention relates to transaction processes within known card payment systems in existence at the priority date. They submitted that, at the priority date, Mr Ingham "understood how card payment systems operated, the numbering structure of cards, and the business and technical requirements for new or improved components". 37 On the other hand, the respondents submitted that Mr Mylordis' experience is "in the technical implementation of systems and not in the broader conceptualisation and design of these systems". They submitted that the evidence did not establish that Mr Mylordis has any relevant experience in the design or operation of card payment systems. 38 Nevertheless, the respondents accepted that, at the priority date, new or improved components of card payment systems were developed by working groups which included persons such as Mr Ingham as well as IT professionals who had "responsibility for implementing the technical aspects of the new systems and technology, for example writing software code to implement the new development". 39 The applicant accepted that Mr Ingham is a person with relevant expertise but submitted that, as a project manager in the Australian banking sector, Mr Ingham's role was the development of business requirements documents. The applicant submitted that the specifications in suit were tantamount to business requirements documents. It pointed to Mr Ingham's acceptance in cross-examination that, "once the business requirements have been conceived for the system design, [it is] the function of the software engineer to put that into practice". The applicant submitted that, once the business requirements have been conceived, a person in Mr Ingham's position "would have no further role to play in implementing the invention and the person to assist the court on the question of whether or not it could be implemented without undue experimentation, invention or prolonged study is the software engineer who would be charged with that implementation given the disclosures in the specification (equivalent to a business requirements specification)." The applicant submitted, therefore, that "Mr Mylordis' technical background is relevant to whether or not the skilled person could put the invention into effect without undue experimentation, invention or prolonged study". 40 I accept that Mr Ingham's knowledge of card payment systems at the priority date, about which he gave evidence, represents knowledge that the notional person skilled in the art in Australia would have had at that date. I regard Mr Mylordis to be representative of the IT professionals in the working groups to whom the respondents referred. I am satisfied that each witness has knowledge of the kind that can be taken as having been possessed by the person skilled in the art at the priority date, bearing in mind that, as a notional construct, the person skilled in the art can be accorded the attributes of a team of individuals to whom the patent specification is addressed. 41 Nevertheless, the evidence given by each witness as to his understanding of the invention disclosed in the specifications in suit (including as proposed to be amended) is problematic. Apart from the meaning of the term "Bank Identification Number" (BIN), about which Mr Ingham gave evidence, the parties do not suggest that there are terms of art or technical expressions in the specifications (including as proposed to be amended) about which either witness could give evidence. Therefore, apart from the meaning of BIN, and, more generally, Mr Ingham's background knowledge of card payment systems at the priority date, I do not think that either witness can properly give evidence about the meaning of expressions used in the specifications in suit or build upon his own understanding of those expressions to venture an opinion about what invention, if any, is disclosed. 42 That said, each witness's evidence as to his understanding of the disclosed invention is relevant to the extent that it provides the basis for his opinion as to whether the description in the accepted parent specification and accepted divisional specification, as sought to be amended, would be sufficient to enable the person skilled in the art to implement the invention, so understood. I have treated the evidence of each witness accordingly.

Background of the invention 43 The accepted parent specification, entitled "Dynamic currency conversion for card payment systems", 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. These 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. 44 The accepted parent specification describes a typical payment transaction by reference to the following flowchart (Figure 3): 45 The accepted parent specification gives the following description with respect to Figure 3 (errors in original): A flowchart demonstrating a typical payment transaction as shown in Figure 3, commences with entry of a payment card's details 30, the terminal makes a connection 31 with the authorisation host using its communications hardware and software 22. Typically, this connection 10 is made over a public telephone network or wireless link, any other communications may be used e.g. the Internet. Information concerning the card details and if required the transaction are passed 32 to the authorisation host. The authorisation host checks 33 to confirm that the card details are valid and that the transaction is permitted. If the card details are valid and the transaction value is permitted, the authorisation host sends 34 an authorisation code to the point of sale terminal which then allows 35 the transaction to proceed. Typically, a transaction slip is printed 21 for signature by the cardholder, whereas for an Internet transaction a conformational HTML page or e-mail may be forwarded to the cardholder. Optionally, some systems may provide an option 36 enabling a merchant to cancel 37 a transaction at this stage. If the authorisation host decides that the card details are invalid or that the transaction is not permitted then no authorisation code is given and the authorisation host informs 39 the terminal that the transaction is not allowed to proceed. The terminal typically outputs 40 an error message to this effect. If approved and the transaction is completed, then details of the transaction are stored 38 in the terminal 1 in a transactions table 23. 46 The accepted parent specification further explains that, as required, the terminal connects to a collection host and transmits details from the transactions table to the collection host. Typically, the terminal prints a report for the terminal user detailing the transactions that have been transmitted. Eventually, these details are passed from the collection host to a clearing bank, which sorts the transaction details according to the card scheme used for the transaction. The clearing bank forwards the transaction details to the appropriate card scheme, which sorts the transactions according to card issuers (issuers), which are, typically, banks or other financial institutions. The transactions for a given issuer are entered into that issuer's computer system. The issuer then assigns the details of each transaction to the account of the cardholder to whom the issuer has issued the card involved in the transaction. 47 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. 48 The accepted parent specification exemplifies another disadvantage (remembering that the parent application claims a priority date of 12 July 1999): Furthermore, with the introduction of the EURO, the potential for conducting transactions in the multi-currency environment has increased. Each country participating in the European Monetary Union (EMU) will have in co-existence two currency units the EURO and the national currency for a transition period. As the transition period is quite long, it is inevitable that different issuers and merchants will convert their base currency from the national currency unit to the EURO at different times, with the inevitable result that merchant and consumers may be using different currencies. In addition, the growth of Internet commerce permits consumers to purchase from a greater variety of sources than was previously available. A large proportion of these on-line transactions will be conducted in currencies other than that of the cardholder. 49 The accepted parent specification says that, for these reasons, 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. 50 The accepted parent specification notes that systems, including point of sale systems, are available which permit multi-currency transactions in which the cardholder may use the currency of his or her choice. However, it also notes the following problem: A problem with these existing systems is that the merchant must enter the desired currency for the transaction into the system. In order to do this the merchant must determine the currency of the cardholder and check to see if this currency is permitted. This involves the merchant looking at the card and/or cardholder and attempting a determination of what country the cardholder is from. This determination requires action and some intelligence on the part of the merchant. In addition, with the advent of the Internet the point of sale is the computer, no human merchant may be involved and the payment card is not available for inspection. This also applies for transactions conducted from a distance by other means, e.g. fax or phone. 51 The accepted parent specification says that, for these various reasons, it would be advantageous if a method and system could be provided for determining the currency of a cardholder at the point of sale automatically, using only a payment card's details. 52 The accepted parent specification then goes on to describe a process which provides electronic access to pre-paid funds for cash or payment for goods and services, in which a card is issued to a customer with a value that can be selected by the customer. 53 For that process, the accepted parent specification discloses the use of a card with a magnetic stripe that contains an encoded card number, including a BIN and an account number. It is common ground that, at the priority date, and at the present time, a BIN comprises six digits, the first of which identifies the card scheme or card company, with the remaining five digits identifying the issuer of the card. 54 It is convenient, at this point, to introduce the concepts of card schemes and card companies. 55 A card scheme is a card payment association in which banks and other financial institutions operate as members. Visa and MasterCard are examples of card schemes. A member of a card scheme acts as either the issuer of a card or the acquirer of card transactions (i.e. it processes payments for the merchant). A card company is a financial institution that acts as both the issuer of a card and the acquirer of a card transaction. American Express is an example of a card company. 56 Mr Ingham gave evidence, which is not disputed, that, 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). 57 Mr Ingham used the Visa card scheme as an illustration of the card numbering structure typically employed by card schemes and card companies. Once again, this evidence was not disputed. He said that the Visa rules provide for the following card numbering structure: An individual BIN will be allocated to the issuer by Visa. In the case of the Visa scheme, the first digit would generally be the numeral "4". The issuer will produce cards with a total card number length of between 13 and 16 digits. The first six digits of the card will be the BIN that has been allocated by Visa. The last digit on the card 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 the seventh digit, up to and including the penultimate digit, represent the account number of the cardholder with the issuer. 58 Mr Ingham said that, in all card schemes, the issuer is allocated an individual BIN or a range of BINs within a payments network to allow other parties within the network to identify the institution that issued the card to the cardholder. 59 The proposition that a range of BINs might be allocated to an issuer was disputed by the applicant and was the subject of cross-examination. Under cross-examination, including by reference to International Standard ISO/IEC 7812, Mr Ingham maintained that, as a practical matter, both before and after the priority date, card schemes did allocate multiple BINs to an issuer. I do not think that this factual dispute is one that requires resolution in this proceeding. 60 Mr Ingham gave the following evidence as to the importance of the BIN to the processing of transactions completed on payment cards: 36. This BIN was, and is, critical to the correct matching of a card to the issuer of this card as it allows for the directing of transactions through a payments process. It is a fundamental part of the infrastructure and design of card payment systems, and has always been so. BINs are designed precisely for the purpose of identifying the issuer of a card (together with the card scheme/card company through the first one or two digits of the BIN) and directing transactions through card payment systems and networks. This was the case at the [priority date] (and indeed for at least a decade beforehand) and remains the case now. 61 Mr Ingham described the typical transaction process using a payment card, from presentation of the card to the merchant by the cardholder in order to make a purchase, to payment into the merchant's nominated account of the value of the transaction. 62 With regard to currency conversions, Mr Ingham gave the following evidence: 41. In the instance of transactions occurring in a currency other than the currency associated with the BIN, the currency conversion occurred during the transaction process, normally at the card scheme or card company. A currency conversion occurred between a merchant's currency and the currency associated with the BIN. 42. In some instances this conversion involved multiple conversions, for example from the merchant currency to US dollars and then from US dollars to the currency associated with the BIN. 43. For transactions requiring currency conversion, settlement with the merchant typically occurred in the currency of the merchant. This was the case at the [priority date] and, in general, remains the case now. 44. The BIN was critical within this process to ensure that settlement instructions and values were sent correctly between the merchant, the cardholder and their respective acquirer or issuer, The reason for this is that, as explained above, the BIN identifies the issuer of the card and, through the first one or two digits of the BIN, the relevant card scheme or card company. BINs and BIN tables were (and are) universally used by all consumer card payment systems to perform this identification role. This is still the case today.

The invention disclosed in the accepted parent SPECIFICATION

Introduction 63 I discuss the legal requirements for amendment (s 102 of the Act) in later paragraphs of these reasons: see [128]-[134]. For present purposes, it is important to note that, 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 necessary to distinguish between the form of a complete specification as filed (meaning, as initially or originally filed) (here, the parent specification as filed), and the form of the (amended) complete specification (here, the accepted parent specification) that is sought to be (further) amended. 64 Save for some differences, the parties proceeded on the basis that the description of the invention in the parent specification as filed is materially the same as the description of the invention in the accepted parent specification. The position taken by the parties in the course of final submissions was that, for the purpose of determining the allowability of the proposed amendments to the accepted parent specification, nothing turns on the differences between the parent specification as filed and the accepted parent specification, other than the following two differences: the flow diagram in Figure 10 of the parent specification as filed does not refer to a "BRT table" but to a "BIN table", and unlike the accepted parent specification, the parent specification as filed makes no separate reference in the body of the specification to the existence of a BIN, when describing the prior art. 65 The applicant submitted that, as there is no reference to a BIN in the description of the body of the parent specification as filed, the reference in Figure 10 to "BIN table" is an obvious error; the reference should have been to "BRT table". In light of my findings in relation to what is disclosed in the accepted parent specification and the parent specification as filed (see [82] and following), it is not necessary for me to determine whether that particular contention is correct. 66 There are other differences between the parent specification as filed and the accepted parent specification. The accepted parent specification contains consistory statements and corresponding claims that differ from the consistory statements and corresponding claims in the parent specification as filed. The parties did not place any particular emphasis on these differences, perhaps because of the particular competing interpretations they sought to place on the accepted parent specification. The fact that there are such differences should, however, be noted. Where relevant, I will refer to them. 67 The parties also proceeded on the basis that, for present purposes, the description of the invention in the accepted divisional specification is materially the same as the description of the invention in the accepted parent specification. 68 It is convenient, therefore, to focus primarily on the accepted parent specification to identify and discuss what is disclosed and described therein as the invention. 69 Before doing so, it is desirable to set out, by way of broad overview, the competing interpretations placed on the accepted parent specification (and, by implication, the parent specification as filed) by the parties and the relevant aspects of the delegate's conclusions in that regard.

The applicant's interpretation 70 It will be necessary, in later paragraphs of these reasons, to refer in detail to certain passages in the accepted parent specification in order to deal with the parties' respective contentions. For present purposes, it is sufficient to note that the accepted parent specification refers variously to an "identifier code", an "issuer code" and an "issuer identifier code" when describing how an extracted code from the payment card details is used for the purposes of automatically setting the currency for the transaction with the merchant. 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.

The respondents' interpretation 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. 74 The respondents adduced the following evidence through Mr Ingham, speaking at the priority date: Issuers of cards were, and still are, allocated an individual BIN or, as I have noted, a range of BINs within a payment network to allow other parties within the network to identify the issuer of the card to a particular cardholder. BIN tables were, and still are, used to identify the issuer of a card and the currency associated with the BIN. This is done by matching the BIN taken from the card with a BIN listed in the BIN table. BIN tables were, and still are, created by card schemes and card companies and held by issuers, acquirers and processing bureaux, as well as by card companies and card schemes themselves. A processing bureau is an entity which routes card transactions to cardholders' banks (issuers) and merchants' banks (acquirers). Generally, the bureau will forward a transaction to the issuer so that the issuer can then approve or decline the transaction. Sometimes, a processing bureau will authorise the transaction on behalf of the issuer. Each BIN listed in a BIN table has a single currency associated with it, which is normally the currency of the country in which the issuer issues the card to the cardholder. 75 Mr Ingham said that he could not recall seeing an entry in a BIN table in which the currency associated with a BIN is not the currency of the country in which the issuer issued the card to the cardholder, although he recognised that there might be some exceptions to this general position. He said that if, before the priority date, an issuer needed to issue cards with different currencies - for example, if the issuer operated in two or more countries - the issuer would obtain separate BINs. 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. 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.

The delegate's first decision 78 In the first decision, which upheld the oppositions to the grant of the parent application (Fexco Dynamic Currency Conversion Limited v Mainline Corporate Holdings Limited [2007] APO 24), the delegate found that the claims of the accepted parent specification were "significantly flawed on several points of clarity". He also found that several claims failed for lack of novelty and lack of inventive step. 79 The issues of clarity are the matters of concern in this hearing, particularly the meaning to be given to the terms "identifier code", "issuer code" and "issuer identifier code", as used in the accepted parent specification. The delegate found that, in this regard, all claims inadequately distinguished between these codes and their interrelationship, noting that, in various parts of the accepted parent specification, the terms appear to have been used interchangeably. Relatedly, the delegate found that the claims inadequately define the content and operation of the BRT, which is an important element of the invention. In passing, the delegate observed (at [72]): 72. … The specification is very light on describing an invention that comes even close to what Mainline presented at the hearing. 80 The delegate also found that the terms "preferred currency" and "operating currency", in the accepted parent specification, appear to have been used interchangeably. The delegate considered that if these terms are intended to have separate meanings, the steps that linked the terms are inadequately defined in the claims. 81 Finally, the delegate found other minor errors in the accepted parent specification, which are not significant for present purposes.

What is disclosed and described in the accepted parent specification? 82 I have already summarised relevant passages from the accepted parent specification that describe the background to the invention: see [43]-[53] above. Following these passages, the accepted parent specification gives a brief summary of the invention by reference to, amongst other things, a number of consistory statements. 83 The first two consistory statements support, respectively, claims 1 and 14 of the accepted parent specification, and, subject to minor contextual differences, reflect the wording of those claims. These consistory statements, and the corresponding claims, do not appear in the parent specification as filed. 84 The consistory statement supporting claim 1 is (errors in original): According to one aspect of the invention a data processing method for determining a preferred currency for association with charge, debit or credit card transaction between a merchant and a charge, debit or credit card cardholder comprising the steps of: obtaining the card number of the card from the cardholder, wherein the method further comprises the steps of; identifying an identifier code from said card number; determining the operating currency for said identifier code, by comparing said identifier code with entries in a table, wherein each entry in the table contains an issuer code or range of issuer codes and a corresponding currency code; and setting the currency for association with the card transaction as the determined operating currency for the issuer code. 85 This statement distinguishes between an "identifier code", which is taken from the card number, and an "issuer code" which is an entry in a table. The statement identifies a step of "determining the operating currency for said identifier code". The statement also refers to a step of setting a currency for the card transaction as "the determined operating currency for the issuer code". Thus, at one level, the statement identifies a currency determined for the identifier code and a currency determined for the issuer code. Does this mean that, at least conceptually, there is a separate currency for the identifier code and a separate currency for the issuer code? Are the identifier code and the issuer code the same thing, so that, conceptually, only one currency is identified? 86 When the consistory statement is read as a whole, and when it is construed in the context of the specification as a whole, particularly with reference to certain passages which I discuss in detail below, I am satisfied that it discloses that the identifier code and the issuer code are conceptually distinct. The identifier code is taken from the card number. This code is then compared with entries in the table. Each entry in the table has an issuer code and a corresponding currency code. Thus, the identifier code is compared, by some means, with each issuer code and its corresponding currency code. By that comparison, a relationship is recognised between the identifier code and the issuer code which, by reference to the corresponding currency code, enables the currency for the transaction to be set. 87 However, it is also clear that the statement is referring to only one currency. The statement describes this as "a preferred currency for association with … [a] card transaction", "the operating currency" and "the currency for association with the card transaction". It is tolerably clear that each description of the currency refers to the same conceptual entity. 88 Moreover, when the statement refers to "the operating currency for said identifier code", it means the currency determined by the steps to which I have referred. In this sense, it can be seen that it is not inapposite to also refer to the currency having been determined for the issuer code, bearing in mind the relationship between the identifier code, the issuer code and the currency code, which leads to the currency for the transaction being set. 89 The consistory statement supporting claim 14 is (errors in original): According to the second aspect of the invention a system for use with a charge, debit or credit card transaction between a merchant and a charge, debit or credit card cardholder; having means for obtaining the card number of the card from the cardholder, wherein the system has means for determining a preferred currency for association with the transaction comprising: means for identifying an identifier code from said card number; means for determining the operating currency for said identifier code by comparing said identifier code with entries in a table, wherein each entry in the table contains an issuer code or range of issuer codes and a corresponding currency code, and means for setting the currency for association with the card transaction as the determined operating currency for the identifier code. 90 Consistently with the first consistory statement, the second consistory statement also distinguishes between an "identifier code" and an "issuer code". The second consistory statement describes a system whose features are substantially the same as the steps of the method described in the first consistory statement. However, unlike the first consistory statement, the second consistory statement does not refer to a currency that has been determined for the issuer code. It only refers to a currency that has been determined for the identifier code. Given the relationship between the identifier code, the issuer code and the currency code, this difference between the first consistory statement and the second consistory statement is not significant. 91 There are a number of passages in the accepted parent specification that sit awkwardly with these consistory statements. 92 For example, following the first two consistory statements (and two other consistory statements, which are not relevant to the present discussion), the specification says (emphasis added): Thus the method for determining a preferred currency for association with a payment card transaction between a merchant and a payment card cardholder comprises the steps of obtaining the card number of the payment card from the cardholder, identifying an issuer code from said card number, determining the operating currency for said issuer code, and setting the currency for association with the payment card transaction as the determined operating currency for the issuer code. 93 Later, the specification describes a typical transaction cycle in the following terms (emphasis added): A typical transaction cycle is now described, commencing when the cardholder offers their payment card to the merchant as a means of payments for goods or services. The merchant typically swipes 205 the card in the magnetic stripe reader of the point of sale terminal. The reader extracts 205 the card number, expiry date and the name of the cardholder from the card. The terminal software searches through the bank reference table and checks 210 for an entry corresponding to the issuer code obtained from the card number. If an entry is found the currency for the transaction is set 215 to that of the payment card. If no entry in the bank reference table is found the currency is set 220 to that of the merchant. 94 The specification describes one embodiment of the invention as follows (emphasis added): In one embodiment an apparatus is provided having means for determining a preferred currency for association with a payment card transaction between a merchant and a payment card cardholder, said means comprising; means for obtaining the card number of the payment card from the cardholder, means for identifying an issuer code from said card number, means for determining the operating currency for said issuer code, and means for setting the currency for association with the payment card transaction as the determined operating currency for the issuer code. 95 The specification also describes an alternative embodiment of the invention which includes the following steps (emphasis added): …If the transaction is authorised, the authorisation host extracts the issuer code from the payment card details and checks 425 the extracted issuer code against entries in the bank reference table. If no entry is found in the bank reference table or if the currency associated with the issuer is the same as that of the merchant then the transaction details are unchanged and forwarded 435 back to the terminal along with the authorisation code. Alternatively, the host may simply send the authorisation code as the terminal already has the transaction details. If an entry is found in the bank reference table and the currency associated with the issuer is different from that of the merchant, the transaction amount is converted 420 to an equivalent amount in the associated currency… 96 These passages of the accepted parent specification make no mention of an identifier code. Only an issuer code is referred to. Moreover, this is the code that is said to have been taken, obtained or extracted from the card number and compared with entries in the table. 97 The applicant referred to these passages as "exceptions". I do not think that they can be so readily dismissed, particularly as they also appear in the parent specification as filed, whereas the consistory statements which I have discussed are not in that specification. Regardless of whether these passages are truly exceptions, there are other passages in both the accepted parent specification and the parent specification as filed which do distinguish between an identifier code and an issuer code in the same way in which the two consistory statements distinguish those codes. 98 Significantly, both the accepted parent specification and the parent specification as filed contain the following description of the invention with reference to Figure 5: A flowchart of the operation of the present invention is illustrated in Figure 5, in which an identifier code is extracted 50 from the payment card details. In the preferred embodiment, the identifier code consists of a portion of the payment card number. 99 Figure 5 is: 100 The description continues: Typically, payment card issuers are assigned a range of card numbers for issuing cards to customers. For example a small bank may be assigned the range 4555999033300000 to 45550999033399999, whereas a larger bank may be assigned 4555998800000000 to 4555998819999999. Accordingly, the identifier code is the portion of a card number, which distinguishes between issuers. 101 At the priority date, the person skilled in the art would understand these passages to disclose and describe the following matters. 102 First, in these passages, and more generally with the example given, the specification is talking about the invention, not an existing card scheme or system. There is no apparent requirement for the invention to conform to any existing card scheme or system. 103 Secondly, the second sequence of numbers in the first given range (i.e. the range of assigned numbers given to the "small bank") contains an error. The sequence erroneously includes the digit "0" after the numerals "455…". The sequence should read "4555999033399999". Ultimately, both witnesses recognised this error. I am satisfied that, at the priority date, the person skilled in the art would have recognised this error. 104 Thirdly, and importantly, the identifier code is disclosed and described as the portion of the card number that distinguishes between issuers. This means that, in the case of the small bank, the identifier code is "45559990333" whereas, in the case of the larger bank, the identifier code is "45559988". As each exemplified identifier code is more than six digits, it follows that the identifier code of the invention is not simply a BIN. Indeed, in the example given, the leading six digits could not function as an identifier code because they contain the same sequence of numbers for both the small bank and the larger bank and would not, therefore, distinguish between those banks as issuers. In each case, the remaining portion of the card number (i.e. after the identifier code) distinguishes between the issuer's customers. 105 Fourthly, there is only one identifier code for the range of card numbers assigned to the issuer. 106 The description continues: The identifier code is compared 51 with entries in a bank reference table (an example of which is shown in Figure 6), which contains a list of issuer identifier codes. Each issuer identifier code 60(1-n) in the table has an associated entry 61(1-n) containing an associated currency, which corresponds to the currency of payment of cardholders accounts of the issuer. For example, if the issuer is an Irish Bank then the associated currency may be Irish Pounds or EUROs, similarly if the issuer is a UK bank then the associated currency is probably pounds Sterling. The bank reference table may be created from a number of sources, including the card scheme administration organisations or from data collected from a large number of cardholders. 107 Figure 6 is: 108 At the priority date, the person skilled in the art would understand these passages to disclose and describe the following matters. 109 First, the expression "issuer identifier code" is introduced. However, as a later passage in the description shows ([113] below) the expressions "issuer identifier code" and "issuer code" are used synonymously and interchangeably. This part of the description maintains, therefore, the conceptual distinction between the identifier code and the issuer code referred to in the two consistory statements. 110 Secondly, the process identified in the two consistory statements is also here described. The identifier code is compared with entries in a table (here called a bank reference table, i.e. the BRT). The BRT contains a list of issuer codes/issuer identifier codes with an associated currency. 111 Thirdly, when regard is had to Figure 6, the entries corresponding to the issuer codes/issuer identifier code are all five digits. Thus, the issuer code/issuer identifier code is not a BIN. Further, in the example given, the identifier code and each issuer code/issuer identifier code in the BRT with which the identifier code is to be compared, is a different length and has a different numerical sequence. Thus, the identifier code and the issuer code/issuer identifier code are not necessarily the same length and do not necessarily have the same numerical sequence. However, there is nothing in this description, or elsewhere in the specification, which says that the identifier code and the issuer code/issuer identifier code cannot be the same length or have the same numerical sequence. 112 I should add here that one possible reading of Figure 6 is that the issuer codes/issuer identifier codes shown in the table relate to the account numbers of the small bank's customers. The parties did not advance this as a possible construction of Figure 6. Further, this is not how either witness understood the figure. Mr Ingham saw the entries in Figure 6 as truncated versions of BINs, not account numbers of customers. Mr Mylordis did not agree with Mr Ingham's construction. He said that the entries in Figure 6 were hypothetical and that the issuer code/issuer identifier codes were not necessarily five digits long. He saw Figure 6 "as a simple demonstration of the look-up logic in the BRT table". However, importantly, he did understand the example, of which Figure 6 is part, as disclosing that the small bank and the larger bank only issue cards in one currency and that this was identified, in the case of the small bank, by the leading 11 digits of the assigned card numbers and, in the case of the larger bank, by the leading 9 digits of the assigned card numbers. 113 The description continues: If no entry is found in the bank reference table for the identifier code of the issuer of the card, then the transaction will be processed 53 as before in the prior art. If an entry is found for the identifier code, the associated currency corresponding to the issuer code is extracted and the transaction is processed with enhanced functionality 54 using the associated currency. A variety of enhancements are available, when the currency of the payment cardholders account is known. 114 At the priority date, this part of the description would tell the person skilled in the art that the issuer code and the issuer identifier code are the same conceptual entity and that the expressions are used in the description synonymously and interchangeably. It would also confirm that there is only one identifier code for the range of card numbers assigned to the issuer. 115 When the description of the invention with reference to Figures 5 and 6 is considered as a whole, the person skilled in the art would understand the specification as disclosing and describing a system or method in which there is only one currency associated with the range of card numbers assigned to the issuer for issuing cards to its customers. This conclusion is a function of the fact that, as disclosed by the example, there is only one identifier code for the range of card numbers assigned to the issuer and that it is this code that is matched to an issuer code/issuer identifier code with its associated currency in the BRT. Indeed, this is precisely what the specification says: Each issuer identifier code… in the table has an associated entry … containing an associated currency, which corresponds to the currency of payment of cardholders [sic] accounts of the issuer. 116 In this connection, reference should also be made to another description of the BRT which is found in both the accepted parent specification and the parent specification as filed: The bank reference table is a table that stores the leading digits of individual issuers of credit/debit cards in the world and identifies an associated currency code for each issuer. 117 In short, there is only one currency associated with the range of card numbers assigned to the issuer. 118 The applicant advanced an alternative interpretation based on the passage referred to at [106] above, which teaches that if, for example, the issuer is an Irish bank "then the associated currency may be Irish pounds or Euros" and that if the issuer is a United Kingdom bank then the associated currency is "probably pounds sterling". The applicant submitted that this passage "expressly recognises the possibility of a bank holding cardholders' accounts in different currencies". 119 The passage relied upon by the applicant does not support that interpretation. Read in context, the passage is only talking about one associated currency which, in the case of the Irish bank may be either Irish pounds or Euros and, in the case of the United Kingdom bank, is "probably" pounds sterling. I am satisfied that the description of the identifier code and its function, including its relationship to an associated entry in the BRT, speaks of only one currency associated with the assigned range of card numbers. This currency is the alternative to the merchant's currency. 120 Moreover, the interpretation for which the applicant contended in submissions is at odds with its own evidence on this topic. As I have already noted, Mr Mylordis' evidence of his understanding of this part of the specification was that the small bank and the larger bank only issue cards in one currency. It is useful to record his evidence on this point: In this example, it is my understanding that the small bank and the larger bank only issue cards in one currency. Accordingly, mapping the currency via an identifier code that distinguishes between these two issuers is sufficient to identify cardholders' currencies. I also note that, in this example, all card numbers beginning with the numbers 4555 9990 333 are allocated to the small bank. This means that in order to distinguish cards issued by the small bank from cards issued by other issuers and in other currencies, it would be necessary to look at the first 11 digits of the cards. In the case of the larger bank, it has been allocated all card numbers beginning with 4555 9988 0 and 4555 9988 1. In order to distinguish cards issued by this larger bank from cards issued by other issuers and in other currencies, it would be necessary to look at the first 9 digits of cards. Therefore, in the example at page 10, lines 10 to 14 of the [accepted parent specification], the identifier code must be at least 11 digits long. 121 For the sake of completeness, I should record that the applicant drew attention to other passages in the accepted parent specification, particularly with respect to Figures 3, 8 and 10, and advanced a number of additional submissions to demonstrate that the invention disclosed and described in the accepted parent specification (and, by implication, the parent specification as filed) is not one that is restricted to the use of BINs. As I have accepted that general submission, I do not propose to summarise these additional references and submissions.

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.

The legal requirements for amendment 128 An applicant for a patent may, subject to the Act and the Patents Regulations 1991 (Cth) (the Regulations), ask the Commissioner for leave to amend a complete specification for any purpose: s 104(1). Any person may, subject to and in accordance with the Regulations, oppose allowing an amendment: s 104(4). The Commissioner must not allow an amendment that is not allowable under s 102 of the Act: s 104(5). 129 Section 102(1) of the Act provides: An amendment of a complete specification is not allowable if, as a result of the amendment, the specification would claim matter not in substance disclosed in the specification as filed. 130 Section 102(2) of the Act provides: An amendment of a complete specification is not allowable after the relevant time if, as a result of the amendment: (a) a claim of the specification would not in substance fall within the scope of the claims of the specification before amendment; or (b) the specification would not comply with subsection 40(2) or (3). 131 In relation to an amendment proposed to a complete specification relating to a standard patent, as is the case here, "the relevant time" for the purposes of s 102(2) is after the specification has been accepted. 132 Section 40(2)(a) of the Act provides: A complete specification must: … describe the invention fully, including the best method known to the applicant of performing the invention; 133 Section 40(3) of the Act provides: The claim or claims must be clear and succinct and fairly based on the matter described in the specification. 134 In Bristol-Myers Squibb Co v Apotex Pty Ltd (2010) 87 IPR 516, I discussed the legal requirements of s 102 of the Act in relation to proposed amendments to a complete specification filed in respect of an application for a standard patent. The following paragraphs ([38]-[40]) of those reasons provide a convenient summary of the requirements of s 102(1) and s 102(2)(a): 38. Consideration of the prohibition in s 102(1) of the Act requires a comparison between what would be claimed as a result of the proposed amendment and what is disclosed in the specification as filed. The steps involved in this comparison were described in RGC Mineral Sands Pty Ltd v Wimmera Industrial Minerals Pty Ltd (1998) 89 FCR 458 at 466C-E. As there emphasised, the key point is that the words "as a result of the amendment" in s 102(1) are not to be confused with the expression "after the amendment". The amendment is identified by considering the specification as it stands with how it would stand after the proposed amendment. It is only by that step that one can determine what matter results from the amendment. Once that is determined, the next step is to read the specification as a whole (that is, amended in the manner proposed) and to compare it with what is "in substance disclosed" in the specification as filed. If by reason of the amendment proposed, and for no other reason, the specification would then claim matter not in substance disclosed in the specification as filed, the amendment would not be allowable. 39. As to the notion "in substance disclosed", the Full Court in ICI Chemicals & Polymers Ltd v The Lubrizol Corporation Inc (2000) 106 FCR 214 at [118] referred to the close relationship between that notion and the test for fair basis, saying that it would be a rare case where a claim which claims matter in substance disclosed in the specification as filed is not, equally, fairly based on the matter described in the specification: see also Gambro Pty Ltd v Fresenius Medical Care South East Asia Pty Ltd (2000) 49 IPR 321 at [18] where the two requirements were said to be "very similar". In Ethyl Corporation's Patent [1972] RPC 169 at 195, Lord Denning MR said that the requirements were "virtually the same", although in Lubrizol the Full Court thought it unnecessary to go that far. It is thus expedient to test whether matter is "in substance disclosed" in the specification as filed by asking whether there is a "real and reasonably clear disclosure" of that matter. 40. Consideration of the prohibition in s 102(2)(a) requires a comparison between the proposed new claims and the claims of the specification immediately before amendment. Once again, the prohibition is conditioned on a state of affairs existing as a result of the amendment, namely that a claim would not in substance fall within the scope of the claims before amendment. Thus the identification of the amendment is, once again, an important first step. Moreover, the reference to "within the scope of the claims" before amendment is significant. The comparison is not between a particular amended claim and that claim before amendment. The expression "within the scope of the claims" directs attention to all the claims. For this reason a practical test is to ask whether an amendment makes anything an infringement which would not have been an infringement before the amendment. If the answer is "yes", the amendment is proscribed by s 102(2)(a) of the Act: AMP Incorporated v The Commissioner of Patents (1974) 3 ALR 283 at 289-290; Fina Research SA v Halliburton Energy Services Inc (No 2) (2003) 127 FCR 561 at [29]; W J Voit Rubber Corp's Application, Re (1965) AOJP 1752 at 1754-1755.

The framework proposed by the parties for considering the proposed amendments 135 The parties classified the proposed amendments to the accepted parent specification and the accepted divisional specification according to broad categories, rather than dealing with the proposed amendments individually. This is both understandable and convenient, given the large number of amendments proposed. 136 The applicant submitted that the amendments in dispute between the parties fall under the following categories: amendments to clarify that the method and system described and claimed in the specifications are directed to identifying the currency of the cardholder's account, and amendments to clarify that the method and system described and claimed in the specifications are directed to identifying a currency for use with a payment card transaction, which is the currency associated with the code obtained from the card number; that the code obtained from the card number is consistently referred to as the "identifier code"; and that the code that comprises each entry in the BRT is consistently referred to as the "issuer identifier code". 137 The applicant also produced a table which identified similar categories of amendments. The table identified another category - amendments that clarify that the method described and claimed in the accepted parent specification is "automatic". Some amendments were assigned to more than one category. 138 The respondents submitted that the amendments fall under the following categories: Codes - proposed amendments relating to the use and meaning of the terms "issuer code", "identifier code" and "issuer identifier code". Currencies - proposed amendments relating to the use and meaning of the term "currency" when used in relation to a currency that is not the currency of the merchant. Automatic - proposed amendments inserting the term "automatically" into the claims and body of the specification. Mistakes - proposed amendments to correct mistakes in, and introduce formatting changes to, the specification. 139 Although the respondents did not more particularly identify the amendments that fall into each of its categories, I have proceeded on the basis that the "codes" and "currencies" amendments are the same amendments as those covered by the applicant's categories identified in [136] above. 140 The respondents did not direct any specific submissions to its "automatic" and "mistakes" categories. Indeed, they did not press their opposition to amendments in the "automatic" category. I do not understand them to have pressed any opposition to amendments in the "mistakes" category. I will confine my attention, therefore, to the "codes" and "currencies" categories.

Overview of the parties' contentions 141 The applicant submitted that the amendments proposed to the accepted parent specification describe a method and system for the automatic determination of a cardholder's currency at the point of sale. According to the applicant, the method and system include the steps of: identifying a code from the card number; comparing the code obtained from the card number with entries in a table wherein each entry in the table contains a code and a corresponding currency code, and setting the currency for association with the card transaction as the currency associated with the code obtained from the card number. 142 The applicant submitted that the amendments contemplate that the code extracted from the card number is not restricted to a BIN and that the BRT is not restricted to a BIN table. 143 The applicant submitted that there is a real and reasonably clear disclosure in the accepted parent specification of the disclosed invention and that the proposed amendments do not change the invention. 144 The respondents submitted that the cumulative effect of the "currencies" and "codes" amendments is that new matters are being claimed that were not disclosed in the parent specification as filed. In essence, the respondents submitted that the proposed amendments extend the invention to a method and system that provides for the currency of payment of cardholders as distinct from the currency of different issuers. The respondents submitted that the proposed amendments show that the invention now contemplated is no longer a method or system that identifies an associated currency code for each issuer, but an associated currency code for each "currency of payment of cardholders' accounts".

The delegate's decisions on the proposed amendments

The delegate's second decision 145 In the second decision, which refused the amendments to the accepted parent specification (Fexco Merchant Services v Mainline Corporate Holding Limited [2011] APO 95), the delegate noted that amendments had been proposed not only to the claims, but to the description of the invention and to one of the figures (Figure 6). 146 The delegate rejected Mainline's contention that the amendments had been proposed for correcting clerical errors or obvious mistakes. The amendments, therefore, did not enjoy the exemption provided by s 102(3). The amendments were only allowable if they satisfied the legal requirements of s 102(1), s 102(2)(a) and s 102(2)(b) of the Act. 147 With respect to s 102(1), the delegate found that the amendments proposed to the description of the invention fundamentally change the invention disclosed in the accepted parent specification from one in which the currency set for the transaction is the issuer's currency to one in which the currency set for the transaction is the cardholder's currency. I discuss this distinction below: see [162]-[170]. The delegate reasoned at [56] that the problem was not so much the amendments to the claims, but rather: 56. … the amendments to the descriptive part of the specification to alter the definition and consequential operation of the identifier code, with such code being referred to throughout the claims, that results in the claims claiming matter not in substance disclosed in the specification as filed. 148 The delegate concluded, therefore, that the proposed amendments contravene s 102(1) of the Act. 149 With respect to s 102(2)(a), the delegate said (at [62]-[63]): 62. It is clear from the previous section that the proposed amendments re-define the identifier code to avoid it being interpreted as just an identifier of the issuer. Furthermore I noted the re-definition would extend the scope of the identifier code from being merely considered a BIN or similar identifier code. The amendment would also claim an identifier code that is more sophisticated to determine appropriate currencies of cards from issuers that issue cards in more than one currency. 63. While the scope of the claims themselves may not appear significantly different before or after amendment, this re-definition of the identifier code makes the claims go beyond the scope of the claims before amendment. Additionally the evidence from all parties indicates the BIN was a well known instrument in the card payments industry before the priority date and was known to be of fixed length across the industry. The re-characterisation of the identifier code as a variable length code, depending on the nature of the issuing bank and/or on the contents of the BRT, substantiates even further that the claims, wherever the identifier code is mentioned, have gone beyond the scope of the claims before amendment. 150 The delegate concluded, therefore, that the proposed amendments contravene s 102(2)(a) of the Act. 151 With respect to s 102(2)(b) the delegate noted (at [67]) that the opponents "broadly submitted" that the amendments contravene s 40(2)(a) relating to the full description of the invention, and s 40(3) relating to clarity of the claims. 152 At [69], the delegate said: 69. The opponents' expert declarants clearly had trouble with this whole altered concept of the identifier code. The concept is not fully described and the claims as a whole are not clear either as a result. I conclude the proposed amendments contravene subsection 102(2)(b).

The delegate's third decision 153 The reasoning and conclusions in the third decision, which refused the amendments to the accepted divisional specification (Fexco Merchant Services v Mainline Corporate Holdings Limited [2011] APO 96), are materially the same as those expressed by the delegate in the second decision with respect to the refusal of the amendments to the accepted parent specification. The delegate concluded that the amendments to the accepted divisional specification contravene s 102(1), s 102(2)(a) and s 102(2)(b) of the Act.

Do the proposed amendments satisfy the legal requirements?

The amendments proposed to the accepted parent specification 154 If the proposed amendments were directed merely to standardising the text of the accepted parent specification and/or to providing a more detailed description of the invention disclosed and described therein, then there would be little room to argue that the invention described by the amendments is not the invention disclosed in the parent specification as filed. For example, standardising the expressions "issuer code" and "issuer identifier code" to, simply, "issuer identifier code", or expressing the relevant currency associated with the card transaction, and hence the card, consistently, would raise little debate. However, the proposed amendments go much further than this. 155 In this connection, it is convenient to focus on the amendments directed to that part of the accepted parent specification that describe the invention by reference to Figures 5 and 6: see [98]-[111] above. 156 With respect to the passage of the accepted parent specification quoted at [100] above, the proposed amendments (shown by interlining and underlining) are: Typically, payment card issuers are assigned a range of card numbers for issuing cards to customers. For example a small bank may be assigned the range 4555999033300000 to 45550999033399999, whereas a larger bank may be assigned 4555998800000000 to 4555998819999999. The identifier code is the portion of a card number required for comparison with entries in a bank reference table, which distinguishes between currencies of payment of cardholder accounts of issuers. In this example, in the case of the small bank, the leading 11 digits of the card number, being 45559990333, identify a currency of payment of cardholder accounts of the issuing small bank. In the case of the larger bank, the leading 9 digits of the card number, being 455599880 or 455599881, identify a currency of payment of cardholder accounts of the issuing larger bank. Accordingly, the identifier code in this example typically comprises the leading 11 digits of the card number, this being is the portion of a card number, which required to distinguishes between the currency of payment of cardholders accounts of issuers, for comparison with entries in the bank reference table. 157 With respect to the passage of the accepted parent specification quoted at [106] above, the proposed amendments are: The identifier code is compared 51 with entries in a bank reference table, (an example of which is shown in Figure 6.), which The bank reference table contains a list of issuer identifier codes which comprise the leading portions of card numbers sufficient to distinguish between currencies of payment of cardholders' accounts of issuers of credit/debit payment cards. Each issuer identifier code 60(1-n) in the table has an associated entry 61(1-n) containing an associated currency, which corresponds to the currency of payment of cardholders' accounts of the issuer. For example, if the issuer is an Irish bank then the associated currency may be Irish Pounds or EUROS, similarly if the issuer is a UK bank then the associated currency is probably pounds Sterling. The bank reference table may be created from a number of sources, including the card scheme administration organisations or from data collected from a large number of cardholders. 158 A new Figure 6 is proposed: 159 With respect to the passage of the accepted parent specification quoted at [113] above, the proposed amendments are: If no corresponding entry is found in the bank reference table for the identifier code of the issuer of the card, then the transaction will be processed 53 as before in the prior art. If an entry is found for the identifier code, the associated currency corresponding to associated with the issuer identifier code is extracted and the transaction is processed with enhanced functionality 54 using the associated currency. For example, in the bank reference table shown in Figure 6, for a card number 4555 8800 0332 1234, the identifier code comprises the leading digits of the card number sufficient to distinguish between the currency of payment of cardholder accounts of issuers, typically being the length of the longest entry in the bank reference table. Accordingly, the identifier code extracted in this example is 4555 8800 033. The identifier code is compared with entries in the bank reference table. A corresponding entry is found in the bank reference table for the identifier code, being the issuer identifier code 45558, and the associated currency, being Sterling, is extracted and the transaction is processed with enhanced functionality. A variety of enhancements are available, when the currency of the payment cardholders account is known. 160 The passage quoted at [116] above with respect to the BRT is proposed to be expressed as follows: …The bank reference table is a table that which stores the leading digits of individual issuers, being portions of card numbers that distinguish between currencies of payment of cardholders' accounts of issuers of credit/debit payment cards, in the world and which table identifies an associated currency code for each entry in the tableissuer. 161 Further, the passage from the accepted parent specification that I have quoted at [95] above with respect to an alternative embodiment, is proposed to be expressed as follows: If the transaction is authorised, the authorisation host extracts the identifier issuer code from the payment card details and checks 425 the extracted issuer identifier code against entries in the bank reference table. If no entry is found in the bank reference table or if the currency associated with the cardholder's account issuer is the same as that of the merchant then the transaction details are unchanged and forwarded 435 back to the terminal along with the authorisation code. Alternatively, the host may simply send the authorisation code as the terminal already as the transaction details. If an entry is found in the bank reference table and the currency associated with the cardholder's account issuer is different from that of the merchant, the transaction amount is converted 420 to an equivalent amount in the associated currency. 162 These amendments signal a subtle but nevertheless significant conceptual change. Rather than being the portion of a card number which "distinguishes between the issuers", the identifier code is now described as the portion of a card number which "distinguishes between currencies of cardholder [or cardholders'] accounts". It is not clear from the proposed amendments whether the identifier code continues to function so as to distinguish between issuers as well. Nevertheless, the conceptual shift from the identifier code being one that distinguishes between issuers to one that distinguishes between currencies of cardholder or cardholders' accounts assigns a new function to that code, with the consequence that, in the example given, the small bank and the larger bank can use portions of the range of card numbers assigned to them to issue cards to customers for a number of different currencies, not merely one currency for that range of card numbers. 163 This consequence is not expressly stated, but it is encompassed within the amended description. The change is illustrated in certain passages of Mr Mylordis' affidavit, which were advanced by the applicant to support its case that, in satisfaction of s 40(2)(a) of the Act, the accepted parent specification, as proposed to be amended, fully describes the claimed invention. Mr Mylordis said: 49. A specific example of the mapping between the card number and the cardholder's currency as determined from the BRT is given on pages 12 and 13 of the Amended Parent. I have developed an example of a possible implementation of the method described in the Amended Parent, being an example that I could have developed as at July 1999, in light of my knowledge and experience as a software engineer, in the same way that I developed the Quickline system, discussed in paragraphs 38 to 40, above. In this example, the issuer identifier code (depicted below) is a code that comprises the first six digits of the card number (being the Bank identification number of "BIN"), together with an additional N digits from the card number, where N could be 0. 6 DIGITS N DIGITS

In this example, an issuing bank, such as Citibank Australia, may be allocated the BIN 435600. Citibank Australia may decide that while most cards that it issues will be in Australian dollars, it is also going to issue cards in Euros and US dollars. All cards issued in Euros will have a number that comprises the BIN plus the digits of 01, while all cards issued in US dollars will have a number that comprises the BIN plus the digits 02 to 03. Any other cards with the BIN 4356 00 will be in Australian dollars. 51. Using information provided to me by a number of different issuers, I could construct a bank reference table, that has the following entries (among others): ISSUER IDENTIFIER CODE CURRENCY CODE 4356 00 AUD 4356 0001 EURO 4356 0002 USD 4356 0003 USD

In my exemplary method, I may nominate that the identifier code is the first 12 digits of the card number, so as to ensure that the identifier code is as long as, or longer than, the longest entry in the BRT. A 12-digit identifier code is therefore extracted from the card number and compared with the entries in the BRT to find the maximal match comparison, being the longest entry in the BRT that matches the identifier code. For example, if the identifier code extracted from a cardholder's card number is 4356 0001 1234, the longest matching entry in the extract of the BRT that I have set out in paragraph 51, above, is 4356 0001. Therefore, issuer identifier code is an eight-digit number and the currency associated with the identifier code is Euros. Alternatively, if the identifier code extracted from the cardholder's number is 4356 0004 9999, the only entry in the table in paragraph 51 that corresponds to that number is 4356 00. Therefore, the issuer identifier code is a six-digit number (which corresponds to the BIN), and the currency of the customer's card is Australian dollars. 164 As I have noted ([118] above), the applicant submitted that the accepted parent specification expressly recognises a bank holding cardholders' accounts in different currencies. For the reasons I have given above, I do not accept that submission. The accepted parent specification describes only one currency that can act as an alternative to the merchant's currency, not a possible range of currencies for the assigned card numbers that can act as an alternative to the merchant's currency. 165 The conceptual change from the identifier code functioning to distinguish or, perhaps, functioning only to distinguish, between issuers, to one that distinguishes between currencies of payment of cardholder or cardholders' accounts, affects how the expression "identifier code" is to be understood within the claims following amendment. This change gives the claims a different meaning. 166 It follows that those amendments which provide for, or are implicated in, this conceptual change would result in the specification claiming matter not in substance disclosed in the specification as filed. Thus, these amendments are not allowable, by dint of s 102(1) of the Act. 167 The respondents submitted that these amendments are not allowable under s 102(1) because, the accepted parent specification would then claim an alternative to the merchant's currency that "may not be the currency associated with the card issuer". By this submission, the respondents meant that the amendments encompass a circumstance where the domestic or home currency of the issuer of the card and the currency for which the card is issued to the cardholder are different. 168 For the reasons I have given above (see [123]-[124]), I do not think that the accepted parent specification is dogmatic about what the currency associated with the card must be. Specifically, I do not accept that the invention disclosed and described in the accepted parent specification or parent specification as filed requires the currency associated with the card transaction, and hence associated with the card, to be the domestic or home currency of the issuer. 169 I am not persuaded, therefore, that the respondents' submission accurately identifies why the proposed amendments fall foul of s 102(1) of the Act. In my view, the defect of these amendments is that the identifier code now distinguishes between currencies, not just between issuers, with the consequence that, by manipulating portions of card numbers assigned to an issuer, the issuer can issue cards for different currencies, not just one currency, within the assigned range, as the alternative to the merchant's currency. 170 This finding is sufficient to defeat the proposed amendments. Nevertheless, I will briefly state my conclusions on the other issues that have been raised. 171 So far as s 102(2)(a) of the Act is concerned, the respondents submitted that, by reason of the proposed amendments, a method or system for identifying the currency of a cardholder that is different from the currency of an issuer, would now be an infringement. To illustrate the point, the respondents gave the example of an Australian consumer travelling in England, who uses a credit card issued by an Australian bank in United States dollars to pay for goods in that currency in that country. The respondents submitted that, as a result of the proposed amendments, this transaction would give rise to an infringement whereas, under the current claims of the accepted parent specification, there would be no infringement. 172 I do not accept that submission. The proffered illustration has a number of difficulties, not the least of which is the fact that the relevant conduct takes place outside Australia, thereby calling into question whether there could be an infringement in any event. Aside from that difficulty, the illustration, once again, focuses - wrongly, in my view - on the contention that the currency for the card must be the home or domestic currency of the issuer, an interpretation of the accepted parent specification, and the parent specification as filed, which I do not accept. 173 Nevertheless, when translated into the claims, the changed meaning of "identifier code" results in the claims of the accepted parent specification post-amendment falling outside the scope of the claims of the specification pre-amendment. In essence, the amendments speak of a new and different invention to the invention that is claimed at the present time. The "identifier code" post-amendment is not the same as the "identifier code" pre-amendment. It cannot be said that, as a matter of substance, this "new" invention falls within the scope of the claims of the accepted parent specification, even though a method or system of dynamic currency conversion is claimed in which the currency for the transaction is set to a currency other than the merchant's currency. I note that the delegate came to the same view. 174 So far as s 102(2)(b) of the Act is concerned, I am satisfied that, to the extent that the proposed amendments use consistent expressions to distinguish between the "identifier code" and the "issuer identifier code", the amendments are clear. However, it is not clear whether the "identifier code" must also function to distinguish between issuers as well as functioning to distinguish between "the currencies of cardholder [or cardholders'] accounts". Moreover, it is not clear whether the identifier code, as a portion of the card number, is restricted to the leading digits of that number. The leading digits of a card number are certainly given as an example of an identifier code, but it is not clear whether the example is given as a limiting one, in the sense that the identifier code must include a portion of the card number that commences with digits that can be described as "leading digits" of that number. This is, perhaps, another manifestation of the problem that it is not clear whether the identifier code continues to function to distinguish between issuers. 175 Similarly, it is not clear whether the issuer identifier code is limited to all or some portion of the identifier code, as opposed to some other sequence of digits to which the identifier code can be mapped. If the issuer identifier code is limited to all or some portion of the identifier code, must it also include digits that can be described as "leading digits" of the card number? 176 These questions - perhaps others - are not resolved by the proposed amended description and have the consequence that the invention is not fully described as required by s 40(2)(a) of the Act, having regard to the requirement of s 102(2)(b). 177 In their written submissions, the respondents also advanced their case in this regard on the basis that, post-amendment, the claims would not be clear, as required by s 40(3) of the Act. However, in the course of oral submissions, the respondents did not persist with that particular objection. They saw the objection as one that was more appropriately characterised as a failure to describe the invention fully. 178 Finally, in their written submissions, the respondents also contended that the opposed amendments would lead to the claims of the accepted parent specification not being fairly based on the matter described therein, contrary to s 40(3) of the Act. In this connection, they submitted that there is no real or reasonably clear disclosure of how an identifier code that is longer than a BIN could be determined, how issuer identifier codes that are shorter or longer than a BIN could be determined, or how a BRT could be constructed. These submissions appear to me to be more appropriately addressed to the contention that the invention is not fully described, rather than that, post-amendment, the claims would not be fairly based. I do not think that the opposed amendments are not allowable because of a lack of fair basis in the claims.

The amendments proposed to the accepted divisional specification 179 The parties proceeded on the basis that, for present purposes, the amendments proposed to the accepted divisional specification are materially the same as the amendments proposed to the accepted parent specification and that the decision on the allowability of the amendments proposed to the accepted divisional specification should follow the decision on the allowability of the amendments proposed to the accepted parent specification.

Conclusion 180 The proposed amendments are not allowable. It follows that the second appeal should be dismissed. By no later than 13 February 2015, the parties are to bring in agreed draft orders giving effect to these reasons and providing for all additional steps necessary to bring the first appeal into readiness for hearing. I certify that the preceding one hundred and eighty (180) numbered paragraphs are a true copy of the Reasons for Judgment herein of the Honourable Justice Yates.

Intellectual Property Laws Amendment (Raising the Bar) Act 2012(Cth)

Federal Court Rules 1979(Cth)

Patents Act 1990(Cth)ss 40, 79B, 88, 120, 140

At a glance

Court

Decision date

Before

Source

Judgment (36 paragraphs)

Parties

Legislation Cited (4)

Cases Cited (6)

Cited By (1)