Fisher & Paykel Financial Services Ltd v Karum Group LLC [2012] NZHC 3314; [2013] 2 NZLR 266; [2013] NZCCLR 8 (10 December 2012)

Last Updated: 29 January 2018

For a Court ready (fee required) version please follow this link

IN THE HIGH COURT OF NEW ZEALAND AUCKLAND REGISTRY

CIV-2006-404-6646 [2012] NZHC 3314

BETWEEN FISHER & PAYKEL FINANCIAL SERVICES LIMITED

Plaintiff

AND KARUM GROUP LLC Defendant

Hearing: 24-26, 29-31 August, 1-2, 5-9, 12-16, 19-22, 26-30 September, 3-7,

10-13 October, 17 November, 14 December 2011 and 22 February

2012

Counsel: AR Galbraith QC, JF Anderson and MA Corlett for Plaintiff

JG Miles QC, ZG Kennedy and JK Wilson for Defendant

Judgment: 10 December 2012

_{JUDGMENT (4) OF RODNEY HANSEN J}

This judgment was delivered by me on 10 December 2012 at 11.00 a.m., pursuant to Rule 11.5 of the High Court Rules.

Registrar/Deputy Registrar

Date: ...............................

Solicitors:

A J Park (K W McLeod), P O Box 565 Auckland

Email: [e-mail] (jess@[e-mail]) MinterEllisonRuddWatts, P O Box 3798 Auckland

_Email: [e-mail]

Copy for:

Alan R Galbraith QC, P O Box 4338 Auckland 1140

Email: [e-mail]

Julian G Miles QC (J F Anderson), P O Box 4338 Auckland 1140

_Email: [e-mail] / [e-mail]

FISHER & PAYKEL FINANCIAL SERVICES LIMITED V KARUM GROUP LLC HC AK CIV-2006-404-

6646 [10 December 2012]

_{TABLE OF CONTENTS}

Introduction [1] Credit management systems [8] The CMS software [17] CMS and FTC [20] Misrepresentations

Background [24] Clean room memorandum [47] Settlement [59] Pleading [63] Legal principles [66] Truth or falsity [69]

(a) Untrue statements

Sheila Mason and Davorka Horvat only had the limited roles described in the memorandum [70]

FPF was independently developing its own revolving credit [77]

platform which did not replicate any aspects of CMS IP

Access to CMS systems and documents was restricted

to previous RFS staff [92]

(b) Half truths

Support teams remain technically, geographically and

culturally separate [93]

Only two of the existing RFS team members (Mason and Horvat)

have accepted roles relating to the FPF systems [96]

No FPF staff had access to CMS development, systems, production system or documents [97]

Once FPF had developed its revolving credit functionality in Lending, it would simply migrate customer data from the CMS

software platform to the FPF Lending system [98]

(c) FPF would keep the clean room process and

procedures in place [101]

Sanitising the clean room memorandum [102] No protections in place [104] Data migration [112] Summary [113]

Inducement [114]

Entire agreement [125]

Infringement

Background [128]

Pleading [132]

Breach of confidence – principles [135] Standing to sue [137] Particulars [138] Quality of confidence [139]

Elements of copyright infringement [145]

Ownership

Preliminary issue – estoppel [148]

Ownership [150] Subsistence [151] Originality [156] Qualification for copyright protection under the Act [164] Conclusion [171]

Infringement [172] Objective similarity [173] Substantial part [174] Causal connection [176]

Ideas versus expression [177]

Features of the CMS system

Source code and logic [187]

Product data [196]

Business rules or policies [199]

Specific infringements

Payment calendar and delinquency calendar [201] Payment calendar [215] Delinquency calendar [221]

Aged debt [226]

Special codes [228]

Statements and intercept codes [239] Reporting [248] Statement history and unbilled transaction displays [254] Agency [258] Conclusion [264]

Result [268]

Introduction

[1] This proceeding has resolved into a claim by Karum Group LLC (Karum), against Fisher & Paykel Financial Services Limited (FPF). The only issues requiring determination arise under Karum’s counterclaim against FPF.

[2] Karum is a software and services company established in the United States of America. It was previously known as Credit Management Services Inc (CMS). Karum’s business is based on credit management software which it has continuously developed over a period of 20 years. The software is used for processing consumer and commercial credit transactions, mainly in North America, Latin America and Mexico.

[3] In 1994 The Farmers Trading Company Limited (FTC) licensed the CMS software from one of Karum predecessor companies, PRJ & Inc (PRJ&), for use by FTC’s wholly-owned subsidiary, Retail Financial Services Limited (RFS). RFS operated the credit division of the FTC business which comprised Farmers Card (a revolving credit product) and fixed instalment (hire purchase) accounts. The licence was perpetual and non-assignable.

[4] FPF is a subsidiary of Fisher & Paykel Appliances Limited. It is a provider of financial products and services, including credit cards. In 2004 FPF acquired RFS, unaware that the CMS licence would terminate in the event that the retail and credit divisions of FTC ceased to remain in common ownership. FPF had intended to continue using the CMS system until it had integrated the RFS business with its own and migrated data on the CMS system to its own credit management software platform known as “Lending”.

[5] When Karum discovered that RFS had been acquired by FPF, it advised FPF of its interest. Karum was prepared to grant FPF a licence to continue using the CMS system provided it was assured that its intellectual property rights would not be infringed pending the integration of the two businesses. After protracted negotiations, agreement was reached. Karum granted FPF a licence to enable it to

continue using CMS software and FPF warranted that Karum’s intellectual property

rights would be protected.

[6] Karum claims that FPF made material misrepresentations in the course of negotiations which induced Karum to enter into the settlement agreement and to grant FPF the licence. Karum says FPF falsely represented that Karum’s intellectual property rights had not and would not be infringed and that procedures had been put in place to ensure that any such infringements would not occur. Karum submits that it is entitled to cancel the agreement and licence and to claim damages under the Contractual Remedies Act 1979 and/or the Fair Trading Act 1986.

[7] Karum further claims that while enjoying access to the CMS system, FPF was in breach of a duty of confidence owed to Karum and infringed Karum’s copyright in the CMS software.

Credit management systems

[8] It will be helpful to complete setting the scene by saying something about computerised credit management systems such as the CMS and Lending platforms.

[9] A credit management system has the purpose and function of recording the transactions of a customer to whom credit has been extended and to use the data for credit control and other management purposes. From an early stage, computer technology was employed for credit management purposes. It lent itself admirably to the high volume of data required to be processed and the various applications required.

[10] A computer program is a sequence of instructions to perform a particular task. They usually comprise a sequence of steps structured in a logical order. The steps are sometimes referred to as algorithms and the series of steps is the logic of the program. The program is developed or designed in order to achieve predetermined objectives or functions. The functionality of a computer system – what it does or is capable of doing – is a key concept.

[11] The instructions to the computer are written in programming language sometimes referred to as the “source code”. It is capable of being read by humans, unlike the object code into which the source code is converted to make it machine (computer) readable.

[12] The CMS software is written in COBOL (Common Business-Orientated Language) which was established as a programming language in the 1960s. It is well established and said to account for some 75 per cent of all computer transactions and 90 per cent of all financial transactions worldwide. The software for FPF’s Lending system is written in Ingres, a fourth-generation programming language.

[13] A computer system such as the CMS system comprises a number of sub- systems, each with a particular function. The sub-systems in turn comprise a number of programs that are linked together to perform a series of related operations or functions. The sub-systems combine to achieve the overall functionality of the programme.

[14] A credit management system processes large amounts of data which must be stored in a way that makes them readily accessible. The most common form of database, and the one used in the CMS software, is a relational database. It comprises tables in which fields (or categories) of information are stored in rows and columns. The way in which the database is organised is called the schema. The information stored in the tables is often referred to as data values.

[15] The functionality of a system (and its components) will be determined by reference to the business rules or policies of the creditor. Business rules are the business-specific policies and procedures established to run, maintain and improve the performance of the business utilising the credit management software.

[16] The distinction between the rationale of business rules, sometimes referred to as business logic and the logic of the computer programme as expressed in the source code, is not always clear. The two concepts are, however, central to the

matters in issue in this proceeding and will be further considered when specific aspects of the CMS system are examined.

The CMS software

[17] The progenitor of the CMS system was a Retail Information System (RIS) developed by PRJ&, a company formed in the United States by Mr Peter Johnson, the Chairman and Chief Executive Officer of Karum. Zale Corporation (Zale), then a large jewellery retail chain in the United States, agreed to licence, modify and maintain the RIS. Two employees of Zale, Dale Williams and Paul Hart (with others), had developed a credit management software system. In 1988, Zale and PRJ& agreed to form a partnership to enhance, further develop and market the CMS software developed by Zale.

[18] In 1992, following the bankruptcy of Zale, a dissolution agreement was entered into dissolving the partnership and granting PRJ& a licence which included rights to transfer and assign the CMS software. Through a series of transactions, the detail of which is not material for present purposes, the right to licence the CMS system was acquired by other companies in which Mr Johnson was beneficially interested. Ultimately, all technology, assets and liabilities and staff were transferred in 1996 to Karum.

[19] Karum brought its claim on the basis that it owned the copyright in the CMS system. That was denied by FPF. In the closing stages of the trial and after the hearing, Karum sought to address questions raised by FPF as to its standing to assert a claimed breach of copyright. Karum sought leave to call further evidence and to make further submissions concerning the interpretation of documents relied on to establish its ownership of copyright in the CMS software. Karum also applied for leave to amend its counterclaim to plead in the alternative that it is the exclusive licensee of the CMS software. I determined that, contrary to what was pleaded in its second amended statement of defence and counterclaim, Karum is not the copyright

_{owner of the CMS software but is an exclusive licensee.}¹ _{I granted leave to Karum}

¹ Fisher & Paykel Financial Services Ltd v Karum Group LLC (No 2) [2012] NZHC 240; Fisher

& Paykel Financial Services Ltd v Karum Group LLC (No 3) [2012] NZHC 794.

to amend its counterclaim to plead that it is the exclusive licensee. I did not consider it necessary for Zale, as owner of the copyright, to be added as a party.²

CMS and FTC

[20] Since the early 1940s FTC had a revolving credit policy enabling customers to purchase goods on credit using the Farmers card. In time its use was extended to third party merchants. FTC’s retail customers could also purchase goods on credit under a fixed instalment or hire purchase contract.

[21] Prior to the introduction of the CMS system, FTC used a credit management system called F Credit. It had a number of processes and functionality comparable to CMS. In 1988 it licensed the RIS developed by PRJ&. When, in 1993, RFS was tasked to find a new credit management system to support Farmers, CMS was one of the two systems to make the short list. The CMS system was chosen against internal advice from FTC’s IT department.

[22] In 1994 FTC and the entity then having the right to licence the CMS system entered into a licence agreement which was structured as an addendum to the 1988 licence agreement in respect of RIS. FTC was granted a perpetual licence to use the CMS system. It was envisaged that the CMS software would require significant modification and enhancement to meet all of FTC’s functionality requirements. An intensive functional review was carried out. Significant modifications were undertaken as a result, most of them by RFS. Under the addendum the licensor agreed to provide maintenance and support services to FTC. It undertook modifications and enhancements to the CMS software until 1998. Thereafter, FTC and RFS modified the CMS software themselves, as they were entitled to do under the addendum agreement.

[23] Thus, when FPF acquired RFS, it had been using the CMS system for 10 years, for most of that time independently of Karum and its predecessor companies. That may help to explain why FPF was not told that the CMS system was licensed

_{and did not know that the licence would terminate when, as occurred, the retail and}

² See [37]–[39] of Judgment No. 3.

credit management arms of FTC were sold to different entities. This necessitated the negotiations with Karum to obtain a new licence. Karum now claims that the new licence and the settlement agreement should be cancelled because of misrepresentations made by FPF during the lead up to their being entered into.

Misrepresentations

Background

[24] Karum first became aware of FPF’s proposed acquisition of RFS in October

2003, following news reports. It sought further information from FTC. FTC advised that FPF did not have the functionality to process FTC’s credit card and suggested that FPF would be enhancing its system to meet FTC’s requirements.

[25] In June 2004, Mr Johnson wrote to Mrs Sheila Mason to ask for an update on the plans for CMS. Mrs Mason had worked for FTC since 1982. She had held positions of responsibility on the credit systems side of the business, most recently as the Project Manager of its management information services. She transferred to FPF in April 2004 as the Development Manager for information services. She was to play a leading role in the integration of the RFS and FPF businesses as part of a project called Project Orpheus. Ms Mason replied to Mr Johnson’s letter, advising him:

Unfortunately, CMS is no longer a requirement for the new business. Fisher

& Paykel Finance have a credit management system of their own and the strategy is to convert from CMS onto the FPF platform. This will all happen

early next year.

[26] Mr Johnson was concerned when he heard that RFS was continuing to use the CMS software under its new owner. He instructed Karum’s legal counsel in the United States, Mr Robb Scott, to write to FPF and its parent company referring to the relevant terms of the licence, recording its understanding that FPF had been using the CMS software to process data originating from FTC and advising that it did not have a licence to do so. There was no reply to that letter or to a follow-up letter sent on 26 August 2004.

[27] Mr Johnson said in evidence his concerns at this stage were two-fold. First, that FPF was using the software without a licence. Secondly - and what had not been articulated in the correspondence to that point – that FPF may make improper use of its opportunity to access the CMS system in the development of its own credit management platform. Specifically, he was concerned that FPF could access the CMS source code. He said he was not so concerned about a deliberate violation but about the use of protected information by FPF, unaware that it did not have the right to use or access the system.

[28] Mr Johnson’s concerns were voiced repeatedly to FPF personnel during

discussions and negotiations that took place between September 2004 and January

2005. The first meeting was on 23 September 2004. It was attended by Mr Johnson and Mr Chris Hall, General Manager of information technology at FPF, and lawyers for the parties. The agreed minutes record Mr Hall’s advice that FPF was very surprised to receive the letter from Karum’s lawyers. He explained that enquiries had been made in the course of due diligence and that Fisher & Paykel were told that RFS owned all rights to the source code of the software. Mr Hall explained how the CMS software was being used. The minutes record:

Chris explained that the CMS software is still being used to process transactions of the finance business acquired by F&P but that it is still located in its original Farmers location on equipment owned and operated by Farmers. The use of the CMS system is strictly limited to processing the same business from the same channels under the same brands (Farmers Finance & RFS) into the same legal entity (“RFS”) as existed prior to the purchase by F&P. The RFS staff are also located generally at the same place but are employed by F&P.

[29] Mr Hall went on to confirm that Mrs Mason and the software development personnel at FPF were continuing to modify the CMS software, but that the modifications were limited to essential maintenance. He said FPF was working towards moving all of its finance business onto one software platform and that the likely conversion date was mid-2005. The CMS software would be used until then. Mr Johnson is recorded as explaining that he wanted the CMS software completely protected. He required FPF to sign a licence agreement covering its use of the CMS software.

[30] On 1 October 2004 FPF’s solicitors, Simpson Grierson, wrote to Karum’s

solicitors. The letter read in part:

The CMS software as originally licensed to Farmers is only being used for the purposes of processing data of the Farmers retail stores, and Farmers card transactions from merchants accepting the Farmers card, as it was prior to the separation of the retail and finance arms of the Farmers business. The CMS software is not being used to process any other transactions of the business of F&P Financial Services Limited (“F&P Financial Services”) and nor is it the intention of F&P Financial Services to use the CMS software for that purpose. The use of the CMS software has not been extended beyond the data and transactions permitted to be processed under the licence granted to Farmers.

