CA, Inc. v ISI Pty Limited

Case [2012] FCA 35

FEDERAL COURT OF AUSTRALIA

CA, Inc. v ISI Pty Limited [2012] FCA 35

Citation: CA, Inc. v ISI Pty Limited [2012] FCA 35
Parties: CA, INC. and CA (PACIFIC) PTY LIMITED
ACN 001 146 345 v ISI PTY LIMITED
ACN 003 152 225
File number: NSD 242 of 2010
Judge: BENNETT J
Date of judgment: 3 February 2012
Catchwords:

COPYRIGHT – subsistence – whether applicants’ database management system identified with sufficient precision to be classified as a “computer program” and/or a “literary work” under the Copyright Act 1968 (Cth) – applicants’ database management system product contains macros – whether applicants’ macros are a “computer program” and/or a “literary work” under the Copyright Act

COPYRIGHT – infringement – respondent develops product to enable users of applicants’ database management system to convert to another database management system – respondent’s product includes macros to replace applicants’ macros – whether respondent’s macros reproduce substantial part of applicants’ database management system – whether respondent’s macros reproduce substantial part of applicants’ macros – relevance of functionality

COPYRIGHT – defences – whether defence in s 47D(1) of the Copyright Act available to respondent – whether respondent acting “on behalf of” applicants’ licensees for purposes of s 47D(1)

CONFIDENTIAL INFORMATION – respondent develops product to enable users of applicants’ database management system to convert to another database management system – applicants allege respondent’s product developed using applicants’ confidential information – whether allegedly confidential information identified with sufficient specificity

CONFIDENTIAL INFORMATION – whether information has quality of confidence – whether certain alleged disclosures of information destroy quality of confidence

CONFIDENTIAL INFORMATION – respondent develops product while working as independent contractor at premises of licensees of applicants’ database management system – whether applicants’ information imparted to respondent in circumstances importing duty of confidence – whether respondent bound by equitable obligation of confidence

CONFIDENTIAL INFORMATION – whether unauthorised use of allegedly confidential information

EQUITY – laches – alleged delay by applicants in commencing proceedings – whether inequitable for applicants to gain relief for breach of confidential information

TRADE PRACTICES – whether alleged representations contravene ss 52 and 53 of Trade Practices Act 1974 (Cth)

Words & phrases: “computer program”, “on behalf of”
Legislation: Copyright Act 1968 (Cth) ss 9(3), 10(1), 13(2), 31(1)(a)(i), 32(2)(d), 32(4), 36(1), 47B(3), 47D(1), 47H, 134(1) and 184
Copyright Amendment Act 1984 (Cth)
Copyright Amendment (Computer Programs) Act1999 (Cth)
Copyright Amendment (Digital Agenda) Act 2000 (Cth)
Copyright (International Protection) Regulations1969 (Cth) reg 4
Trade Practices Act 1974 (Cth) ss 52 and 53
Cases cited: Ansell Rubber Co Pty v Allied Rubber Industries Pty Ltd [1967] VR 37 cited
Australian Medic-Care Co Ltd v Hamilton Pharmaceutical Pty Ltd (2009) 261 ALR 501 applied
CA Inc v Independent Systems Integrators Pty Ltd (No 2) [2009] FCA 900 applied
Campomar Sociedad, Limitada v Nike International Ltd (2000) 202 CLR 45 cited
Coco v AN Clark (Engineers) Ltd (1968) 1A IPR 587 cited
Computer Edge Pty Ltd v Apple Computer Inc (1986) 161 CLR 171 cited
Commonwealth v John…

Continue reading CA, Inc. v ISI Pty Limited

Sign in free to access the full text

Details
AGLC
CA, Inc. v ISI Pty Limited [2012] FCA 35
Case
[2012] FCA 35
Decision Date

CaseChat Overview and Summary

CA, Inc. (CA) brought an action against ISI Pty Limited (ISI), alleging copyright infringement, breach of confidence, and contravention of the Trade Practices Act 1974 (Cth). CA claimed that ISI used its confidential information and copyright-protected works in developing a product that enabled users of CA’s database management system to convert to another database management system. ISI denied these allegations and counterclaimed for relief under the Copyright Act 1968 (Cth). The court was required to determine whether CA's database management system and its macros were protected under the Copyright Act as a computer program or literary work, whether ISI's product infringed on CA's copyright, and whether ISI had breached any confidentiality obligations or engaged in misleading conduct. The court also needed to assess whether ISI's actions qualified for any statutory defences under the Copyright Act.

The court found that CA's database management system was identifiable with sufficient precision to be classified as a computer program under the Copyright Act, but the macros were not sufficiently original to be considered literary works. The court held that ISI's product did not reproduce a substantial part of CA's database management system or its macros, thus no copyright infringement occurred. Regarding the breach of confidence, the court concluded that ISI had not used any of CA's confidential information in developing its product. The court further found that ISI's conduct did not contravene any provisions of the Trade Practices Act, and that the defence in s 47D(1) of the Copyright Act was not available to ISI. The court rejected CA's claim of laches and found no evidence of misleading conduct by ISI.

The court ordered that the reasons for judgment remain confidential to the parties' legal advisers until further order, and directed the parties to consult on any confidential matters and to attempt to agree on proposed orders. If agreement could not be reached, the parties were to submit their proposed orders by a specified date. The matter was then stood over to a later date for further proceedings.

Orders

Orders of the court

1. These reasons be kept confidential to the legal advisers for the parties until further order.

2. Counsel consult as to any matters within these reasons for which confidentiality is asserted, and to notify my Associate of any proposed redactions on or before 5 March 2012.

3. The parties attempt to agree on proposed orders to give effect to these reasons and to submit such proposed orders on or before 5 March 2012. Failing agreement, each party is to submit proposed orders on or before 5 March 2012.

4. The matter be stood over to 9:30 a.m. on 9 March 2012.

Note: Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011

Background

Background to the litigation

Generally, I do not accept Mr Richards’ evidence unless it relates to matters not in issue or is supported by other evidence in the proceedings.FURTHER BACKGROUNDFunctioning of DatacomURTs Mr Lynn explains that every application program written by a licensee of Datacom for use in batch needs to have attached to it a special attaching program called a “User Requirement Table” (URT). A URT is a small piece of information that contains information about a Datacom database. The URT is used by a user’s application program when that application program accesses or changes information that the user has stored in a Datacom database. The name ‘URT’ is, as Mr Melito put it, ‘just the name CA gave to such an object module generated using particular macros’. The choice to use a URT was a design decision by the Datacom development group to enable user application programs to access Datacom databases. URTs provide the communication link or key that “opens the door” into the database region (often referred to as the “Multi User Facility” or MUF). According to Mr Lynn, the purposes of the URT are:·to “enter” Datacom at the correct point – referred to as an “entry point”;·to identify the correct Datacom resources required to operate the Datacom licensee’s application program and how the Datacom licensee’s application program will use them; and·to identify the data tables that will be required by the Datacom licensee’s application program. Some applications and data tables may share a URT while other applications and data tables use different URTs. There are two aspects to a URT:1.It may contain a piece of DBNTRY “stub code” (DBNTRY stub); and2.It may have information about a Datacom database and the data tables stored therein. The URT may or may not contain an executable program. If the URT contains a DBNTRY stub then, and only then, is it an executable program. DBNTRY stands for “database entry”. DBNTRY is not a common term but is unique to Datacom. When a Datacom licensee writes an application program, at the point that the user needs to use data from a Datacom data table, the programmer must “call” Datacom, by using the words “CALL DBNTRY”. In batch, the URT, which is included in the application program, resolves this call; in CICS, a module included with the CICS program resolves the call. In each case the call takes the licensee’s application program to the right place to carry on setting up the online processing required by the application program. The application program only calls DBNTRY and is unaware of the difference in the way in which the request is processed and the result returned. In batch, the URT manages the process of preparing and transporting the request to the database and handling the response that is returned to the application program. The DBNTRY code in the URT locates and starts the Datacom database interface program (DBINFPR) which is stored in the mainframe computer’s memory. DBINFPR creates and manages the connection to the database. DBINFPR is not documented in the Datacom documentation provided to licensees because, according to Mr Turgeon, they do not need it.

Evidence

Evidence Before The Court