Mr Alastair Macfarlane, the Managing Director of FPF, confirmed in evidence that

the assurances given in the letter accorded with FPF’s instructions.

[31] Karum’s solicitors, Minter Ellison Rudd Watts, replied on 18 October. They rejected the suggestion made in Simpson Grierson’s letter that FPF’s use of the CMS software was not in breach of the licence agreement. The letter went on to express concern that FPF “has had prolonged and unrestricted access to its proprietary software” and was continuing to modify the software with a view to transferring all of its financial operations onto a single software platform. The letter continued that Karum sought “immediate confirmation that the intellectual property resident in its proprietary code has not been compromised in any way”. It also sought FPF’s:

(a) Immediate acknowledgement that it accepts that it is not currently licensed to utilise the CMS software; and

(b) Confirmation that it will execute a new licence agreement directly with our client (to be backdated to the date upon which your client commenced using the CMS software).

The letter concluded by stating that Karum would “look towards its legal remedies”

if it did not hear within five days that FPF would accept its demands.

[32] A response came by way of a personal email on 18 October 2004 from Mr Macfarlane to Mr Johnson. Mr Macfarlane commented that the parties’ lawyers appear to be having difficulty resolving the matter between them. He suggested the following “practical” solution:

(a) I am more than comfortable to confirm that the Intellectual Property resident in your proprietary code has not been, and will not be, compromised by us in any way. I can give you this assurance because there have been no changes made to the manner in which we are using the CMS software since the acquisition of the Farmers Finance business in July of this year.

(b) I am conscious that your primary concern is to protect your intellectual property and ensure that parties using the CMS software are respecting the appropriate terms and conditions under which that licence is granted. I am therefore equally comfortable with executing any appropriate agreement between us that ensures we are dealing with the software in a manner in line with your expectations. With this in mind, would you have your lawyers send me an agreement for my review. We can then proceed to execute an appropriate agreement between us that gives you the comfort you need that we are in fact acting in an appropriate manner with respect to the CMS software. This agreement may need to be in the form of a new licence as I understand the original licence agreement was first executed back in 1988 and would be unlikely to include the appropriate terms and conditions.

[33] Mr Macfarlane said in evidence that his assurance that CMS software had not been compromised relied predominantly on the advice of Mr Hall, who was the executive directly responsible for this part of the business. It accurately recorded what he had been told and was intended to give Mr Johnson the reassurance he sought.

[34] A letter to similar effect was sent by Simpson Grierson (with whom Mr Macfarlane had discussed the proposed contents of his email) on 22 October. In response to both communications, Karum’s United States attorney, Mr Scott, sent FPF the standard form licence agreement of CMS for his perusal.

[35] Mr Macfarlane and Mr Johnson met in San Francisco on 8 November 2004 in the course of an overseas trip taken by Mr Macfarlane. He confirmed that FPF was happy to enter into an agreement to protect Karum’s intellectual property and to provide assurances that the software would be used in the same manner as it was used when RFS was part of FTC. In a letter he wrote on 24 November he referred to concerns raised by Mr Johnson at the meeting about the role of Mrs Mason. He said:

You expressed concerns that your intellectual property could be compromised as a result of Sheila Mason’s involvement in the development of Fisher & Paykel Finance’s (FPF’s) systems. I can assure you this is not the case. The project to develop revolving credit functionality into FPF’s

own systems started back in July 2003 well before the RFS acquisition. Business requirements have been gathered using standard analysis techniques. FPF engaged an external Business Analyst with relevant credit card industry experience to assist with defining the requirements. The system being developed does not replicate any aspects of the CMS system that could be considered to be CMS’s intellectual property.

The letter continued:

However, we understand your concern to ensure your intellectual property is properly protected. Accordingly, we are happy to sign an appropriate Deed of Covenant that protects your intellectual property in your CMS software. This Deed would ensure that Fisher & Paykel Finance Limited (FPF):

● uses your CMS software for the same purposes and in the same way that it was being used prior to the purchase of the Retail Financial Services (RFS) business by FPF as if the original license agreement was an agreement between CMS and FPF.

● does not “reverse engineer” your CMS software or by any other means incorporate any intellectual property of your CMS software into FPF’s system.

[36] Mr Macfarlane explained why he felt able to assure Mr Johnson that Mrs Mason’s responsibilities at FPF for Project Orpheus would not pose any threat to Karum’s interests. He said from his point of view the CMS software was simply not relevant to the development of FPF’s systems. FPF did not need what he referred to as “the old technology”. He said that the “old COBOL mainframe system” used by CMS had no relevance to FPF’s “much more sophisticated systems”. Mr Macfarlane said that Mrs Mason’s involvement in Project Orpheus was important, not because of her knowledge of the CMS system, but because of her understanding of the Farmers business and the processes and procedures necessary to support it in the FPF environment.

[37] Mr Johnson was unimpressed with Mr Macfarlane’s proposal. In an email to Mr Macfarlane on 1 December, he expressed disappointment with the delay in bringing matters to a conclusion and with the offer. He described the legal arguments underpinning the proposal as “disingenuous”. After summarising his view of the facts, he said that he was not concerned that his intellectual property could be compromised:

I am concerned that it has been compromised. This genie cannot be put back in the bottle.

Mr Johnson went on to say that the only acceptable mechanism to protect Karum against the uses FPF had made and was making of Karum’s proprietary information was to enter into a licence permitting those uses. He said that as FPF had not taken the opportunity to enter into the licence, Karum was left with no choice but to institute legal proceedings, which it would do if it did not receive a signed licence agreement from FPF within a specified time.

[38] FPF decided the time had come to involve its in-house lawyers. Mr Lindsay Gillanders, the Legal Director of the Fisher & Paykel group and a Director of FPF and Ms Rebecca Holbrook, General Counsel for Fisher & Paykel Appliances Limited, were asked to become involved. Neither had any prior knowledge of the issues and immediately sought briefings from senior managers most directly involved, including Mr Macfarlane and Mr Dennis Churches, FPF’s Chief Financial Officer. They reviewed the correspondence.

[39] On 3 December 2004, Mr Gillanders sent an email to Mr Johnson expressed to be without prejudice. He said:

Before both our organisations embark on a time consuming and costly litigation process I would like to enquire if there is a way in which a reasonable compromise can be reached between us.

I should emphasise that we have a policy that we do not deliberately infringe the IP rights of other organisations. Our approach is to avoid costly and time-consuming litigation if a sensible and reasonable commercial resolution can be found to the issues of concern.

Mr Gillanders went on to acknowledge Mr Johnson’s two principal concerns. In order to meet the claim that FPF’s current use of the CMS system was not authorised by the existing licence, he said FPF were prepared to pay a reasonable and fair fee for the use of the system until FPF’s system was completed in mid-2005. He invited Mr Johnson to indicate what he regarded as a fair and reasonable fee.

[40] In relation to the concern that in the development of its own system FPF would be using Karum’s intellectual property, he said that he could personally verify that FPF had been developing its own card products and system for several years. He agreed with Mr Johnson that the question of whether or not FPF was using Karrum’s intellectual property was simply a question of fact and said:

To provide reassurance to you that we are not using your IP, if necessary, we can set up an independent review and audit process acceptable to you that can report to both parties and set up a cost effective arbitration process if any dispute should arise.

[41] Mr Scott replied on behalf of Karum. In an email to Mr Gillanders of

6 December 2004 he advised that Karum accepted the two elements of FPF’s proposal. He stipulated a licence fee of US$350,000 and that the parties agree upon a process for confirming at the end of the usage period that FPF was not using CMS trade secrets; for the appointment of an expert, if necessary; and the remedies for breach. He sent a draft heads of agreement to which was attached as Exhibit A an appendix which set out the proposed procedure for review. Mr Scott referred to delay on FPF’s part and said that Karum had reluctantly come to question FPF’s good faith. He said Karum sought agreement to the proposal by the start of business on 4 December, California time, two days before the date of the email.

[42] On 8 December Mr Scott, Mr Gillanders and Ms Holbrook had a telephone conference. The development of FPF’s system was discussed. Mr Gillanders told Mr Scott that it would be difficult or impossible for crossover to occur.

[43] Following the telephone call on 10 December 2004, Ms Holbrook sent a detailed proposal to Mr Scott addressing both the continued use of Karum’s intellectual property to process transactions pending transition to the FPF platform and confirming that the FPF system did not, and would not, infringe Karum’s intellectual property. She proposed a licence fee of US$200,000 for the use of Karum’s intellectual property for the period ending 30 June 2005. Rather than enter a new licence agreement, she suggested that FPF enter into a deed of covenant recording FPF’s agreement to be bound by the terms of the CMS addendum entered into by FTC in 1994. Minor amendments would be required to recognise the changed circumstances. She proposed that if FPF was unable to complete the migration from the CMS system to FPF’s system by 31 June 2005, FPF would pay a monthly fee of US$20,000.

[44] Referring to the concern that FPF had been using CMS intellectual property in the development of its integrated platform, Ms Holbrook said:

I can confirm that our team is confident that there has been no copying of your intellectual property in our system.

She reiterated earlier advice that FPF had its own card product and had been developing and enhancing its own system for a number of years, long before the acquisition of Farmers finance business was contemplated. She said that in order to provide Karum with reassurance that its intellectual property had not been copied, FPF was agreeable to the conduct of an independent review of the FPF integrated platform once migration had been completed. Both Ms Holbrook and Mr Gillanders confirmed in evidence that, based on the advice that they were given at the time, no copying of CMS intellectual property had taken place during the preceding year.

[45] Mr Scott replied on 14 December. He reiterated Karum’s preference for a new licence which would supersede the existing licence. He said CMS would require the agreement to contain warranties. This part of his letter read as follows:

3. Factual Premise. If we were to enter into an agreement with F&P resolving this matter, the agreement would have to include representations and warranties confirming certain representations which have been made by F&P in the course of our discussions. Specifically, that would represent and warrant that (i) F&P did not profit from the financial services business of Farmers (as compared to profiting as an owner from the combined financial services and retail businesses) until July 5, 2004; and (ii) that Farmers has only

350,000 accounts. CMS has previously asked for information on both points. (the sources of your confusion on these issues are

F&P’s public statements, which appear to contradict what CMS has

been told – i.e. F&P has told its shareholders that Farmers has in excess of 500,000 accounts and that F&P has been recognizing revenue from Farmers since November 2003).

Mr Scott sought an urgent reply, advising that Mr Johnson was then in New Zealand finalising legal proceedings which could be filed as early as the following day.

[46] The proceedings were duly filed on 15 December. In the proceedings Karum alleged that FPF was using the CMS software without authorisation and in breach of the copyright. It sought a permanent injunction to restrain FPF from using the software.

Clean room memorandum

[47] At about this time Mr Gillanders or Ms Holbrook (it is not clear who) asked for a memorandum to be prepared which came to be known as the “clean room memorandum”. It was drafted by Pamela Nobbs who had not long before replaced Chris Hall as FPF’s General Manager for information systems. FPF witnesses said it was initially prepared for internal purposes but by the time it was finalised on

20 December 2004, Mr Gillanders and Ms Holbrook were expecting to provide it to

Mr Johnson.

[48] The memorandum reported on the way in which the RFS and FPF credit management systems operated. It recorded that since joining FPF on 10 December

2004, Ms Nobbs had sought information regarding systems usage, security, development and support methodologies within FPF and RFS; she had spoken with the key managers and staff members and was reliant on the information they had provided.

[49] The memorandum recorded its findings under four headings. The findings under the first heading, “Independent Technical Environment and Support Resources”, read as follows:

The RFS and FPF systems are separately supported with dedicated technical specialists. Support staff are located at separate sites, use different methodologies (e.g. Systems Development Life Cycle (DDLC) and have specific technical skills relating to the very different environments they support. Lending systems at FPF are written in ABF Ingress Fourth Generation Language (4GL), with the Ingress Relational Database, whilst CMS is written in Cobol supported by the DB2 database. Typically the older CMS environment used by RFS requires much longer development cycles and changes that take months in the CMS environment can be completed in weeks with the more modern environments used by FPF. IS support staff in each site are also very culturally different, with those supporting FPF systems tending to be more familiar with recent methodologies such as Object Orientation and reluctant to consider supporting mainframe applications such as CMS. These cultural differences have ensured the continuation of separate support.

[50] Under the heading “Functionality & IP”, there was a discussion of the development of FPF’s software system and an explanation of the decision to migrate RFS customer accounts to the FPF system. There was some discussion of the

modifications that had been carried out by RFS to the original CMS software package.

[51] Under the heading “Security”, the report read:

It should be noted that none of the FPF system developers have access to CMS development, test or production systems or documentation. Only two of the existing RFS team members (Devorka Horvat and Sheila Mason) have accepted roles relating to FPF systems. Devorka’s role involves interfacing a newly acquired debt collection package, rather than developing FPF lending systems so ensures the continuity of IP separation, whilst Sheila’s is a non technical management role. Sheila’s skills and experience are primarily in the business administration arena and she has no formal technical qualifications or experience supporting Cobol or DB2 (the CMS technical environment).

[52] There was then a brief discussion of future migration strategy, noting that after business integration had been achieved in June 2005, all CMS modules currently used by RFS will be decommissioned and customer data migrated to the FPF system.

[53] Under the heading, “Summary”, the memorandum concluded:

Support teams remain technically, geographically and culturally separate. In addition, system and documentation access to the CMS system is restricted to previous RFS staff. Systems at FPF are considered to provide a competitive advantage over those at RFS and have been selected as the preferred platforms for migration of RFS receivables, planned to be completed by July 2005.

[54] On 22 December Mr Gillanders and Ms Holbrook had a telephone conference with Mr Scott to discuss FPF’s 10 December proposal. Mr Johnson was overseas at the time. Like all communications over this period, it was expressed to be without prejudice. The discussion covered the form of the licence. FPF’s preference still was to be bound by the terms of the existing licence, whereas Karum was proposing a new agreement. One of the issues that concerned FPF was that under the existing licence improvements would be owned by FTC whereas under the new agreement improvements would be owned by Karum.

[55] Other matters covered were the “Exhibit A” review procedure, the licence fee

and the representations and warranties sought by Karum. There was reference to the

clean room memorandum. Mr Gillanders advised that Ms Nobbs had been asked to carry out a review and that it was intended that the memorandum would be provided to Messrs Scott and Johnson. Ms Holbrook’s notes of the discussion recorded “memo will assist Peter [Johnson] to understand – give him reassurance”.

[56] Negotiations concluded with a meeting on 6 January 2005 in San Francisco. Mr Gillanders and Ms Holbrook met with Mr Johnson and Mr Scott in Mr Scott’s office. Again, the discussion was agreed to be “without prejudice” and “off the record”. Mr Johnson and Ms Holbrook each took notes. Both sets of notes are agreed to be accurate and there are no material differences as to what was said at the meeting. After discussing the start date for the licence (eventually agreed to be 1

April 2004) and the definition of “account” for the purpose of fixing the number of active customer accounts that would be processed, the licence fee was addressed. Mr Gillanders said FPF was prepared to pay an up-front fee of US$400,000 for two years but not the proposed US$150,000 contract initiation fee. According to Mr Gillanders, as soon as he told Mr Johnson that FPF were prepared to pay US$400,000 as a licence fee, his whole demeanour changed. He became much more relaxed “and it was as if we had in one movement addressed his greatest concern”.

[57] Discussion then turned to the migration of data to the FPF system. The clean room memorandum was handed over at this point. Mr Gillanders said that Mr Johnson seemed “not the least bit concerned” about the statements made in the memorandum because he was satisfied that any issues that may arise would be dealt with by the Exhibit A review process. Mr Gillanders rejected Mr Johnson’s view that the Exhibit A process would only be required, based on FPF’s assurances, in the unlikely event that FPF inadvertently incorporated Karum’s intellectual property into its software. Mr Gillanders’ position is that the Exhibit A process was put in place in order to address Mr Johnson’s position that he was not prepared to rely on representations made by FPF. According to Mr Gillanders, he made that very clear at the meeting.

[58] There was discussion of modifications required to the licence. It was agreed that a clause should be added in which FPF warranted that its software would not be based upon or derived from the CMS system. Mr Johnson said that was to cover the

possibility that FPF could inadvertently incorporate a small amount of CMS proprietary information into its new platform during the process of data migration. He compared this to a composer remembering a few notes or a melody over dinner and incorporating them into a new song the following morning.

Settlement

[59] The documents were redrafted and the following day, 7 January 2005, a heads of agreement (HOA) was signed which provided that:

(a) The parties would enter into a software licence agreement (SLA 2005) under which CMS would grant to FPF a non-exclusive right and licence to use the CMS software.

(b) The review process set out in the document attached as Exhibit A would be employed on the termination of SLA 2005 to determine whether CMS intellectual property had been using by FPF in developing its Lending software.

(c) The payments to be made under the licence would settle claims relating to the misuse of the CMS software. This part of the HOA read as follows:

CMS acknowledges and agrees that the payments referred to in the License Agreement include (a) a full and final settlement of all claims howsoever arising out of the use of the Software by any member of the Client Group prior to 1

April, 2004; and (b) a full and final settlement of all claims made in relation to any alleged infringement, or breach of

any agreement in relation to, CMS proprietary trade secret

information by Farmers Trading Company Limited or its related companies.

[60] The review process in Exhibit A provided for a preliminary review by a nominee of CMS within 90 days of termination of the licence agreement. If the nominee concluded that no proprietary trade secret information of CMS had been incorporated in FPF’s software, the review process would conclude. If the nominee concluded that CMS trade secrets had been incorporated, a process would ensue that

would eventually lead, if the parties were unable to agree on a resolution, to an arbitration.³

[61] In the licence agreement FPF agreed to pay a transfer fee of $300,000 for CMS agreeing to transfer rights to use the software granted to FTC under the CMS Addendum and to a licence fee of $100,000 for the period 1 April 2004 to 31 March

2006. There was provision for the extension of the licence on payment of an annual subscription usage fee which varied according to the number of accounts being processed.

[62] Clause 2.10 of SLA 2005 contains the warranty sought by Mr Johnson in relation to the incorporation of CMS intellectual property into FPF’s system. It provides:

CMS acknowledges that the Client Group has developed its own software and system for the processing of credit card and hire purchase transactions and is in the process of further developing that software and system to enable the migration of all transactions for which the Client Group requires use of the Software to the Client’s own system. Client represents and warrants that the Client Group’s own software and system is not and will not be based upon or derived from the Software; provided that the exclusive remedy for any breach of this representation is provided for in the Heads of Agreement between the parties of even date herewith.

Pleading

[63] The pleaded representations are in two categories:

(a) (i) The use of the CMS software had not been extended beyond the data and transactions permitted to be processed under the licence granted to Farmers.

(ii) There had been no changes made to the manner in which the plaintiff was using the CMS software since the acquisition of the Farmers Finance business in July 2004.

³ The Exhibit A procedure was invoked but abandoned in circumstances set out in my judgment of

12 October 2007 in which I refused FPF’s applications to strike out, dismiss or stay the counterclaim and for summary judgment: Fisher & Paykel Financial Services Ltd v Credit Management Services Inc HC Auckland CIV-2006-404-6646. See also my judgment Fisher & Paykel Financial Services Ltd v Credit Management Services Inc HC Auckland CIV-2006-404-

6646, 16 May 2008 refusing FPF leave to appeal.

(iii) The defendant’s intellectual property and the defendant’s proprietary code in the CMS software had not been, and would not be, compromised by the plaintiff in any way.

(iv) The plaintiff’s software platform under development did not replicate any aspects of the CMS software that could be considered to be the defendant’s intellectual property.

(v) The plaintiff did not deliberately infringe the IP rights of other organisations.

Collectively “the non-infringement representations”

(b) (i) The defendant’s intellectual property could not be compromised as a result of the involvement of the plaintiff’s staff with the plaintiff’s software platform and the CMS software.

(ii) The plaintiff’s software platform and the CMS software were independently supported by the plaintiff with dedicated technical specialists located at separate sites.

(iii) None of the plaintiff’s software developers had access to the CMS software, including the defendant’s development, test or production systems or documentation.

Collectively “the ‘clean room’ representations”.

[64] The term “clean room” is something of a misnomer. It is a term of art used to describe a process commonly employed to ensure that protected information is not accessed when a computer is being operated by a third party. It is often used when data are being transferred from one software system to another. After the term was used in a letter from CMS’ American counsel to FPF, it became the collective noun for the assurances FPF is claimed to have given that there were mechanisms in place to ensure that CMS’ intellectual property was at minimal risk of being compromised.

[65] The focus of this part of Karum’s case was on the clean room representations. The question of whether there was or was not infringement of Karum’s intellectual property (the non-infringement representations) falls to be examined when the claims for breach of confidence and copyright are considered. Moreover, Karum developed this part of its case in representation and for breach of the Fair Trading Act on the basis that the clean room representations led Karum to believe that it had no reasonable basis to doubt FPF’s non-infringement representations. Karum’s position is that, based on the clean room representations, it assessed the risk of its intellectual property being compromised during the data conversion and migration

process as low. It considered that a technical review of the Lending software at the conclusion of the licence agreement in terms of Exhibit A would be adequate to address any infringement which occurred, notwithstanding the clean room protections.

Legal principles

[66] Karum claims to cancel the heads of agreement pursuant to s 7(3) and (4) of the Contractual Remedies Act, which gives a party to a contract the right to cancel if induced to enter into the contract by a misrepresentation, whether innocent or fraudulent, made by or on behalf of another party to the contract and:

(a) The parties have expressly or impliedly agreed that the truth of the representation is essential to the representee; or

(b) The effect of the misrepresentation will be:

(i) Substantially to reduce the benefit of the contract to the cancelling party; or

(ii) Substantially to increase the burden of the cancelling party under the contract; or

(iii) In relation to the cancelling party, to make the benefit or the burden of the contract substantially different from that represented.

[67] In order to succeed on this part of its claim, Karum must show that: (a) The representations were false statements of fact.

(b) It was induced into enter into the contract by the representations.

(c) As a result, the benefit or burden of the contract has been substantially affected.

[68] For the purpose of the Fair Trading Act cause of action, Karum must show that the representations were capable of being misleading and led to loss or damage.⁴

The question of whether there has been deceptive or misleading conduct will depend upon the context, including the characteristics of the person affected. The question is whether a reasonable person in the claimant’s situation would likely have been misled or deceived.⁵

Truth or falsity

[69] For the purpose of considering the clean room representations, it is convenient to follow the framework used by Karum in final submissions. The alleged misrepresentations were divided into three categories:

(a) Statements of fact that are said to have been untrue at the time the clean room memorandum was provided to CMS viz:

(i) Sheila Mason and Davorka Horvat⁶ only had the limited roles described in the memorandum.

(ii) FPF was independently developing its own revolving credit platform, which did not replicate any aspects of CMS intellectual property.

(iii) Access to CMS systems and documents was restricted to previous RFS staff.

(b) Representations alleged to be half truths at the time the memorandum was provided to CMS:

(i) RFS and Lending information technology support teams remained technically, geographically and culturally separate at

_{separate sites.}

⁴ _{Red Eagle Corporation Ltd v Ellis [2010] NZSC 20; [2010] 2 NZLR 492.}

⁵ _{Ibid at [28].}

⁶ A programmer for RFS whose Christian name is incorrectly spelt in the memorandum.

(ii) None of the FPF IT developers had access to CMS

development, test or production systems or documentation.

(iii) Once FPF had developed its revolving credit functionality in Lending, it would simply migrate customer data from the CMS software platform to the FPF Lending system.

(c) A representation that FPF intended to keep the processes and procedures described in the memorandum in place until the data migration had been completed.

(a) Untrue statements

Sheila Mason and Davorka Horvat only had the limited roles described in the memorandum⁷

[70] Mrs Mason moved from RFS to FPF in April 2004. She became FPF’s IT Development Manager when the incumbent (Chris Hall) left in October 2004. As previously noted, she had been involved in credit management roles for FTC for many years. Although she did not have technical skills (for example, as a programmer), she had working knowledge of the CMS software going back to the time it was first licensed in 1994. The description of her skills and experience in the memorandum is accurate. However, as she did have access to CMS documentation, the statement that none of the FPF system developers have access to CMS development, test or production systems or documentation is incorrect at least in that respect.

[71] Karum says that it was highly misleading to describe Mrs Mason’s as a non- technical role, but I consider it fairly characterised her job as IT development manager. It is true that she had the leading role in Project Orpheus but on technical matters she relied on specialist qualified staff. In closing submissions she was described by Karum’s counsel as “often hopelessly wrong in her grasp of technical

_matters”.

⁷ The relevant extract is at [51] above.

[72] Ms Horvat worked as a programmer for RFS from March 1998. Her main role was repairing and maintaining the CMS elements of the credit management system. She said that by 2001 she had become the staff member with most knowledge about the system. In 2002–3 her title changed to Senior Systems Analyst, whose role is to propose solutions to a programme to meet a specific business requirement. The job does not usually involve writing codes.

[73] In June 2004, Ms Horvat moved to FPF, retaining her title. That involved a physical move from the premises of FTC/RFS to FPF’s premises at Highbrook Drive, East Tamaki. She said she did not expect (or want) to undertake programming work in her new role but as part of familiarising herself with the FPF system in her first three months at FPF, she wrote seven programmes for the Lending platform. After speaking to Mrs Mason, she was not required to do any more programming work.

[74] Ms Horvat also worked on the development of an “off-the-shelf” debtor management system which FPF had purchased and assessed whether it could be used for RFS collections. In early 2005, she moved back to RFS to work on a special project, returning to FPF in April/May 2005 to work on Project Orpheus.

[75] The clean room memorandum described Ms Horvat’s responsibility for the development of the debt collection system. As she had ceased doing any programming work some months beforehand, I consider that to have been an accurate description of her role at the time. In any event, I am satisfied that her earlier work on Lending programmes did not require access to or the application of her knowledge of the CMS system. One of the programmes concerned statement history and unbilled transaction screens. However, for reasons I explain later in this

judgment,⁸ I am satisfied that she did not rely on her knowledge of the CMS system.

[76] The relevant section of the clean room memorandum was plainly never intended and could not have been understood to have been more than a brief

_{summary of the essential nature of what those two employees were doing. Subject to}

⁸ At [255]–[257].

the reference to Mrs Mason not having access to CMS documentation, I consider this part of the memorandum to have been accurate.

FPF was independently developing its own revolving credit platform which did not replicate any aspects of CMS IP

[77] The clean room memorandum did not say (and it was not pleaded that FPF represented) that FPF was independently developing its own revolving credit platform which did not replicate any aspects of CMS’ IP. However, underlying Karum’s case is the proposition that from an early stage, and certainly by the time the memorandum was tendered, FPF was actively seeking to use elements of the CMS software in its Lending platform. It is convenient to begin a consideration of this part of the claim with a review of the way in which the Lending platform was developed.

[78] The Lending system was created in 1994 to manage hire-purchase transactions involving Fisher & Paykel appliance whiteware through retail outlets. It developed progressively since then. It comprised 753 programmes in 1994. By the end of 2000, they numbered 1,619.

[79] In 2004 when FPF acquired RFS, it offered a range of credit products. All were supported by Lending. One of the products with particular relevance to this proceeding is a payment card known as the “Q card”, which was launched in 2000. It is available for use in some 8,500 retail stores around New Zealand. It is marketed as a credit card alternative that can be used for small purchases but also for larger items and repayment over longer periods.

[80] Both the Q card and Farmers card operate a revolving line of credit facility with an associated credit limit, although there are important differences in the way each operates. The Farmers card operates only as a standard credit plan whereas Q card customers can make purchases under either fixed or flexible plans.

[81] In 2003 the decision was made to extend the Lending platform to support

Q card. This was to replace a platform used in partnership with ANZ Bank since

Q card was introduced in 2000, which was thought to be inadequate to support a planned expansion of the functionality of Q card. The task of replacing the ANZ Q card with an in-house product was called “Project Innovator”. It was developed during 2003 and 2004 and finally launched in 2005.

[82] The revolving credit functionality required for Q card was accordingly being developed when RFS was acquired. FFP was aware that the revolving credit platform being developed in Lending would need to accommodate the Farmers card product. Although the two products are similar, they operate differently and have a different client base. It was well understood that the migration of the RFS business to the Lending platform would require customisation of the Lending system to support the Farmers card.

[83] During 2004, however, other projects took priority over development of the Lending platform to accommodate the Farmers card. The FPF IT team was primarily focused on Project Innovator, modifications to meet the requirements of the Credit Contracts and Consumer Finance Act 2003, capacity verification and other projects associated with Project Orpheus, such as the extended warranty conversion. Some preparation for data migration was being undertaken but was not perceived to have pressing urgency.

[84] In late 2004 and early 2005 an internal debate took place within FPF as to whether the project should remain a data migration project with RFS business rules and policies largely being absorbed within existing FPF rules and policies or whether RFS’s distinct rules and policies should be maintained. FPF managers who had been involved in the development of Lending, argued for the former, but the concerns of FTC’s business users that there should be no change for RFS customers prevailed. As a result, the project increased in scope to include the integration into the Lending platform of all but any redundant RFS rules and policies. The increased scope of the project was signed off on 1 April 2005.

[85] I will later consider in more detail whether the decision to maintain RFS business rules and policies in Lending led to FPF replicating aspects of CMS software in Lending. It is clear, however, that when the clean room memorandum

was written and handed to Karum, FPF was focused on developing its Lending platform. For that purpose it had begun an analysis of some aspects of RFS business requirements and had sought the assistance of RFS analysts and users. However, I am satisfied their involvement did not render what was said in the clean room memorandum untrue.

[86] Mr Miles QC submitted that during 2004, as part of Project Orpheus, FPF personnel, led by Mrs Mason, were freely referring to and accessing CMS software and proprietary material. He said that RFS and FPF technical staff were working together and not totally separately, as the clean room memorandum had suggested.

[87] Karum placed particular weight on a document prepared at Mrs Mason’s request by Nicole Leonard and Doug Burger dated 15 June 2004 entitled “Farmers Stores: Credit Request Processing”, which reported in detail on credit authorisation procedures. Ms Leonard was a business analyst who had been with FTC/RFS for many years and held the position of Application Development Leader at RFS. Mr Burger was a contractor to FTC. Both were very familiar with the CMS system. In the course of preparing the report, Ms Leonard asked Mrs Mason to tell her “how technical she wanted the document to be”. Mrs Mason’s response was:

My thoughts for the use of the documentation is so that you and Malcolm [Jenkins] can get together to see whether it is feasible to replicate FTC’s Store requirements in the FPF systems. Your mention on Tuesday regarding Mazerunner, I think details of that to Malcom may also be useful. Send me what has been done so far and I will review.

(Mazerunner was the subsystem used as part of the authorisation procedure in the FTC/CMS system.)

[88] Mrs Mason said in evidence that she asked Ms Leonard and Mr Burger to prepare the report because they had knowledge of the authorisations process. She said she wanted a document that would explain the interfaces between FTC and RFS. She would give it to Datacom (who had been retained to assist) so that they could come up with a solution for FPF. The document provided a high level of detail and, Ms Mason acknowledged, contained a great deal of confidential information. She said she was surprised to find that level of detail but said Datacom would not have used the information other than to determine the interface that needed to be

written for FTC stores and to ensure that their point of sale systems still interacted with RFS.

[89] At the time this report was commissioned and written FPF was, of course, unaware that it did not have the right to access (or even to use) the CMS system. The report was a first step in the process of creating an interface between FTC and FPF to replace the existing interface between FTC and RFS. It was logical and not at all sinister that Ms Leonard and Mr Burger should be asked to write the report. They had the required knowledge of the FTC/RFS infrastructure. Indeed, Mr Burger had been involved in writing the original interface.

[90] A second report relied on by Karum entitled “RFS Integration Requirements” was prepared by Paul McCarthy, Team Leader, Business Analysts, who reported to Mrs Mason. Its purpose was to carry out a detailed analysis of the RFS/FTC business and to identify the functionality missing in Lending. The first draft was circulated on 13 December 2004. Karum submits that it shows that at this time there were substantial infringements of protocols in CMS IP and makes the clean room memorandum materially untrue at the time it was given to Karum.

[91] I do not agree. I see it as no more than a necessary first step in the business integration process. It did not require or involve accessing CMS source code or intellectual property. It does not invalidate any representation to the effect that FPF was independently developing its own revolving credit platform. During 2004, FPF focused on development of its own Lending platform, both for the purpose of serving Q card and to enable it to meet FTC’s particular requirements when integration took place.

Access to CMS systems and documents was restricted to previous RFS staff

[92] Beginning in 2004 until migration occurred, FPF had to maintain two parallel business operations – one for the RFS business and one for the FPF business – while planning a transition which would not involve any disruption. This required RFS staff maintaining the CMS platform at the same time as processes were developed for migrating the RFS ledger across to the FPF platform. In the main, RFS IT staff

involved in the daily operation of the CMS system remained separate from the FPF IT staff. As already noted, Mrs Mason and Ms Horvat moved to the FPF team in order to deal with the expanded work load caused by and after the transition. They were the only FPF staff who could access CMS systems and documents. FPF IT staff were instructed and understood that the CMS code was not to be accessed except (in the case of Ms Horvat) for the purpose of ongoing maintenance of the CMS platform.

(b) Half truths

Support teams remain technically, geographically and culturally separate⁹

[93] The RFS and FPF IT teams were at different locations until March or April

2005, when RFS and FTC IT personnel moved to the FPF premises at Highbrook Drive, East Tamaki. The move had been planned for some time. Two extra wings had been built to accommodate the additional staff. Some of those who made the move were RFS programmers who had access to the CMS source code. They were accommodated on the same floor as FPF staff who were involved in the development of the Lending platform, though the two teams were physically separate.

[94] At the time the memorandum was written and handed over, the statement that the support teams were technically, geographically and culturally separate was correct. After the move it could no longer be said that they were geographically separate. For Karum it is submitted that, given that the representations were describing the protections in place for the CMS software during the term of the SLA

2005, they were undoubtedly false at the time they were made.

[95] I do not accept that what was said was intended to describe the state of affairs that would continue for the duration of the licence. In describing the separation of RFS and FPF systems, the memorandum is carefully expressed to describe only present arrangements. There is nothing which might have conveyed that the

_{situation was static. And the way in which discussions developed gave no hint to}

⁹ See [53] above.

FPF that Mr Johnson was interpreting the document in any other way. Mr Gillanders said that in discussions with Mr Johnson the question of whether or not separation would continue simply was not an issue. He did not seek elaboration or clarification of what was in the memorandum. I am satisfied that this part of the memorandum was true at the time it was made and was neither intended nor had the effect of misleading Karum. In my view, FPF management understood Karum’s concerns and were committed to ensuring that the two systems were operated independently until integration had been completed.

Only two of the existing RFS team members (Mason and Horvat) have accepted roles relating to the FPF systems¹⁰

[96] That statement was true at the time the memorandum was written. No other RFS staff were engaged by FPF. The involvement of RFS staff was confined to assisting FPF developers to identify the business needs of FTC/RFS as a first step to determining what additional functionality was required in Lending. In time RFS staff became more directly involved in developing enhancements to the Lending platform but even then their role was to report on FTC and RFS business requirements in order to ensure that FPF systems had the requisite functionality. I consider FPF to have been mindful and respectful of Karum’s concerns at and from the time the settlement was negotiated and agreed.

No FPF staff had access to CMS development, systems, production system or documents

[97] The statement in the clean room memorandum was in fact that none of the FPF system developers have access to CMS development, test or production systems or documentation.¹¹ Except in relation to Mrs Mason, that statement is accurate. The system developers of FPF did not have access to CMS proprietary information at the time the memorandum was written and I am satisfied that the intention of senior management was that that should continue to be the case. FPF developers

_{relied on FTC/RFS personnel to provide the information necessary for them to assess}

¹⁰ _{See [51] above.}

¹¹ See [51] above.

the additional functionality required in Lending to accommodate RFS business requirements. Karum says that in the course of this process (and after the settlement was concluded in January 2005), FPF developers and business analysts were provided with CMS proprietary information. However, that is a different issue which I will consider in relation to the specific claims of breach of confidence and copyright.

Once FPF had developed its revolving credit functionality in Lending, it would simply migrate customer data from the CMS software platform to the FPF Lending system

[98] The relevant passage of the clean room memorandum read as follows:

4. Future Migration Strategy

Post business integration (June 2005), all CMS currently used by RFS will be decommissioned and customer data migrated to the FPF custom written Lending and Revolving Credit systems running on the Solaris operating system with Sun hardware. Mainframe infrastructure currently supporting CMS will be retained by Farmers Retail operations.

The memorandum went on to conclude in the summary section:¹²

Systems at FPF are considered to provide a competitive advantage over those at RFS and have been selected as the preferred platforms for migration of RFS receivables, planned to be completed by July 2005.

[99] These statements were a fair summary of FPF’s intention at the time the memorandum was written although they masked the internal debate, unresolved at that time, over the way in which business integration should be achieved. Karum submits that Mr Gillanders and Ms Holbrook were well aware of the change of direction by December 2004 at the latest. There is reliance on a passage in a memorandum to Mr Gillanders, copied to Ms Holbrook, of 31 December 2004, which reads as follows:

Information Systems Requirements

A strategic decision has been made to migrate RFS customers, currently processed using the CMS system to the custom developed Lending system used by FPF. A prerequisite to customer migration is the development and

¹² See [53] above.

implementation of revolving credit functionality on the FPF systems and creation of interfaces and functionality to ensure Farmers retail service is not impaired. In addition, a new debt collection system (from Merchantile) is planned to be implemented.

[100] At the time this memorandum was written management had yet to determine the direction that Project Orpheus would take. I do not understand Ms Nobbs to be announcing any change of strategy. I do not think what she wrote would have caused Mr Gillanders and Ms Holbrook to question the essential accuracy of the clean room memorandum, assuming they saw Ms Nobbs’ memorandum before meeting with Mr Johnson. The memorandum was not put to either in cross- examination.

(c) FPF would keep the clean room processes and procedures in place

[101] Karum submitted that FPF had no intention of following through with the clean room representations. The memorandum was said to have been crafted to provide Mr Johnson with comfort that FPF was only carrying out a data migration in an environment in which protections were in place for the CMS software.

Sanitising the clean room memorandum

[102] The memorandum went through a number of drafts. I accept Ms Holbrook’s evidence that it was produced initially as a briefing paper for her and Mr Gillanders. Once received it was decided to offer a copy to Mr Johnson. It was then reviewed by them as well as others responsible for providing Ms Nobbs with the information she used when preparing the first draft.

[103] Mr Miles submitted that the changes made to the memorandum were made to present a picture of total systems and staff separation during FPF development, followed by a simple customer data migration. I have carefully considered the changes made and the evidence of Ms Holbrook, who was closely questioned about her knowledge of the changes. I do not accept that the changes were made for the purpose of creating a misleading picture. On the contrary, my assessment is that they were made for the purpose of achieving greater accuracy. It was suggested, for

example, that references to “integration” were removed in order to convey that what was being considered was a simple data migration project. Yet, the passage discussing future migration strategy explicitly states that there would be business integration, followed by decommissioning of CMS modules currently being used and the migration of customer data to the Lending system. In my view, that accurately described the process FPF was then planning to undertake.

No protections in place

[104] Karum submits that FPF’s failure to put in place procedures to maintain the “protections and circumstances” described in the clean room memorandum shows its disregard for Karum’s intellectual property. Karum points to the absence of any written explanation or directives relating to the clean room obligations.

[105] The memorandum itself was not given wider circulation. Mrs Mason, for example, said she had no knowledge of it. However, there was a great deal of evidence which showed that FPF personnel were made aware of FPF’s obligations to protect Karum’s confidential information including the CMS source code. Mrs Mason said she was asked by Ms Nobbs in late 2004 to keep FPF and RFS staff separate and she did so. She said in an email to Ms Leonard on 22 February 2005 on the subject of migration:

I talked to Chris [Holmes] regarding this as he was making arrangements to have CMS access on Davorka’s PC as well as Lending access. However, in hindsight it might not be a good idea, considering PRJ and their requirement for us to keep CMS separate. Therefore, if Davorka needs to work on CMS, Chris is going to set up a separate PC in the contractor area to allow this.

[106] Chris Holmes was contracted to FPF. At this point the RFS team was still located in a separate office. The email referred to Mr Holmes wanting to have access to CMS remotely at FPF’s premises. Ms Horvat had two computers – one for her role with Lending and one to enable her to provide continuing support to CMS. She was the only one who had that dual role.

[107] On 5 April 2005, Ms Holbrook advised Mr Scott that she and Mr Gillanders had met with key individuals from FPF to discuss the procedures being followed to

ensure that no proprietary trade secret information of CMS would be incorporated into FPF’s system. She advised also that there was now expected to be slippage in the timing of the migration of data from the CMS system to FPF’s system. The plan was now to migrate in September 2005. She also advised that FPF would like to appoint KPMG to independently review FPF’s system and the CMS system as part of the process being adopted by FPF to ensure that there was no tainting of FPF’s system. This proposal was never put into effect.

[108] On 14 June 2005, Ms Nobbs sent an email to key staff members involved in

Project Orpheus. It read as follows:

Subject: CMS IP

As you are aware, we need to protect the IP of the CMS system and surrounding functionality to ensure that “trade secrets” are not transferred to FPF Lending systems. This is a non negotiable requirement and will be subject to audit shortly after integration (with potential significant consequences should a breach be proven).

To mitigate potential issues, we have continued to physically separate the RFS team from the FPF team, despite our desire to fully integrate. (Please accept my apologies for any short term inconvenience this may cause).

To further ensure protection of IP, please ensure that no FPF people have access to CMS code (either electronically or in printed format).

If there are any queries regarding the above, please don’t hesitate to contact

me.

Many thanks for your co-operation regarding this critical issue. Kind regards

Pam

[109] On 24 July 2005, Mrs Mason sent a memorandum, apparently in response to concerns about hire purchase contracts in CMS that had been “set up incorrectly and need to be fixed”. She advised Mary Ward (a business analyst with FPF):

No I cannot give you access to CMS, we have to be very careful as we are going to be audited when we convert by the owners of the CMS software, who are not convinced that we are not copying parts of CMS.

[110] To similar effect is an email sent to Ms Ward by Ms Leonard on 19 August

2005:

Since I am not allowed to show you any CMS code, I have tried to work out what it is doing from looking at the code. I have combined this with the information from Karum’s billing presentation document. Hopefully this will help ...

[111] Ms Leonard was entitled to look at CMS code as she was supporting that system. In my view, for reasons which I will elaborate on later in this judgment, she was also entitled to look at the CMS code for the purpose of the Lending customisation project, to ascertain business rules and parameter settings or tolerances, e.g. the extent to which a customer could exceed a credit limit.¹³

Data migration

[112] Karum submitted that the data migration project required separation between the source IT team (RFS) and the target IT (FPF) team as described by Mr Maliga, a payments systems technology Management Consultant called by Karum. Whether or not adequate protections were put in place is not an issue that needs to be considered in the context of the alleged misrepresentations. The clean room memorandum could not reasonably be understood as providing any assurances about the way in which the data migration would be carried out. Indeed, at that stage FPF itself had not decided on the way the business integration project would move forward. The memorandum was an attempt to provide a snapshot of a process that still had a long way to run. That is the way it reads. That is the way I believe it was understood.

Summary

[113] I consider the clean room memorandum to have been an honest and fair attempt to summarise the situation at the time it was written. It emerged largely unscathed from a searching line-by-line examination undertaken with the advantage of hindsight and a great deal of information which would not have been known to its authors. It largely succeeded in conveying the essential features of a complex and

_{dynamic process that was really only just getting underway.}

¹³ The difficulty of ascertaining tolerances is considered further at [208].

Inducement

[114] Assuming, contrary to my findings, that the clean room representations were false and misleading, I turn to consider whether Mr Johnson was induced by what was stated in the memorandum and previously to enter into the settlement agreement and licence.

[115] As already noted,¹⁴ when Mr Johnson realised that FPF was continuing to use the CMS software, he had two major concerns. The first was that FPF was using the software without a licence. The second was that FPF had made or may make improper use of its opportunity to access the CMS system in the development of its Lending platform. FPF’s response was that it was happy to enter into a licence (and to pay a licence fee) and to give an assurance that it had not improperly accessed CMS’ intellectual property and had no intention of doing so. At an early stage this was backed by an offer to enter into an agreement that ensured that FPF would deal

with the CMS software in a manner in line with CMS’ expectations.¹⁵

[116] Additional issues of concern were raised in the course of ongoing discussions. Mrs Mason’s position was discussed and addressed.¹⁶ Mr MacFarlane, the Chief Executive Officer of FPF, gave an assurance that CMS’ intellectual property was not being utilised by FPF for the purpose of developing its own system and advised that FPF would be happy to provide appropriate undertakings in a deed of covenant.¹⁷

[117] However, Mr Johnson was not to be persuaded. He made clear his belief that CMS intellectual property had already been compromised – “the genie is out of the bottle”. I do not think his suspicions in this regard were ever allayed. He seemingly remained convinced that Karum’s intellectual property was at risk and was sceptical of FPF’s assurances. In Mr Johnson’s letter of 1 December 2004, he said that the only acceptable mechanism to protect CMS was to enter into a licence permitting

_{those uses. Shortly afterwards, when Mr Gillanders became involved, he went}

¹⁴ _{See [27] above.}

¹⁵ _{At [32] above.}

¹⁶ _{See [35]–[36] above.}

¹⁷ At [43].

further and offered what became the Exhibit A process to provide reassurance to Mr Johnson that FPF was not using Karum’s intellectual property. That offer was accepted with alacrity, Mr Scott’s email of 6 December enclosing both a draft heads of agreement and an Exhibit A procedure. In the circumstances, I find Mr Scott’s advice that CMS had come to question FPF’s good faith curious.¹⁸ It seems to me that FPF had been proactive and constructive in searching for a resolution. In my view, Karum’s criticism, and the threats of legal proceedings that accompanied it, was part of a strategy to apply pressure to FPF to finalise an agreement.

[118] The major difference between the parties from that point was whether a new licence should be entered into (as CMS wanted) or a deed of covenant recording FPF’s agreement to be bound by the terms of the 1994 addendum, as FPF wanted.¹⁹

There were also questions as to the terms of any licence.²⁰ When the conference of

22 December 2004 took place, the form of the licence was the main issue.

[119] By the time the clean room memorandum was presented at the meeting in San Francisco, there was agreement in principle which would ensure that Mr Johnson’s main objectives were met. It remained to finalise the form and terms of the licence and the amount of the fee. It was agreed that there would be no unlicensed use of CMS software and there was a procedure to detect and provide a remedy for any unauthorised access to CMS.

[120] The agreement brought with it a windfall gain for Karum, who would not have been entitled to any further payment if RFS had not been sold or had stopped using the CMS system on sale. Under the new licence, Karum became entitled to a payment of US$400,000 by 17 January 2005 and, based on up to 500,000 active accounts, an additional fee of US$200,000 per annum would be payable if FPF required use of the software beyond 1 April 2006. It is not at all surprising that, as Mr Gillanders and Ms Holbrook said, Mr Johnson visibly relaxed when advised that

_{FPF was prepared to pay US$400,000.}

¹⁸ _{At [41].}

¹⁹ _{At [54].}

²⁰ At [58].

[121] There is no indication that Mr Johnson ever accepted FPF’s assurances that CMS’ intellectual property had not been compromised or that the risk of future infringement was minimal. He never retreated from his position that there had already been violations. Ms Holbrook said he was “doubting of everything”. He accepted the Exhibit A procedure as soon as it was suggested. Thereafter, no particular concerns were conveyed by CMS as to the procedures that would be put in place to protect CMS’ intellectual property. I accept Mr Gillanders’ evidence that Mr Johnson appeared unconcerned about the statements in the memorandum because he was satisfied that any issues that might arise would be dealt with by the Exhibit A review process.

[122] Mr Johnson required the incorporation of cl 2.10 into the licence.²¹ He said in evidence that this was only ever intended to cover minor inadvertent infringements that occurred notwithstanding the protection envisaged by the clean room memorandum. I do not accept that. There is nothing in the circumstances in which the licence was negotiated to suggest that the words of cl 2.10 were not intended to be read literally. Mr Johnson was obliged to concede that what was in the clause “captured” the representations made by Mr MacFarlane and Mr Gillanders and the process described in Ms Nobbs’ memorandum.

[123] If Mr Johnson had relied on any other representations, I believe he would have insisted on their incorporation into the agreement. I am satisfied that cl 2.10 was sufficient to meet his concerns.

[124] By the time the clean room memorandum was presented at the 6 January meeting, I think it was of little interest to Mr Johnson. He had already achieved his key commercial objectives. I am satisfied that the statements made in the course of negotiations and in the clean room memorandum had no material bearing on his decision to enter into the heads of agreement and to grant a new licence.

Entire agreement

_{[125] Clause 10.1 of the licence provided:}

²¹ Set out at [62] above.

This Agreement, and the Schedules hereto, contains the entire agreement of the parties with respect to the subject matter hereof and supersedes all prior oral or written discussions, representations, understandings and agreements.

Mr Galbraith QC submitted that the clause should be given full effect and exclude reliance on any prior representations.

[126] The purpose of an entire agreement clause was discussed by the Court of

Appeal in PAE (New Zealand) Limited v Brosnahan.²² The Court said:²³

An entire agreement clause, however, is not absolute or conclusive. Section 4(1) [of the Contractual Remedies Act 1979] recognises a wide judicial discretion to determine whether it is “fair and reasonable that the provision should be conclusive. While the issue is to be determined “having regard to all the circumstances of the case”, the specified criteria focused the inquiry on an assessment of the relative positions of the parties and their access to independent legal advice. Its apparent purpose is to protect one party’s relative vulnerability from another party’s power to impose an exemption from liability which is contrary to the factual reality or an existing legal obligation and is thus unreasonable and unfair. Section 4(1) is a mechanism for striking balances, both individually between parties and conceptually between freedom of contract and unfair or unreasonable commercial conduct.

[127] The party relying on the entire agreement clause has the initial evidential burden to prove that it is fair and reasonable to accept the terms of the exclusion clause as conclusive.²⁴ In my view FPF has discharged that burden. This was an arm’s length commercial negotiation between two well resourced parties. Karum had the benefit of Mr Scott’s involvement throughout the negotiation. He is experienced counsel who had been Mr Johnson’s legal adviser for many years.

Karum clearly had the superior bargaining position. There is little doubt that RFS had no right to continue using the CMS software following its separation from Farmers retailing activities. Karum had strong grounds for injunctive relief, which would have had disastrous consequences for FPF. I am satisfied that cl 10.1 should take effect according to its tenor. Karum could not have relied on prior

_{representations to cancel the licence.}

²² _{PAE (New Zealand) Ltd v Brosnahan [2003] NZCA 61; [2009] 10 TCLR 626.}

²³ _{Ibid at [15].}

²⁴ Ellmers v Brown (1990) 1 NZ ConvC 190, 568.

Infringement

Background

[128] On 30 March 2006, FPF advised Karum that it had completed migration of data from CMS software to the FPF platform and that it did not need to renew SLA

2005.

[129] Pursuant to the Exhibit A procedure, Paul Hart,²⁵ as CMS nominee, conducted a preliminary review of the FPF software platform in New Zealand in July

2006. He recorded his findings in a report dated 31 July 2006 entitled “Preliminary Review”. He concluded in the report that components of the CMS software had been incorporated into the FPF software by a variety of methods and on what Mr Hart described as an “extensive” and “pervasive” scale. The report was provided to FPF, which responded in terms of the Exhibit A procedure objecting to the conclusion reached in the report.

[130] Before further steps in the Exhibit A process could be taken, CMS issued arbitration proceedings in the United States under the dispute provision in SLA 2005. FPF’s objection to the jurisdiction of the arbitral tribunal was upheld. The tribunal found that the parties had agreed to resolve their dispute under the Exhibit A procedure and not under the software licence agreement. The counterclaim in this proceeding followed.

[131] The parties agreed to a further and more extensive review which took place in Dallas, Texas in November 2010. Mr Williams and Mr Hart carried out the inspection and prepared a further report, the Dallas “Clean-Room” review, a copy of which was provided to FPF in December 2010. The report concluded that the code, logic, algorithms, database designs and schema behind many of the CMS software sub-systems and components had been incorporated into the FPF software. The

_{report, supported by documents discovered by FPF, provided the basis of the}

²⁵ With Dale Williams, Mr Hart was largely responsible for the development of the CMS system –

see [17] above.

evidence of Mr Williams and Mr Hart that there had been extensive use by FPF of confidential information embedded in the CMS software.

Pleading

[132] Karum claims that in the course of Operation Orpheus FPF infringed its intellectual property rights in relation to eight components of the CMS system:

(a) Payment calendar;

(b) Delinquency calendar; (c) Special codes;

(d) Statement and intercept codes; (e) Stock keeping units;

(f) Reporting;

(g) Statement history and unbilled transactions; and

(h) Agency.

[133] The claim in relation to stock keeping units was not pursued. In each of the remaining categories, Karum pleads that FPF breached a duty of confidence owed to Karum by:

(a) Failing to maintain the confidentiality of the CMS software; (b) Failing to comply with the clean room representations; and

(c) Incorporating Karum’s CMS software or parts of it into FPF’s own

software platform.

[134] In relation to the first four categories, there is also a claim for infringement of copyright.

Breach of confidence – principles

[135] The elements required to establish a claim for breach of confidence are well established. Karum must show:²⁶

(a) The information has the necessary quality of confidence about it;

(b) The information has been communicated in circumstances importing a duty of confidence; and

(c) There has been an unauthorised use of that information to the detriment of the person communicating it.

[136] FPF says that in addition to the three established elements, Karum must establish that it has standing to sue and that its claim is adequately particularised.

Standing to sue

[137] FPF questions whether Karum has established that it is the party who is entitled to sue.²⁷ It submits that if there is any party that is entitled to the confidence that Karum claims, it is Zale. However, it is clear that Karum’s exclusive rights and the vastly diminished nature of Zale’s interest entitles Karum to assert rights to confidentiality in the CMS software.

Particulars

[138] FPF claims that there is a lack of clarity over exactly what information is said to be confidential and to have been used. However, I find Karum’s case in this regard was adequately explained. The confidential information resides in the CMS

_{software supplied to FTC/RFS. I do not understand Karum to rely on property in}

²⁶ Coco v AN Clark (Engineers) Ltd [1969] RPC 41, adopted by the NZ Court of Appeal in AB Consolidated Ltd v Europe Strength Food Co Pty Ltd [1978] 2 NZLR 515 at 520 and in Norbrook Laboratories Ltd [2004] NZCA 56; [2004] 3 NZLR 49.

²⁷ Fraser v Evans [1969] 1 QB 349.

software written by RFS after 1994 except to the extent that it incorporated CMS

information.

Quality of confidence

[139] The quality of confidence is conferred by the application of the skill and ingenuity of the human brain; but will be lost if the information becomes public knowledge or public property.²⁸ The converse, however, does not apply. Simply because information is not in the public domain does not mean it has the necessary quality of confidence. It still must have the essential qualities of originality or novelty or ingenuity.

[140] There is little doubt that, in general terms, the CMS software has the necessary quality of confidence. Its confidential nature was recognised in negotiations between FPF and Karum leading to the grant of SLA 2005. Karum submitted that the terms of the licence make the proprietary confidential nature of the CMS software clear, referring in particular to cl 2.3 which provides:

Client acknowledges and agrees that the Software and the systems, ideas, methods of operation, and information contained therein are proprietary “trade secret” information of CMS, the use and disclosure of which must be continuously controlled and that the Software is protected by the Copyright Act and treaties of the United States. Without limiting the generality of the foregoing, Client will not make the Software or any part thereof, including screen-shots, available or accessible to third parties (not being members of the Client Group).

[141] Karum also refers to clauses in 2005 SLA requiring non-disclosure agreements from any third party credit bureaus engaged,²⁹ and to maintain all proprietary information which has not become in the public domain in strict confidence and to take all reasonable steps to ensure that such proprietary

_{information is not disclosed to others.}³⁰

²⁸ _{Coco v AN Clark (Engineers) Ltd at [47].}

²⁹ _{Clause 1.3.}

³⁰ Clause 2.5.

[142] Of course, the terms of the licence are not conclusive. It remains necessary for Karum to establish that the information relied on has the necessary quality of confidence.

[143] It is accepted that the source and object code of the CMS system have the requisite quality of confidentiality. The status of other elements of the software is not so clear-cut, as will become apparent when specific subsystems are discussed. A key issue is whether CMS can assert confidentiality in respect to aspects of the system which can no longer be regarded as secret and which simply reflect the business policies and rules of FTC/RFS.

[144] The negotiations leading up to the grant of the licence and the terms of the licence itself provide the basis for importing an obligation of confidence. I do not understand FPF to dispute that any information that has the necessary quality of confidence was communicated in circumstances importing a duty of confidence.

Elements of copyright infringement

[145] In order to establish breach of copyright, Karum has to establish that:³¹

(a) It is the owner of a copyright work; and

(b) FPF has infringed its copyright.

[146] In order to establish ownership, Karum must show:

(a) The CMS software is a work in which copyright can subsist; (b) Copyright in fact subsists in the CMS software; and

(c) Karum owns the copyright in the CMS software.

_{[147] In order to prove infringement, Karum must show:}

³¹ Henkel KGAA v Holdfast NZ [2007] 1 NZCR 577 at [34].

(a) Objective similarity between the relevant part or parts of FPF’s

Lending software and the CMS software;

(b) Those parts of FPF’s Lending software platform reproduce the whole or a substantial part of Karum’s CMS software; and

(c) A causal connection between the respective parts of FPF’s Lending software and the CMS software such that the CMS software is the source from which the relevant part or parts of Lending’s software platform has been taken.

Ownership

Preliminary issue – estoppel

[148] Karum submits that FPF is estopped from putting Karum to proof of subsistence and ownership because of acknowledgements incorporated into the SLA

2005 at cl 2.2, which reads in part:

CMS shall own all right, title and interest in and to all intellectual property rights including ... copyright and trade secret rights, relating to the Software ...

[149] Estoppel by deed or other instrument in writing binds parties only on claims under the instrument.³² It cannot be invoked when, as here, the claim is brought in copyright.

Ownership

[150] Ownership of the CMS software was determined in the judgments directed to that issue.³³ I found that Karum is not the owner of copyright in the CMS software

_{but is the exclusive licensee. Karum has accordingly rights and remedies concurrent}

32. McCathie v McCathie [1971] NZLR 58. See also Halsbury’s Laws of England Estoppel (online ed) at [1028].

³³ Judgments (2) and (3).

with those of the copyright owner.³⁴ It has leave to proceed without joinder of the copyright owner.³⁵

Subsistence

[151] On the issue of ownership, it remains to consider whether copyright subsists in the works. FPF submitted that copyright cannot subsist in the works the subject of Karum’s claims and has not shown that copyright in fact subsists in the copyright work.

[152] The CMS software is pleaded as comprising: (a) A computer programme; and

(b) Related documentation and materials.

[153] The particulars pleaded are cl 1.1 of the SLA 2005 which licensed FPF to use:

... the source and object code of the computer software programmes and related documentation and materials (together, the “Software”) identified in Schedule A ...

[154] Schedule A describes the software as:

Credit Management System as originally supplied by CMS to the Farmers Trading Company Limited under the CMS Addendum between CMS and The Farmers Trading Company Limited dated 25 July 1994 (“CMS Addendum”) being: [26 systems are then listed].

[155] In order to establish that copyright subsists in a work, it must be shown that the work is:

_{(a) Original s 14(1) of the Copyright Act 1994 (the Act);}

³⁴ _{Copyright Act 1994, s 123.}

³⁵ Judgment (3) at [38] – [39].

(b) That it qualifies for copyright under either s 18, because the author(s) are citizens of New Zealand or a prescribed country or s 19, because the work has been first published in New Zealand or a prescribed country; and

(c) The work has been recorded in writing or otherwise (s 15).

Originality

[156] As the concept of originality is not defined in the Act, common law principles apply.³⁶ The Act does, however, provide that a work is not original if or to the extent that it is a copy or infringement of another’s work.³⁷

[157] To be original for copyright purposes the work must originate from its author and must be the product of more than minimal skill and labour.³⁸ In a computer programme, the enquiry as to originality must be directed to the skill, judgment and labour which devised the form of expression of the programme as a literary work.³⁹

_{For FPF, Mr Galbraith submitted, relying on Henkel,}⁴⁰_{that it is not correct to}

subdivide a work into its component parts and ask whether copyright might attach to the individual parts. He said the appropriate test is to determine whether the plaintiff’s work as a whole is original and protected by copyright.

[158] However, Henkel concerned a claim of copyright which derived from a collocation or arrangement of features which were not original in themselves. In such cases copyright protection may arise because of the way in which the features have been arranged or collocated. That is not the position here. Each of the systems which comprise the whole are claimed to be original. Each was developed separately, many at different times. Though pleaded as a single system, infringement

_{is alleged in relation to a number of separate though integrated subsystems.}

³⁶ _{Henkel v Holdfast at [37].}

³⁷ _Ibid.

³⁸ _Ibid.

³⁹ Copinger & Skone James on Copyright (16th ed, Brookers, Wellington) at [3–132]; SAS Institute

_{Inc v World Programming Ltd [2010] EWHC 1829 at [206]–[207].}

⁴⁰ At [40].

[159] The threshold for originality is a low one.⁴¹ The amount of skill and labour that has gone into the creation of the work may be relevant for infringement purposes,⁴² but in proving originality it is sufficient for Karum to show that the software was the product of more than a minimal skill and labour.

[160] FPF submitted that the author or joint authors of the work must be identified and evidence adduced of the author’s expenditure of skill and judgment, citing Fairfax Media Publications v Reed International Books Australia Pty Ltd, ⁴³ where Bennett J said:⁴⁴

A “work” for the purposes of the Act is the work of a single author, except where it is a work of joint authorship. The parties agree that the author or joint authors must be identified (IceTV at [99], [105], [151]). The “author” of a literary work and the concept of “authorship” are central to the statutory protection given by the Act (IceTV at [22]). The essential source of original works remains the activities of the authors (IceTV at [96]).

[161] Bennett J went on to say, however, that he was not persuaded that it was fatal to the claim of copyright that each person making a contribution to the work was not identified in circumstances where the authors had been identified as employees holding specified job descriptions and the skill and labour involved in those job

descriptions had been identified.⁴⁵

[162] That is substantially the state of the evidence here. Mr Williams and Mr Hart explained how, as employees of Zale, they were primarily responsible for the development of the CML software working, however, as part of a large team. The skill and labour that went into the work has been clearly established. Originality has been shown notwithstanding that the identity and contribution of each employee involved was not covered in evidence.

[163] FPF further submitted that Karum had failed to show that the work was not the copy of another work, given that key aspects of versions five and six of the CMS

_{software have been present since version one was created by Zale. However,}

⁴¹ _{Ibid at [38].}

⁴² _{Ibid at [41].}

43. Fairfax Media Publications v Reed International Books Australia Pty Ltd [2010] FCA 984, citing Ice TV Pty Ltd v Nine Network Australia Pty Ltd [2009] HCA 14; (2009) 239 CLR 458.

⁴⁴ _{At [85].}

⁴⁵ At [89].

successive revisions to a complete work may result in separate copyright works if the revisions are the product of new skill and labour. The important issue is usually the originality of later versions, although copyright will continue to subsist in the earlier version.⁴⁶ Regardless, Karum is the exclusive licensee of the copyright works on the basis explained in Judgments (2) and (3).

Qualification for copyright protection under the Act

[164] As the CMS software was written prior to 1 January 1995 (when the 1994

Act came into force), Karum must show copyright subsisted in the software under the Copyright Act 1962 and that it continues to subsist by virtue of Schedule 1 of the

1994 Act.

[165] Computer programs were recognised as a form of literary work pursuant to the Copyright Act 1962 in International Business Machines Corporation v Computer Imports Ltd.⁴⁷ Karum relies on cl 5(1)(a) of Schedule 1 to the 1994 Act which provides that a work made before the commencement of the Act may qualify for copyright after commencement under ss 19 or 230.

[166] It was established that Mr Williams and Mr Hart were residents of and domiciled in the United States over the relevant period. Section 18(2)(b) provides that a work qualifies for copyright if the author is an individual domiciled or resident in a prescribed country. By s 18(3), a work of joint authorship qualifies for copyright if, at the material time, any of the authors satisfies the requirements of subsections (1) and (2). A prescribed foreign country is a Convention country in terms of s 230 of the Act or a country that is declared by Order in Council made under s 232 to be a foreign country to which any provision of the Act applies. The United States of America qualifies under both heads as a prescribed foreign country. The CMS software that Mr Williams and Mr Hart helped to develop accordingly

_{qualifies for copyright under s 18.}

⁴⁶ _{Copinger & Skone James at [3-136].}

⁴⁷ International Business Machines Corporation v Computer Imports Ltd [1989] NZHC 159; [1989] 2 NZLR 395.

[167] Karum also relies on s 19 which provides that a work qualifies for copyright if it is first published in New Zealand or in a prescribed foreign country. FPF questioned whether there has been publication, defined in s 10(1) as follows:

10 Meaning of “publication”

(1) In this Act, the term publication, in relation to a work,—

(a) Means the issue of copies of the work to the public; and

(b) Includes, in the case of a literary, dramatic, musical, or artistic work, making it available to the public by means of an electronic retrieval system;—

and publish has a corresponding meaning.

[168] FPF submitted that, because the software is available only by licence, copies have not been issued to the public.

[169] Whether or not there has been publication will vary according to the nature of the work and those who might have an interest in receiving it. In principle publication does not occur unless a work may be acquired by any member of the community.⁴⁸ But in the case of works of interest only to a limited class, publication may occur if the work is available to members of that class. Restrictions on access are permissible provided they apply uniformly. It is sufficient that there is an intention to satisfy the demands of the public, should such demand arise.⁴⁹

[170] CMS software by its very nature is of interest to only a very small section of the public. I am satisfied that it has been published by being available to members of that class who wish to access it.

Conclusion

[171] The works have been recorded as required by s 15 of the Act. It has therefore been shown that copyright subsists in the pleaded works.

⁴⁸ _{Laddie and Prescott at 5.38.}

⁴⁹ Copinger & Skone James at [1-17] and [3-178].

Infringement

[172] Karum alleges infringement has occurred by FPF copying or making an adaption or derivative work of a substantial part or parts of the CMS software in breach of s 16 of the Act. In order to establish infringement, it must show:

(a) There is sufficient objective similarity between the relevant part or

parts of FPF’s Lending software and the CMS software;

(b) FPF’s software platform reproduces the whole or a substantial part of

Karum’s CMS software; and

(c) There is a causal connection between FPF’s Lending software and the

CMS software.

Objective similarity

[173] Objective similarity does not require that there be an exact copy of the work or a substantial part of it but there must be a sufficient degree of resemblance between what is said to have been copied and the work in which copyright is said to subsist.⁵⁰ The focus is on the number and nature of the similarities, rather than the differences. ⁵¹ Similarities which are commonplace or unoriginal will be disregarded.⁵²

Substantial part

[174] Whether a part is a substantial part of the copyright must be decided by its quality rather than its quantity.⁵³ What must have been copied is the essence of the copyright work.⁵⁴ It is the cumulative effect of the copied features that is

_important.⁵⁵

⁵⁰ _{Wham-O MFT Co v Lincoln Industries Ltd [1987] 1 NZLR 641 at 666.}

⁵¹ _{Nova Productions Ltd v Mazooma Games Ltd & Ors [2006] EWHC 24 at 123.}

⁵² _{Designers Guild Ltd v Russell Williams (Textiles) Ltd [2000] UKHL 58; [2001] FSR 113 at 2425.}

⁵³ _{University of Waikato v Benchmarking Services Ltd [2004] NZCA 90; (2004) 8 NZBLC 101,561 at [30] – [33].}

⁵⁴ _{Bleiman v News Media (Auckland) Ltd [1994] 2 NZLR 673 at 678.}

⁵⁵ Designers Guild Ltd v Russell Williams (Textiles) Ltd at 2423.

[175] The Court may need to consider the degree of originality (the skill and labour expended) in respect of those parts said to have been copied. If the level of originality is low, the skill and labour required to reproduce something similar is likely to be correspondingly low. This may assist to determine whether substantial reproduction has occurred.

Causal connection

[176] Normally proof of a causal connection is established by similarity combined with proof of access to the plaintiff’s products.⁵⁶ However, access to the works will not necessarily be determinative of a causal connection.⁵⁷

Ideas versus expression

[177] In considering whether FPF wrongly used Karum’s proprietary information, the distinction between ideas and the expression of ideas assumes importance. The basic principle is that copyright protects the expression of ideas but not the ideas themselves. The principle is expressed as follows in the Agreement on Trade- Related aspects of Intellectual Property Rights (TRIPS):⁵⁸

Copyright protection shall extend to expressions and not to ideas, procedures, methods of operation or mathematical concepts as such.⁵⁹

[178] In the context of computer programmes, the principle raises the question of whether the non-literal elements – the architecture, design, structure, logic and algorithms – can be protected or only the elements which express those ideas. The EU Software Directive⁶⁰ is clear on the issue. The recitals read in part:

(13) Whereas, for the avoidance of doubt, it has to be made clear that only the expression of a computer program is protected and that ideas and principles which underlie any element of a program, including those which underlie its interfaces, are not protected by copyright under this Directive.

⁵⁶ _{Wham-O MFT Co v Lincoln Industries Ltd at 668.}

⁵⁷ _{Designers Guild Ltd v Russell Williams (Textiles) Ltd at 2432.}

⁵⁸ _{To which New Zealand is a party.}

⁵⁹ _{Agreement on Trade-Related aspects of Intellectual Property Rights, art 9(2).}

⁶⁰ Directive 1991/250/EEC of 14 May 1991 on the legal protection of computer programs (“the

Software Directive”).

(14) Whereas, in accordance with this principle of copyright, to the extent that logic, algorithms and programming languages comprise ideas and principles those ideas and principles are not protected under this Directive.

(15) Whereas, in accordance with the legislation and jurisprudence of the Member States and the international copyright conventions, the expression of those ideas and principles is to be protected by copyright.

Article 1 reads in part:

Object of Protection

...

(2) Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive.

[179] In Nova Productions Ltd v Mazooma Games Ltd, Jacob LJ said of the recitals and directive:⁶¹

To my mind these provisions are abundantly clear. The well-known dichotomy between an idea and its individual expression is intended to apply and does to copyright in computer software. When I say “well-known” I mean not just known to copyright lawyers of one country but well-known all over the world. Recital 15 refers to the protection of the expression of ideas as being “in accordance with the legislation and jurisprudence of the Member States and the international copyright conventions” and is clearly a reference to this dichotomy. The TRIPS agreement of 1994 likewise recognises this dichotomy, see particularly Art, 9.2.”

[180] The non-literal aspects of a computer system such as programme structure or architecture and design features may be capable of protection.⁶² As Pumfrey J said in Navitaire Inc v Easyjet Airline Co Ltd,⁶³ approving Jacob J’s comments in IBCOS,⁶⁴ a sufficiently general idea can be taken without infringing copyright but the taking of a detailed “idea” may infringe.

[181] In Navitaire the defendant wanted a ticketless airline booking system such as

the plaintiff’s but because the plaintiff was not prepared to make the modifications

_{sought by the defendant, it decided to develop its own booking system. There is no}

⁶¹ _{At [31]}

⁶² IBCOS Computers Ltd & Anor v Barclays Merchantile Highland Finance Ltd & Ors [1994] FSR

_{275 [302]–[303]; Cantor Fitzgerald International v Tradition (UK) Ltd [2000] RPC 95 at 77.}

⁶³ _{Navitaire Inc v Easyjet Airline Co Ltd [2006] RPC 95.}

⁶⁴ IBCOS Computers Ltd & Anor v Barclays Merchantile Highland Finance Ltd & Ors at [124].

suggestion that the defendant had access to the plaintiff’s source code. The languages used, code and architecture were quite different. However, it resulted in a system nearly identical in function and appearance. It was a case of “non-textual copying” or “copying without access to the thing copied, directly or indirectly”.

[182] Pumfrey J warned against extending protection to the functional effects of a programme. He said:⁶⁵

Copyright protection for computer software is given, but I do not feel that the courts should be astute to extend that protection into a region where only the functional effects of a program are in issue. There is a respectable case for saying that copyright is not, in general, concerned with functional effects, and there is some advantage in a bright line rule protecting only the claimant’s embodiment of the function in software and not some superset of that software.

[183] Nova Productions Ltd v Mazooma Games Ltd is another case where it was not suggested that the defendants had access to or copied the source code itself. Rather, the defendant copied the outputs which appeared on the screen. Kitchin J held that the similarities comprised general ideas that had nothing to do with the skill or effort expended by the programmer so that taking the features did not amount to a

substantial part of the programme. He said:⁶⁶

They are cast at such a level of abstraction and are so general that I am quite unable to conclude that they amount to a substantial part of the computer program. They are ideas which have little to do with the skill and effort expended by the programmer and do not constitute the form of expression of the literary works relied upon.

Further, application of the principles explained by Pumfrey J in Navitaire leads to the same conclusion. Nothing has been taken in terms of program code or program architecture. Such similarities that exist in the outputs do not mean that there are any similarities in the software. Further, what has been taken is a combination of a limited number of generalised ideas which are reflected in the output of the program. They do not form a substantial part of the computer program itself. Consideration of Article 1(2) of the Software Directive confirms this position. Ideas and principles which underlie any element of a computer program are not protected by copyright under the Directive.

_{[184] In upholding the decision,}⁶⁷ _{the Court of Appeal said:}⁶⁸

⁶⁵ _{At [94].}

⁶⁶ _{At [247]–[248] and [253].}

⁶⁷ _{Nova Productions Ltd v Mazooma Games Ltd [2010] EWHC 1839.}

⁶⁸ At [51].

... A written work consisting of a specification of the functions of an intended computer programme will attract protection as a literary work. But the function themselves do not.

_And:⁶⁹

Pumfrey J was quite right to say that merely making a programme which will emulate another but which in no way involves copying the programme code or any of the programme’s graphics is legitimate.

[185] SAS Institute v The World Programming Ltd⁷⁰ is another case where the defendant sought to emulate much of the functionality of the plaintiff ’s system. There was no suggestion that the defendant ever had access to or copied SAS source code. It did study SAS technical manuals which described the operation and use of the various components. They only gave information about the external behaviour of the SAS system, not any internal behaviour nor details of the source code. Arnold J held that although WPS replicated a large part of the functionality of the SAS

components, it did not constitute an infringement of copyright.⁷¹ He said:⁷²

... I accept that copyright protection is not limited to the text of the source code of the program, but extends to protecting the design of the program, that is, what has been referred to in some cases as its “structure, sequence and organisation”. If there were any doubt about this, then the conferring of protection on “preparatory design material” [in recital [7] of the Software Directive] confirms it. But there is a distinction between protecting the design of the program and protecting its functionality. It is perfectly possible to create a computer program which replicates the functionality of an existing program, yet whose design is quite different.

In my judgment Pumfrey J was right to say that at [129] the key question is “the nature of the skill and labour”. If one takes the example of the tax calculation program postulated in The Modern Law of Copyright, the skill, judgement and labour that goes into understanding and elucidating the tax regulations is the wrong kind of skill, judgement and labour to be protected by copyright in the resulting computer program (including any preparatory design material). Copyright in the computer program (including any preparatory design material) protects the skill, judgement and labour in devising the form of expression of the program (including any preparatory design material), that is to say, its design and source code.

_And:⁷³

⁶⁹ _{At [52].}

⁷⁰ _{SAS Institute v The World Programming Ltd [2010] EWHC 1829.}

⁷¹ _{At [246] and [249].}

⁷² _{At [232]–[233].}

⁷³ At [207].

In my judgment counsel for WPL is correct: the distinction is one between different kinds of skill, judgement and labour. Skill, judgement and labour in devising ideas, procedures, methods of operation and mathematical concepts is not protected by the copyright in a literary work. What is protected by copyright in a literary work is the skill, judgement and labour in devising the form of expression of the literary work.

[186] Arnold J also held that the principle that copyright does not protect functionality is “not confined to that which it is strictly necessary to reproduce”⁷⁴. Accordingly, names of procedures and fixed text elements in the log files were not protected, as there was no evidence that significant skill, judgement or labour was expended in devising them.

Features of the CMS system

Source code and logic

[187] Before considering the specific infringements alleged by Karum, it will be helpful to recapitulate and expand on the earlier discussion of the elements of a computerised credit management system such as CMS and Lending.⁷⁵

[188] As was noted,⁷⁶ a computer program is a set of instructions to a computer. It is developed for the purpose of carrying out particular functions, hence the term functionality is used to describe what the program actually does. The first step to writing the program for a business is usually to identify business requirements: the outcomes sought. The next step is to plot the way in which those outcomes can be achieved: the functional specification for the program. The final step is to write the program itself.

[189] The program is written in a computer programming language: the source code. It will be automatically translated into binary machine code, known as object

_{code which the computer can directly read and execute.}

⁷⁴ _{At [249].}

⁷⁵ _{At [8]–[16].}

⁷⁶ At [10] above.

[190] As mentioned,⁷⁷ the CMS software was written in COBOL, a third generation programming language. FPF’s Lending software is written in Ingres, a fourth generation programming language. The two languages have entirely different syntax and construction. They cannot be used together.

[191] Even two pieces of source code written by different programmers to achieve the same functional specification may look quite different as a result of the individual programmer’s particular modes of expression, preferences towards a certain syntax and other idiosyncrasies. By the same token, if two separate pieces of source code written for the same purpose share a high degree of visual similarity, it may be inferred that one piece of code has been written by referencing the other.

[192] Karum’s case is not that the COBOL code of CMS has been translated or adapted into Ingres to achieve the same outcome. That would involve copying the literal elements of a computer language, notwithstanding the language differences. The allegation in this case is that FPF has copied non-literal elements of the CMS software, specifically the logic inherent in certain components of the software.

[193] In general terms, logic is the sequence of steps, structured in a logical order, that is required to perform a given task. A software system such as CMS comprises thousands of individual computer programs, each of which have a specific function to give effect to the operation of the system as a whole. The function is what the program does. The logic of each program is how the result is achieved – the specific steps, calculations and tasks undertaken and the order in which they are undertaken. The logic adopted to achieve a specific function is the result of the application of skill, labour and judgment on the part of the analysts and programmers who develop the program.

[194] The term “processing logic” was applied by witnesses and counsel to describe the logic defined in program specifications. Processing logic is conceptually distinct from the source code. The source code is the literal

_{programming language of the computer program, whereas processing logic describes}

⁷⁷ At [12] above.

the steps taken to achieve the intended outcome. However, as the source code implements those steps, it can be said to include the processing logic in that sense.

[195] Karum alleged that FPF replicated the processing logic – the particular paths or methods chosen by CMS software developers – in Lending. The processing logic is said to be what makes CMS software effective and unique and was copied by FPF in order to achieve the same user experience and level of service to RFS users and the FTC business.

Product data

[196] Two distinct types of data involved in data processing for credit systems were identified in evidence. The first is customer data, which is the raw data collected from or about the customer by the business in the course of dealings. It includes personal information such as a customer’s date of birth and address and individual transactions entered into such as purchases and payments.

[197] More controversially, the payments systems technology expert, Mr Kenneth Maliga, who gave evidence for Karum, identified a second data category which he called “product data”. He defined this as the data that a credit management system will use for internal system logic and navigation control, typically in the form of codes, flags and indicators. They are used to steer and control the internal software navigation logic of a system. The value of the data contained by the codes, flags or indicators determines which logic is activated. Product data provide a shortcut which avoids the duplication of the steps required to make a particular calculation. Mr Miliga said product data values are basically signals of condition. Each value within a code represents a different condition. In the case of a flag or indicator, the condition is either “yes” or “no”, whereas a code that has many values will signal multiple conditions and therefore multiple paths of navigation. These are known as multiple use codes in which a single code has varying code values.

[198] Karum claims that product data (as well as processing logic) were appropriated by FPF for the purpose of its Lending platform, particularly in its payment calendar, delinquency calendar, special codes and intercept codes. FPF

acknowledges that there may be processing conventions adopted for programming convenience internal to the software which may be protected if there is sufficient skill and judgment or confidentiality underpinning the particular convention. However, FPF says that once the conventions are used for the purpose of conveying information external to the system, i.e. to users, justification for describing them as product data is lost. FPF says all of Karum’s claimed examples of appropriation of product data were used externally to communicate information to business users and accordingly do not attract protection.

Business rules or policies

[199] As earlier noted,⁷⁸ business rules (or business policies) are the business- specific policies and procedures established to run, maintain and improve the performance of the business utilising the credit management software. Business rules are established independently of the credit management software which will be configured to implement them where necessary.

[200] Karum says, however, that when a business rule has been incorporated into the processing logic of the software programme (as it says it was in the case of CMS), FPF is not entitled to utilise the processing logic. Karum makes no claim to the business rules properly established by RFS or FPF but says that where the CMS software has incorporated “pre-programmed” business policies, FPF is not entitled to utilise the logic.

Specific infringements

Payment calendar and delinquency calendar

[201] The payment calendar and delinquency calendar, while separate sub-systems of the CMS credit management system, can conveniently be considered together.

_{They were developed in tandem for incorporation into Lending.}

⁷⁸ At [16] above.

[202] The payment calendar in the CMS system records the payment history of an individual customer. It tracks a customer’s payment history for the preceding 24 months by reference to the proportion of a scheduled payment actually made by the customer. Payment classifications include full payment of the amount due, partial (more than half but not all of what was due), less than half of the scheduled payment and no payment at all. These payment conditions are calculated by the CMS software from the raw customer data in the database and by the application of the applicable product data tag to which each payment is coded. The codes are a letter – “O” for no payment, “L” for a payment of less than half, “P” for a payment of more than half and “F” for the full scheduled payment. By this means the payment history of a customer can be shown over a 24-month period. Business users apply the codes to interpret what is displayed on a screen.

[203] The contractual delinquency calendar also analyses a customer’s payment history for the preceding 24 months. It does so by analysing payments by reference to arrears. A numerical code is assigned to each month according to the length of time the payment is overdue. A payment which is up to 30 days past due (i.e. one payment has been missed) is assigned the code “1”, a payment overdue between 31 and 60 days is “2” and so on. There are also codes which indicate other information about the status of the account such as a credit balance or the existence of a dispute. As with the payment calendar, a business user familiar with the code can tell at a glance the payment record of a customer and status of the account over the preceding

24 months.

[204] Karum claims that FPF has infringed its copyright (and/or misused its confidential information) in relation to the payment calendar and contractual delinquency calendar by copying the CMS code values, the method of determining when a particular code will be applied and the sequence in which values are created.

[205] FPF incorporated a payment calendar and a contractual delinquency calendar into its Lending system using codes that were (in the case of the payment calendar) identical and (in the case of the delinquency calendar) very similar to CMS codes. The adoption of CMS codes in the two calendars was a necessary consequence of the decision to accede to the wishes of RFS users to use existing contract performance

indicators⁷⁹ in the integrated system. This was in accordance with the principle adopted for the purpose of Project Orpheus that the same credit criteria, business rules and policies needed to apply to the RFS portfolio after the conversion as applied before the conversion.

[206] Mr Philip McDiarmid, a business analyst contracted to FPF from December

2003, was tasked by Paul McCarthy, the Team Leader, to undertake five streams of work in February 2005, including the performance indicators project of which the development of the payment and delinquency calendars (and credit rating fields) were a part.⁸⁰ Mr McDiarmid explained that the migration of the payment and delinquency calendars and credit rating fields required an investigation of the business rules of RFS. The objective was to ensure that the same business rules applied following integration. Among the documents he examined was a summary of how contractual delinquency, payment summary, credit rating and credit limits were determined in RFS. On the basis of his enquiries, he prepared and, on 3

October 2005, circulated a first draft of a Business Requirements Definition (BRD) report. It was headed “Integration Project: Establishment of RFS Contract Performance Measures in the Lending System”. The document concluded with a series of questions including the following:

1 What aspects of this, if any, could be regarded as CMS IP? For example the CD Cal and Payment Cal, and the deriving of credit ratings and limits from these” Sheila advises these measure preceded CMS, and so are not IP.

3 Business rules for calculating CD Cal – will need code inspection to determine.

4 There are two delinquency calendar fields referred to during credit limit calculation, i.e. CD Cal i.e. and Memo CD Cal. Will need code inspection to determine if both are needed, and why.

What aspects of this, if any, could be regarded as CMS IP? For example, the CD Cal and Payment Cal and the deriving of credit ratings and limits from these? Sheila advises these measures preceded CMS, and so are not IP.

[207] Mr McDiarmid said he posed the first question because he and others involved in the integration programme had been advised during 2005 that concerns

⁷⁹ _{As they, together with a credit rating history, are called.}

80. Another stream for which he was responsible was automated credit assessment which required scoring originating credit applications in an equivalent manner to the existing RFS process.

had been raised by Karum in respect to intellectual property in the FTC-CMS software. They were told to ensure that in the course of the integration process there was to be no involvement with the system itself, that is, he said, “with the computer codes”. Mr McDiarmid confirmed, as the draft report records, that he was told by Mrs Mason that the performance measures in question were in use at RFS before the FTC-CMS software came into operation. With this reassurance, he continued to ascertain the rules behind the performance measures. He also saw Mrs Mason’s response as consistent with a distinction which could fairly be made between the business logic and rules relating to credit risk and the actual software implementing it.

[208] Mr McDiarmid said he recalled being told by Ms Horvat that there were some tolerances in play in the delinquency calendar that needed to be factored in. Tolerance values determine how a customer’s arrears should be aged. For example, a customer with a high rating may not be classified as being more than one month overdue if their arrears are less than $9 (being the tolerance amount). Mr McDiarmid searched for documentation setting out RFS rules on tolerances. He was unsuccessful. Nor could he find anyone who knew the RFS tolerances from memory. This led Mr McDiarmid to comment in his report that “actual values [of tolerances] to be determined from CMS code”. The further questions (3 and 4) asked in the BRD report arose because of a lack of documentation in other areas of the business logic behind RFS credit policy.

[209] Mrs Mason said in evidence that when she saw that Mr McDiarmid had asked for information to be obtained by code inspection “my heart dropped”. She said that ethically she would not allow inspection. Mr McDiarmid said, however, that he was not suggesting by the questions that he would check the code himself, rather, that he would ask an RFS IT team member to ascertain the business rules and values from the code.

[210] While the BRD report was being finalised, Mr McDiarmid wrote a functional specification. It contained all the information required by the programmer who was to write the source code for Lending. It set out, for example, the values and meanings for the payment calendar and delinquency calendar. There is no reference

to CMS source code. However, it may be inferred that, to the extent that values and business rules could not be ascertained from documents, they were derived from CMS source code, albeit by RFS personnel entitled to access the code.

[211] Mr Malcolm Jenkins, the manager of FPF’s Information Service department, confirmed that because the business requirement was to retain the RFS business rules, FPF had to understand and document what those rules were. He said that instances where the FTC/CMS codes appears to have been referred to were for the purpose of identifying a particular value, such as a tolerance, which none of the business users could recall. He said that is because the tolerances will have been determined by the business earlier and then embedded in the software programme. He went on to say, however, that he was advised, particularly by Mrs Mason, that the payment calendar, contractual delinquency calendar and credit rating used business rules of RFS of longstanding pedigree that in fact predated CMS. Accordingly, no CMS intellectual property was in issue. He said that, in any event, RFS business logic was implemented in Lending by developers working under his supervision without access to FTC-CMS codes.

[212] Mr Jenkins acknowledged that on conversion to Lending, the payment calendar became available for use by screen users just as it had been available to RFS staff previously. However, he saw it as simply customer data in a summarised form.

[213] It is clear then that the payment calendar and delinquency calendar used in Lending were based on functional specifications which incorporated the code values and meanings used in the CMS system. In some instances data was obtained by access to the CMS source code.

[214] Karum’s case is that the adoption by Lending of the calendars and the codes and meanings attributable to them involved the appropriation of the product data and processing logic of the CMS system. It is accepted that there was no property in the code values taken isolation. The claim is as to the use and application of the underlying logic of the systems as integrated units.

Payment calendar

[215] The payment calendar, as a mechanism for analysing and displaying customer data in a way that is useful and readily intelligible to a user familiar with the code, is a common feature of credit management systems. The way in which payments are analysed is also commonplace. The definitions or meanings ascribed to the codes were said by Mr Steven Zeringue, an American retail payments expert called by FPF, to represent all possible logical outcomes of whether or not a satisfactory payment had been made. There could be no objection to FPF replicating the functionality in Lending, provided that in order to do so, FPF did not copy CMS logic.

[216] There is no reason why the code values themselves could not be adopted by FPF. Their selection does not require the exercise of any particular skill and judgment. They (and what they stood for) were not confidential. They were well known to FTC business users. They were also used by RFS for its credit authorisation rules that were written by RFS into CMS in 2001. It was accepted that there could be no objection to that system being replicated in Lending.

[217] There remains only the concern that FPF used the processing logic of CMS in Lending. Yet the logic of the two systems is quite different. Mr Michael Harvey, a computer software consultant called by FPF, explained that in CMS the payment calendar values are stored in the database as numbers and then converted to the relevant code for display to the user. The 24-month calendar is stored in the database as a single string of 24 characters. In contrast, in Lending the payment calendar values are stored in exactly the form presented. The payment code is stored in individual rows of data which are then collated together to represent the 24-month calendar. Lending does not retain a calendar as such. It is generated “on the fly” only when needed for display or reporting. Mr Harvey said this indicated to him that the Lending database design and programme development was derived from the Functional Specifications without reference to the CMS source code.

[218] What FPF sought to do (and did) is to replicate the functionality of the payment calendar in the CMS system. As earlier observed, this was a necessary consequence of the decision to retain CMS business rules following integration. FPF

was entitled to do this, provided that in order to do so it did not take that which was the product of the skill, judgment and labour of those who wrote the CMS programme.

[219] In my view, FPF did not cross that line. The programmes have similarities in outputs and in the commonplace features of the system. But the processing logic of the software is totally dissimilar. I am satisfied that FPF achieved the requisite functionality by the application of the skill, judgment and labour of its own programmers.

[220] Business developers should not have sought access to the CMS source code but they did so solely for the purpose of ascertaining the relevant business rules of RFS. This did not involve copying or other wrongful use of CMS intellectual property. There was unauthorised use of confidential information but no detriment to Karum.

Delinquency calendar

[221] A delinquency calendar is another elementary component of any credit management system. The use of contractual aging – comparing what has been paid with what ought to have been paid – is the invariable basis for such a system. The use of numbers to represent the time a debt has been outstanding – 30 days (1), 60 days (2) and 90 days (3) – is also an industry standard. The system used by F Credit before CMS was adopted had these basic features.

[222] The code values and meanings used in the CMS delinquency calendar were largely incorporated into Lending. They comprised the numbers 1 – 8 to represent periods of up to 240 days overdue, 9 for “written off”, a dash and an asterisk for “no activity” and “current”, and letters as follows to indicate particular outcomes:

C credit balance

R reactivate

W write off small balance

[223] Some of these, including code numbers 1 – 3 for 30, 60 and 90 days overdue and provision for write offs and credit balances, existed in F Credit and were mapped into CMS. Some of the code values, such as C, R and W, are, as FPF submitted, more intuitive than the result of skill and judgment. However, it is not on the individual codes that Karum relies. Rather, it is on the code values and meanings, taken as a whole, which are said to be a significant part of the works in issue.

[224] Although the delinquency calendar is more complex and its values and meanings less obvious than the payment calendar, I do not think it warrants any difference in approach. I consider FPF was entitled to replicate its functionality provided it did not copy the CMS software in order to do so. There was no particular skill and judgment involved in the identification of the codes used. For the most part, they were in common use, some had their equivalents in F Credit and, of course, they were known to business users. There was nothing secret about them.

[225] If there has been a breach of confidence or infringement of copyright, it is in the use of CMS processing logic or source code. I am satisfied that isolated instances of access to CMS source code were for the purpose of and restricted to ascertaining or clarifying RFS business rules. There is no evidence that CMS source code was copied in Lending. Mr Harvey identified material differences between the logic used in the two programmes. It is consistent with the view I have reached, based on my assessment of FPF witnesses, that the Lending programme was developed from the Functional Specifications and not from copying the logic of the CMS system.

Aged debt

[226] Karum argues, as a separate though related issue, that Lending copied the CMS software by which “aging buckets” were used to determine the values in the CMS delinquency calendar. Unlike payment and delinquency calendars, the aging buckets and logic driving their operation are not visible to a user. Karum says that the reports generated by FPF in the course of Operation Orpheus show that FPF accessed the CMS source code and replicated the aged debt logic in Lending.

[227] However, I accept the evidence of Mr Jenkins who explained that, for the purpose of managing Q card arrears, FPF had earlier (in 2004) developed an aged debt bucket system. He said that in order to achieve aged debt functionality for the RFS Farmers Card contracts, the code was written by an FPF developer employing the basic logic of the earlier development. His evidence was not challenged in cross- examination. Mr Harvey confirmed that the methods by which the CMS and Lending programmes perform their function are materially different.

Special codes

[228] Special codes are used in the CMS system to identify certain conditions associated with a customer or the customer’s account. The use of codes (sometimes referred to as flags or values) is commonplace in credit management systems, as has already been shown. The function of a special code typically is to indicate an action or inaction that represents “special handling” or special circumstances requiring a deviation or exception from the norm. Often the code will have what was described as “downstream consequences” within the system. So, for example, an account which has been identified as forged (and has the special code O2), has its statements suppressed and is not targeted for receipt of promotional materials. The code will be entered manually by a user. The consequences will follow by virtue of the way the software is written. The source code is written so as to achieve those outcomes.

[229] Prior to the conversion from F Credit to CMS, RFS had made extensive use of special codes (known as restrictive codes in F Credit). Some of them did not exist in Base CMS which came with 37 special codes, though some were inapplicable to New Zealand conditions. As part of the conversion project, FTC specified the special codes it required in the new system. The values and behaviours associated with the special codes introduced from FTC were written by RFS in the conversion process to meet RFS business requirements.

[230] As part of Project Orpheus, FPF undertook a comprehensive review of all CMS special codes. It was not confined to those in use at RFS. It covered every special code existing in the CMS software, whether obsolete or not, and the behaviours associated with each.

[231] Some of the CMS special codes had existing equivalents in Lending. Karum says there were an additional 18 codes resident in the CMS software which, together with their associated logic, were directly migrated into Lending, 15 under what was described as “the guise” of “override codes”, the remaining three as other data elements. Karum says that of the 18 special codes, at least eight can be traced back to Base CMS.

[232] It is not in dispute that the additional special codes introduced into Lending have replicated the functionality that existed in CMS. They remain in use. Some have also been applied to Q card accounts.

[233] Nine of the 18 special codes migrated to Lending originated from F Credit. They had no equivalent in Base CMS. They were written by RFS to meet RFS business requirements. Karum submits that the prior use of these codes by FTC is of no relevance, as upon conversion to CMS the logic and behaviours associated with them were incorporated into the CMS system. Karum says that the conditions attached to each code, whether derived from FTC or not, comprise processing logic programmed into the CMS source code which FPF has no right to; it was entitled only to the underlying customer data.

[234] For reasons already discussed in relation to the payment and delinquency calendars, FPF was plainly entitled to ascertain the business rules of RFS which lay behind the use of the special codes and to give effect to them in Lending. The special codes in CMS were activated or introduced to give effect to those rules. CMS could claim neither confidentiality nor the exercise of skill and judgment in relation to either the code values or their attributes.

[235] The issue reduces, as Mr Galbraith submitted, to one of process. At heart Karum’s complaint is as to the means by which the special codes (or the business practices that underlay them) were implemented in Lending specifically, Karum says, by wrongfully accessing CMS’s intellectual property. As Mr Johnson said when asked about the migration of the account of a deceased customer:

Well, once again I would say the right way to do this would be by reference to the business requirements, not by inspecting the software.

[236] There is, however, no evidence that FPF personnel did “inspect the software” for the purpose of building the RFS special codes into Lending. I am satisfied that FPF acquired the information it needed (as it did in most other areas) by questioning business users and accessing documents which recorded the conditions or attributes of the codes, including the so-called data dictionary compiled by Karen Mitikulena, a programmer with RFS. None of the information was acquired by accessing CMS source codes.

[237] The way in which FPF approached this aspect of the conversion was in line with what Mr Zeringue referred to as “customary industry best practises” in the USA. It is necessary, he said, to create a “master file” of all information required to ensure that the account can be treated the same way the day before migration as the day after. He said that without the conditions or behaviours or (as he termed them) algorithms associated with a code, nothing can be done: “If you’re going to hand me a value, I need to know what to do with it.”

[238] The way in which FPF implemented the special codes in Lending once again provides confirmation that there had been no improper access to or appropriation of CMS source code. In this case, the code values themselves were changed and the description of some was amended. More significantly, Mr Harvey said the ways in which CMS and Lending stored special code information were “quite different” and inconsistent with the processing logic and/or source code of CMS having been copied.

Statements and intercept codes

[239] The CMS system provides for the production of statements for printing and despatch to customers. The system incorporates what are called intercept codes to suppress or divert statements of customers’ accounts in particular categories. For example, if a customer is bankrupt or in default and debt recovery has been pursued, the account will be coded in such a way that a statement will not be produced or sent. Karum says that FPF incorporated the logic and functionality of the CMS software by incorporating intercept code values and using CMS processes for the production of statements and otherwise.

[240] Prior to CMS, RFS used the equivalent of interception codes in F Credit. In that system they were known as “streaming codes”. They were converted to CMS intercept codes when CMS was installed.

[241] Both prior to CMS and subsequently RFS used a third party, Datamail, to print and despatch statements. This required an interface file which incorporated the streaming/intercept codes. Datamail software could interpret the codes and statements in the categories identified.

[242] It is not clear who was responsible for the development of the interface file used post-CMS. Mrs Mason said it was created by FTC’s IT team. Karum asserts it was based on CMS software. That was doubted by Mr Harvey who said the relevant CMS programme was formatted for printing by a Xerox printer and, unless changed subsequently, could not have been used as an interface file.

[243] What is not in dispute is that FPF replicated the existing RFS interface file layout in Lending for the production by Datamail of Farmers statements. FPF had an existing interface file to enable Datamail to produce statements for its Q card. However, it was decided to retain the existing RFS interface because of the development cost that Datamail would have had to incur if there were a switch to the Q card format. Mr Jenkins said there was also a timing issue as it would have taken Datamail a month to produce an interface file.

[244] Karum says that FPF infringed its copyright and breached confidentiality in the use of five intercept codes as well as by replicating the CMS interface file layout. The intercept codes and the values (the numbers) ascribed to them are:

54 Permanent hold

18 Bankrupt

12 Repossession

02 Fraud/Forge

98 Regular mail

[245] Code 98 depended on American address codes and Imperial measurements that could not be applied in New Zealand. It was used in Lending to denote the default position, print and post. All of the remaining codes existed in F Credit, albeit using different values.

[246] It cannot be said that the code values themselves are entitled to protection. They are arbitrary, do not require the exercise of skill and judgment and, in any event, are not confidential. They have been shared with Datamail since the inception of CMS. Similarly, the descriptions are the same as used in F Credit and are without novelty or inventiveness.

[247] As earlier discussed, it has not been shown that the interface file format was created by or based on CMS. Regardless, as Mr Galbraith pointed out, the interface file lacks the element of confidentiality, given its function as an agreed protocol with a third party. Moreover, the intercept code operates to suppress the printing of statements by virtue of the Datamail software which recognises the intercept code. As Mr Jenkins explained, this is a behaviour that happens at the Datamail end not in Lending.

Reporting

[248] Reporting is a standard feature of all credit management systems. It is used for many purposes, including monitoring performance, measuring productivity and highlighting accounts or transactions that may require review or action.

[249] The CMS software had the capacity to generate a large range of reports; Base CMS came with 250 reports. Karum claims that FPF incorporated into Lending the logic and functionality of CMS software to enhance its reporting capability in a number of areas.

[250] Prior to the introduction of CMS, F Credit produced 192 standard reports. By the time FPF acquired RFS, the number had grown to over 470. These were identified in the course of a gap analysis undertaken as part of Project Orpheus to determine the gap between the business reporting needs of the integrated operation

and the functionality existing in Lending. Such an analysis was described by Mr Michael Laing, a consultant in credit cards and systems, called by FPF as “standard” and agreed to be unobjectionable by Karum witnesses.

[251] FPF decided to meet the reporting requirements of the integrated business either through existing Lending reports or through its data warehouse (DSS). This is a computer-based third party licensed information system that allows non- programmers to access and analyse data and construct their own reports. It was not suggested that there was anything improper about FPF achieving reporting functionality by this means.

[252] As it turned out, two further reports were built in Lending, both fraud reports. There is no evidence that CMS knowhow was used for this purpose.

[253] I can see nothing in the process undertaken by FPF to achieve reporting functionality that breached confidentiality. As Karum witnesses accepted, FPF had every right to ascertain what reports were being generated in RFS and to decide whether they wished to obtain the same information. And there could be no objection to the means FPF adopted to meet such of those reporting requirements as were not available in Lending.

Statement history and unbilled transaction displays

[254] Karum says that FPF used CMS logic and functionality in developing subsystems for Lending for an account statement history screen (which enables a user to see a customer statement history) and one for showing unbilled transactions. Mr Hart said it is clear that CMS IP formed the foundation for these subsystems.

[255] The programmes were among those written by Ms Horvat in 2004 at the request of Mr Jenkins. I found Ms Horvat an honest and careful witness. I have no hesitation in accepting her evidence that in writing the programs she did not refer to or rely on CMS source code or her knowledge of the CMS system.

[256] Ms Horvat wrote the statement history program based on a functional specification written by a business analyst. There is nothing to indicate that the functional specification drew on the CMS system. It is clear, moreover, that such systems are commonplace. Mr Maliga, the payments systems technology consultant called by Karum, described a statement history and unbilled display screen as standard functionality in credit management systems. Similarities of the kind referred to by Karum witnesses are to be expected given that the information displayed will be very similar.

[257] Mr Harvey’s evidence is consistent with the Lending system being developed independently. He said the layout and methods of displaying the data are different and there is nothing to indicate that the Lending programmes were copied from CMS documentation or source code. Rather, he said, the existing Lending programmes had been modified to the requirements in the functional descriptions and in a manner consistent with already existing standards.

Agency

[258] FTC used external agencies to undertake recovery of debts written off after internal recovery action had failed. Their use predated the introduction of CMS. There was “basic agency functionality” in F Credit which was incorporated in the CMS platform (at a cost of $240,000 to RFS). The system did not include an interface with external agencies which was paper-based.

[259] In 1999, as part of a broader review of collections, a project was initiated to develop an electronic interface with external agencies. It was implemented by developing a separate module of code which was then interfaced with the CMS software.

[260] As part of Project Orpheus the Agency subsystem was rebuilt in Lending. While acknowledging that it had no rights in relation to the Agency subsystem itself, Karum claims that in incorporating it into Lending, FPF used Karum’s intellectual property.

[261] The basis of Karum’s claim, as articulated in closing submissions, is the use in the Agency subsystem of CMS software’s database schema. These house the customer data (for instance, names and addresses) that are required for transmission to the agency. Karum does not take issue with FPF taking the customer data but with the taking of those aspects of the CMS software’s database schema, which house the customer data, for inclusion in Lending.

[262] Ultimately, Karum’s case is that because the Agency subsystem developed by RFT depended for its efficacy on data stored on the CMS database, its application in Lending necessarily involved the use of CMS intellectual property, viz the database schema.

[263] I am unable to accept the argument, put this way or in the various ways articulated by Mr Williams and Mr Hart in their evidence. The Agency subsystem, while dependent on data from the CMS database while operated by RFS, lost any such link when rewritten for use in Lending. It functions independently of CMS database schema. It draws only on data held in the Lending database. It does not incorporate or rely on any CMS intellectual property.

Conclusion

[264] Hindsight suggests that from the time Karum discovered that FPF had unwittingly had unauthorised use of and access to the CMS system, this litigation was inevitable. Mr Johnson seems to have held firm to the view he formed at an early stage that FPF would exploit its opportunity to access the CMS software for its own ends. Karum maintained that stance notwithstanding what I consider to have been the commercially ethical and constructive approach FPF took to negotiating a new licence.

[265] Contrary to the suspicions harboured by Karum, FPF was never motivated to appropriate CMS secrets. It was quite capable of designing and writing credit management programmes no less complex and sophisticated than the CMS system. It had little to learn from the CMS system other than an understanding of the functionality that had to be replicated in Lending in order to achieve a seamless

migration of RFS customer accounts onto the Lending platform. That functionality was a product of the business rules of FTC/RFS. There was nothing secret or confidential about it.

[266] FPF took all reasonable steps to accommodate Karum and to comply with its contractual and broader legal obligations. Staff who worked on the business integration project were well aware of what they could and could not do. For the most part, there was compliance. Having regard to the scale, duration and complexity of the project, transgressions were relatively few. None involved a deliberate attempt to appropriate protected information. None resulted in detriment to Karum.

[267] Inspection of the Lending system persuaded Karum to the view that in key areas FPF had incorporated the logic of the CMS software. That view rested on a fallacy that pervaded Karum’s case: that, to the extent that the business rules of FTC/RFS were reflected in or embedded in the logic of the CMS software, they could not be replicated in Lending. That is not what the law of copyright or the obligation of confidence require. FPF could not copy the source code or the logic of the CMS programme. But it was fully entitled to develop a programme which emulated the CMS programme in order to give effect to RFS business rules. In my view, ultimately, that is all it can be said to have done.

Result

[268] The plaintiff is entitled to judgment on the counterclaim and to costs. If the parties are unable to agree on costs, I will receive memoranda. In view of the likely complexity of any application for costs, I will not make timetable orders at this stage. If required, the parties may seek further directions by the filing of memoranda.