ISI submits that CA’s conduct, in particular, its ‘deliberate delay… in bringing or even threatening proceedings’, has made it inequitable for CA to obtain the relief it seeks. CA disputes this.Evidence Mr Shuma gives evidence about his past knowledge of ISI, 2BDB2 and CA’s decision to commence legal proceedings. The parties have both proceeded on the basis that Mr Shuma’s knowledge and belief was the relevant knowledge and belief of CA. Mr Shuma says that he first heard about 2BDB2 in or around October 2001. He agrees that he first became aware of it prior to an email of 19 October 2001 sent by Dale Russell and copied to him. It was noted in that email that 2BDB2 ‘apparently let’s [sic] clients convert from VSAM programs using CA-Datacom/VSAM Transparency to VSAM programs using their transparency to DB2’ and that Datacom and DB2 could coexist during the conversion. Mr Russell’s email attached a PowerPoint presentation (the Presentation). Mr Shuma agrees that, in the Presentation, the claim was made that 2BDB2 was able to convert Datacom application programs to DB2. Mr Shuma agrees that 2BDB2 was, to his knowledge in about 2001, the first product that emerged which might have the capability of doing so. He agrees that the contents of Mr Russell’s email were a matter of interest to him and says that he assumes that he viewed the Presentation at the time. He says that, if 2BDB2 was able to do what ISI claimed and if the statements made in the Presentation were true, this would have been of significant concern to CA. However, he says that he ‘felt the Presentation was confused’ and that he ‘did not believe the statements that were made.’ He points to the references to VSAM in the Presentation, which, he says, detract from the suggestion that 2BDB2 could convert Datacom applications to DB2. Although the Presentation listed two existing customers, State Street Bank and Beta, as customers of ISI, Mr Shuma says that he did not know whether ISI’s claim that State Street Bank and Beta were ISI customers was correct or not. On 23 October 2001 Mr Shuma replied to Mr Russell’s email, noting that ISI had been attempting to market solutions to convert people from Datacom and IDEAL to DB2 for a while but that attempts had not been successful. Mr Shuma said that ISI had a different “back-end” but that the “front-end” working was ‘fishy’. He noted that the ISI descriptors could be used to describe CA’s VSAM-T front end (VSAM call interceptors) and that some of the same terms were used. He queried whether there had been some ‘borrowing’ by ISI to build their product but described this suggestion as ‘just my two cents’. At that stage, Mr Shuma maintains, it was not clear to him how it was claimed that 2BDB2 worked. Mr Shuma says that, in undertaking inquiries subsequent to Mr Russell’s email, he was informed about the difficulties that a customer experienced with 2BDB2, which led him to believe that the product was not of concern to CA.

Decision

Reasons for decision

CA did also contend that ISI used the CA URT Macros in the creation of the ISI 2BDB2 interface. However, as this claim was only raised briefly in CA’s closing written submissions and was not addressed further in response to my request for the parties to provide further submissions on the relevance of the CA URT Macros to CA’s breach of confidential information case, I consider it to be abandoned. In any event, CA has not discharged its onus of proof in supporting this conclusion.Conclusion on AMODDY and B2BRQA As to AMODDY, I conclude that:·AMODDY is a part of 2BDB2. ·It was written at least in part by Mr Richards. ·Mr Richards denies and CA has not established that Mr Richards wrote the relevant sections of AMODDY of which it complains or that he was the sole author. ·Mr Richards was quick to disclaim knowledge of, or memory of, parts of AMODDY that were relevantly identical to the relevant Key CA Manuals. ·CA has not proved by evidence that Mr Richards himself used the Key CA Manuals during his involvement in creating AMODDY or that any other writer of AMODDY used the Key CA Manuals.·However, of the list of 17 parameters in the RQA parameter sections of AMODDY, seven were the same as in the Programmer Guide and all 17 were the same as in the Database and System Administrator Guide. ·I do not accept that the precise correlation of the parameters is likely if there had been truly independent creation of AMODDY. ISI has not established that Mr Richards or another ISI contractor or employee independently created the parameters. ·Based on the similarity in content between the parameters in the RQA parameters section in AMODDY and those listed in the Database and System Administrator Guide, I conclude that this guide was used in the creation of AMODDY. Whether the information in the Database and System Administrator Guide was used by Mr Richards, Mr Worboys or another ISI programmer, it was incorporated into 2BDB2, an ISI product, for and on behalf of ISI. ·As I have concluded that the Database and System Administrator Guide was used, I am not prepared to draw the inference that the Programmer Guide, which contained only seven of the 17 parameters used by ISI, was also used in creating AMODDY. As to B2BRQA, ISI submits that the mapping of the RQA contained in B2BRQA did not involve the Programmer Guide and was by a legitimate process of reverse engineering by drawing conclusions from authorised observations and that use of such information is not unauthorised use. I make the following findings about the creation of B2BRQA:· Mr Richards accepts that B2BRQA maps with complete precision the specifications in the Programmer Guide apart from the complete list of parameters and the E section but still asserts that he was the “author” of this section. ·Mr Richards was quick to disclaim knowledge of, or memory of, the comment block, a part of B2BRQA that was relevantly identical to the Programmer Guide, had the Programmer Guide as its original source and could not have been produced by Mr Richards’ claimed method of utilising storage dumps. ·Despite the fact that ISI adduced evidence from other programmers involved in 2BDB2, none asserted authorship of that part of B2BRQA.·Mr Richards accepts that the Programmer Guide was the source of the comment block. That concession was inescapable and undermines Mr Richards’ original evidence about his method of creating B2BRQA.·ISI maintains that there was no copying of the pages before and after the page containing the text in the Programmer Guide that was used in the comment block and relies on Mr Richards’ evidence of independent creation. I do not accept Mr Richards’ evidence in this respect. I do not accept that storage dumps used by Mr Richards were the source of the content of B2BRQA. When faced with objective evidence that was inconsistent with his original assertions, Mr Richards simply disclaimed knowledge or changed his evidence. Once it was established that the Programmer Guide was copied in part, the inference is clearly open, and I draw it, that it was consulted and copied, probably by Mr Richards, at least to the extent of creating B2BRQA.

Ratio Decidendi

Legal Principle Established

For application programs that are written to be used in CICS, the DBURSTR, DBURTBL and DBUREND Macros are used in the generation of URTs but the DBURINF Macro is not used. In CICS, the URT object modules are not linked as part of the user application code written for CICS. Instead, DBCSVPR is linked with every one of the user’s CICS programs that accesses Datacom. This module provides a pathway to the CICS Services processes that use the URTs to define and control the resources within the database that will be available for use by the application programs connected to the CICS Services process. As with the batch URTs, the URT object modules used in the CICS environment remove the need for the CICS region to have the complex knowledge necessary to communicate to the database regions in the mainframe complex.2BDB2’s operation The term “2BDB2” is a reference to a suite of computer software products offered by ISI, some or all of which might be employed in connection with the conversion by a customer from use of a Datacom database system to a DB2 database system. In broad terms, 2BDB2 comprises three parts. The first element is known as “2BDB2 Datacom Data Converter”. The second element is known as “Transparency”. The third element is known as “2BDB2 Ideal”. In opening, CA made no complaint about the use of its alleged copyright works and confidential information in respect of the 2BDB2 Datacom Data Converter or 2BDB2 Ideal. However, CA later contended that ISI used its confidential information in creating parts of the 2BDB2 Datacom Data Converter. CA also claims that ISI has used certain information confidential to CA in creating Transparency. 2BDB2 Datacom Data Converter performs the function of migrating Datacom licensees’ data managed by Datacom to DB2. It does this by converting the data from their Datacom format into a format that is understood by DB2. 2BDB2 can migrate the data one data table at a time. 2BDB2 Ideal is a code conversion engine that performs the function of converting Datacom licensees’ applications that have been written in CA’s IDEAL language into COBOL applications which will operate in the DB2 environment. Transparency is designed to allow existing applications programs to be run against either Datacom or DB2, depending upon in which of those two databases the required information is located. Transparency interposes itself within the Datacom licensee’s mainframe in such a way that the Datacom licensee’s applications communicate with it. It is “bilingual” because it can understand the Datacom statements made by the Datacom licensee’s applications and can translate them into statements that can be understood by DB2. When Transparency identifies that a request has been made by a Datacom licensee’s application that relates to data still managed by Datacom, it simply passes the request on to Datacom. When Transparency identifies that a request made by a licensee’s application relates to data now managed by DB2, it passes that request on to DB2 but it does so in statements understood by DB2. As the Datacom licensee’s application is only written in statements that Datacom understands, Transparency translates the application’s request to a statement that DB2 understands and passes the request on. When DB2 responds, Transparency translates the output back into a statement that the application understands and places it into the area of the computer’s memory where the application expects that answer to be, as if the response has come from Datacom.