FEDERAL COURT OF AUSTRALIA Motorola Solutions, Inc. v Hytera Communications Corporation Ltd (Liability) [2022] FCA 1585 File number: NSD 1283 of 2017 Judgment of: PERRAM J Date of judgment: 23 December 2022 Catchwords: PATENTS – Applicant patentee of three method patents relating to digital mobile radios ('DMR') using Time Division Multiple Access ('TDMA') to divide frequency channel – disputed constructions – fair basing – inventive step – identification of inventive step in claims – manner of manufacture – stare decisis – whether Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 has a ratio decidendi – whether Full Court decision in Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 binding for single judge – whether Respondents' non-reprogrammed and reprogrammed DMR devices use methods of patents – secondary liability for importation of DMR devices – authorisation and joint tortfeasorship – whether Respondents took reasonable steps to prevent infringement – injunctive relief – relevance of ETSI Standard – additional damages COPYRIGHT – Applicant owner of Australian copyright in 11 computer programs in source code – importation by First Respondent of DMR devices into Australia containing firmware in object code – firmware compiled from intermediate source code in China and installed into DMR devices in China – First Respondent's intermediate source code developed using Applicant's source code – First Respondent's intermediate source code mostly lost although some available – header and source files – disassembly of object code back into assembly language – whether available intermediate source code copied from Applicant's source code – whether missing intermediate source code copied from Applicant's source code – substantial part – whether the fact that Applicant's programs derived from earlier versions renders them not original for the purposes of infringement – whether First Respondent's object code deemed to be a reproduction of Applicant's source code by s 21(5) of the Copyright Act 1968 (Cth) – whether compiled object code is an adaptation of Applicant's source code – secondary infringement of Applicant's Australian copyright by importation of DMRs into Australia – whether making firmware available for download in Australia infringement of Applicant's Australian copyright – where copies of firmware made in Australia by Second Respondent and authorised dealers – liability for authorisation and joint tortfeasorship – injunctive relief – additional damages – whether flagrancy to be measured against acts of copying in China or subsequent acts constituting infringement of Australian copyright – whether copying deliberate large scale industrial theft – extent of knowledge of theft within First Respondent – extent of knowledge at time of infringement – whether knowledge to be attributed to First Respondent Legislation: Copyright Act 1968 (Cth) ss 4, 10, 14(1), 21(5), 31(1), 36(1), 37(1), 115(4) Copyright Amendment (Digital Agenda) Act 2000 (Cth) Evidence Act 1995 (Cth) s 136 Federal Court of Australia Act 1976 (Cth) ss 37AE, 37AF, 37AG, 37AI, 37AJ Income Tax Assessment Act 1936 (Cth) s 109 Judiciary Act 1903 (Cth) s 23(2)(a) Patents Act 1990 (Cth) ss 7(2), 7(3), 18(1), 117, 122(1A) Patents Act 1990 (Cth) s 40(3), later amended by Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (Cth) Statute of Monopolies 1623, 21 Jac 1 c 3 s 6 Trade Practices Act 1974 (Cth) ss 45(2), 45A(1), now the Competition and Consumer Act 2010 (Cth) Federal Court Rules 2011 (Cth) Cases cited: Aktiebolaget Hässle v Alphapharm Pty Ltd [2002] HCA 59; 212 CLR 411 American Cyanamid Company v Berk Pharmaceuticals Limited [1976] RPC 231 Apotex Pty Ltd v Warner-Lambert Co LLC (No 2) [2016] FCA 1238; 122 IPR 17 Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29; 96 ALJR 837 AstraZeneca AB v Apotex Pty Ltd [2014] FCAFC 99; 226 FCR 324 AstraZeneca AB v Apotex Pty Ltd [2015] HCA 30; 257 CLR 356 Australian Broadcasting Commission v Parish (1980) 29 ALR 228 Australian Competition and Consumer Commission v Air New Zealand Ltd (No 3) [2012] FCA 1430 Australian Competition and Consumer Commission v Air New Zealand Ltd (No 12) [2013] FCA 533 Australian Competition and Consumer Commission v Cement Australia Pty Ltd (No 2) [2010] FCA 1082 Australian Competition and Consumer Commission v PT Garuda Indonesia Ltd (Remedies) [2019] FCA 786; 370 ALR 637 Australian Competition and Consumer Commission v Valve Corporation (No 5) [2016] FCA 741 Australian Mud Company Pty Ltd v Coretell Pty Ltd [2011] FCAFC 121; 93 IPR 188 Baigent v Random House Group Ltd [2007] EWCA Civ 247; 72 IPR 195 Brambles Holdings Ltd v Carey (1976) 15 SASR 270 Calidad Pty Ltd v Seiko Epson Corporation (No 2) [2019] FCAFC 168; 147 IPR 386 Cambridge University Press v University Tutorial Press (1928) 45 RPC 335 Catnic Components Limited v Hill & Smith Limited [1982] RPC 183 CCOM Pty Ltd v Jiejing Pty Ltd (1994) 51 FCR 260 Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202; 163 IPR 231 Commissioner of Patents v Microcell Ltd (1959) 102 CLR 232 Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177; 238 FCR 27 Commissioner of Taxation v Comber (1986) 10 FCR 88 Computer Edge Pty Ltd v Apple Computer (1986) 161 CLR 171 Cooper v Universal Music Australia Pty Ltd [2006] FCAFC 187; 156 FCR 380 D'Arcy v Myriad Genetics Inc [2015] HCA 35; 258 CLR 334 Data Access Corporation v Powerflex Services Pty Ltd [1999] HCA 49; 202 CLR 1 Davies v Lazer Safe Pty Ltd [2019] FCAFC 65 Dyson Appliances Ltd v Hoover Ltd [2001] RPC 26 Elconnex Pty Ltd v Gerard Industries Pty Ltd (1991) 32 FCR 491 Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2018] FCA 421; 130 IPR 387 Fresenius Medical Care Australia Pty Limited v Gambro Pty Limited [2005] FCAFC 220; 67 IPR 230 GlaxoSmithKline Australia Pty Ltd v Reckitt Benckiser Healthcare (UK) Ltd [2016] FCAFC 90; 120 IPR 406 Grimaldi v Chameleon Mining NL (No 2) [2012] FCAFC 6; 200 FCR 296 Hogan v Australian Crime Commission [2010] HCA 21; 240 CLR 651 Howard v Commissioner of Taxation [2012] FCAFC 149; 206 FCR 329 IceTV Pty Ltd v Nine Network Australia Pty Ltd [2009] HCA 14; 239 CLR 458 International Business Machines Corporation v Commissioner of Patents (1991) 33 FCR 218 Jones v Dunkel (1959) 101 CLR 298 JR Consulting & Drafting Pty Ltd v Cummings [2016] FCAFC 20; 116 IPR 440 Krakowski v Eurolynx Properties Ltd (1995) 183 CLR 563 LHRC v Deputy Commissioner of Taxation (No 4) [2015] FCA 70; 326 ALR 150 Lockwood Security Products Pty Limited v Doric Products Pty Limited [2004] HCA 58; 217 CLR 274 Lockwood Security Products Pty Ltd v Doric Products Pty Ltd (No 2) [2007] HCA 21; 235 CLR 173 Motorola Solutions Inc v Hytera Communications Corporation Ltd (No 2) [2018] FCA 17 Muller v Dalgety & Co Ltd (1909) 9 CLR 693 National Research Development Corporation v Commissioner of Patents (1959) 102 CLR 252 Nichia Corporation v Arrow Electronics Australia Pty Ltd [2019] FCAFC 2 NV Philips Gloeilampenfabrieken v Mirabella International Pty Ltd (1995) 183 CLR 655 Oliver Hume South East Queensland Pty Ltd v Investa Residential Group Pty Ltd [2017] FCAFC 141; 259 FCR 43 Oxworks Trading Pty Ltd v Gram Engineering Pty Ltd [2019] FCAFC 240; 154 IPR 215 R D Werner & Co Inc v Bailey Aluminium Products Pty Ltd (1989) 25 FCR 565 Ramset Fasteners (Aust) Pty Ltd v Advanced Building Systems Pty Ltd [1999] FCA 898; 44 IPR 48 Ranbaxy Australia Pty Ltd v Warner-Lambert Co LLC [2008] FCAFC 82; 77 IPR 449 Rehm Pty Ltd v Websters Security Systems (International) Pty Ltd (1988) 81 ALR 79 Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223; 164 IPR 1 Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150; 227 FCR 378 Seven Network v Cricket Australia (No 2) [2021] FCA 1032 Steelforce Trading Pty Ltd v Parliamentary Secretary to the Minister for Industry, Innovation and Science (No 2) [2018] FCAFC 47 Sunchen Pty Ltd v Federal Commissioner of Taxation [2010] FCAFC 138; 190 FCR 38 Telstra Corporation Limited v Phone Directories Company Pty Ltd [2010] FCAFC 149; 194 FCR 142 Vickers, Sons & Co Ltd v Siddell (1890) 15 AC 496 Warwick Film Productions Ltd v Eisinger [1969] 1 Ch 508 Wellcome Foundation Ltd v VR Laboratories (Aust) Pty Ltd (1981) 148 CLR 262 Division: General Division Registry: New South Wales National Practice Area: Intellectual Property Sub-area: Patents and associated Statutes Number of paragraphs: 2315 Date of last submission: 1 October 2020 Date of hearing: 22-23, 25, 29-30 July 2019, 1-2, 6-7, 12, 14-16 August 2019, 27-28, 30-31 July 2020, 3-7, 10-14, 17, 19-21 August 2020, 14-16 September 2020, 1, 7 October 2020 Counsel for the Applicant: Mr C A Moore SC, Mr A R Lang and Ms P L Arcus Solicitor for the Applicant: Herbert Smith Freehills Counsel for the Respondents: Mr C Dimitriadis SC, Mr J S Cooke and Mr C Burgess Solicitor for the Respondents (Patent Trial): MinterEllison Solicitor for the Respondents (Copyright Trial): Spruson & Ferguson Lawyers ORDERS NSD 1283 of 2017 BETWEEN: MOTOROLA SOLUTIONS, INC. Applicant AND: HYTERA COMMUNICATIONS CORPORATION LTD First Respondent HYTERA COMMUNICATIONS (AUSTRALIA) PTY LTD ACN 165 879 701 Second Respondent AND BETWEEN: HYTERA COMMUNICATIONS CORPORATION LTD First Cross-Claimant HYTERA COMMUNICATIONS (AUSTRALIA) PTY LTD ACN 165 879 701 Second Cross-Claimant AND: MOTOROLA SOLUTIONS, INC. Cross-Respondent order made by: PERRAM J DATE OF ORDER: 23 DECEMBER 2022 THE COURT ORDERS THAT: 1. The parties confer and, if possible, bring in a minute of order giving effect to these reasons by close of business on 13 February 2023 or, if no agreement be possible, provide a minute of the orders for which each contends by the same date. 2. Order 1 made by the Court on 25 November 2022 be set aside but only prospectively from the time of the making of these orders. 3. Order 8 of the orders made on 22 July 2020 remain in force until 1 March 2023. 4. The matter be stood over for further directions at 9.30 am on 15 February 2023. 5. Pursuant to ss 37AF(1)(b) and 37AG(1)(a) of the Federal Court of Australia Act 1976 (Cth), until further order of the Court, and subject to any restrictions imposed by the confidentiality regime agreed between the parties dated 10 April 2018 ('Confidentiality Regime') and/or the confidentiality regime agreed between the parties dated 24 May 2019 ('MSI Code Confidentiality Regime'), access to and disclosure (by publication or otherwise) of the unredacted text of the reasons for judgment delivered today be restricted to the parties and their legal representatives, and those persons to whom access is allowed under the terms of the Confidentiality Regime or the MSI Code Confidentiality Regime. 6. Nothing in Order 5 or any other earlier order of the Court prevents any party from publishing the covering pages of these reasons for judgment up to and including these orders or paragraphs [1]-[8] of the reasons or the Associate's Certificate appearing at the end of the reasons after paragraph [2315]. 7. By 27 January 2023, the legal representatives for the Applicant and the legal representatives for the Respondents exchange highlighted versions of the reasons for judgment identifying the parts of the reasons that are claimed to contain information confidential to their respective clients for redaction. 8. By 10 February 2023, the legal representatives for the parties confer on the proposed redactions and, if the parties are able to agree on the proposed redactions, provide to chambers an agreed form of the reasons for judgment with the proposed redactions highlighted, together with an agreed redacted form of the reasons for judgment that is suitable for publication. 9. In the event the parties are unable to agree on the proposed redactions, by 14 February 2023, the legal representatives for the parties provide chambers with: (a) a version of the reasons for judgment which identifies the redactions which have been agreed and those which are in dispute; and (b) a short written submission addressing the areas of disagreement. Note: Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011. REASONS FOR JUDGMENT CHAPTER I: INTRODUCTION [1] CHAPTER II: BACKGROUND TO TWO-WAY RADIO COMMUNICATIONS [9] What are Radio Communications and How Do They Work? [11] Well-Known Digital Radio Systems before July 2004 [93] Well-Known Digital Radio Systems before 28 July 2005 [115] Well-Known Digital Radio Systems before 3 October 2008 [120] International Field [121] CHAPTER III: THE PATENT TRIAL [123] CHAPTER IV: THE 355 PATENT [125] Introduction [125] Construction [185] Inventive Step [231] Manner of Manufacture [354] Infringement [360] CHAPTER V: THE 764 PATENT [422] Introduction [422] Construction [436] Fair Basis [467] Inventive Step [470] Manner of Manufacture [551] Infringement [552] CHAPTER VI: THE 960 PATENT [553] Introduction [553] Construction [584] Validity [639] Infringement [732] CHAPTER VII: INTRODUCTION TO THE COPYRIGHT TRIAL [737] CHAPTER VIII: STATE OF HYTERA'S TECHNOLOGY [749] Introduction [749] Strand Three: How Long Would It Have Taken Hytera to Bring the Prototype to Market? [766] Strand Two: The Failure to Carry Out Simulations [892] Strand One: The Failure to Consider Cost and Battery Life at the Development Stage [921] Overall Conclusions [931] CHAPTER IX: THE EVENTS AT SHENZHEN [932] Introduction [932] Problems Confronting Hytera's DMR Project at the end of 2007 [936] The Engagement of the Ex-Motorolans by Hytera [943] What the Ex-Motorolans Brought with Them [964] Roles within the Hytera DMR Team [988] Extent of Knowledge within the Hytera DMR Team that Motorola's Obviously Confidential Information Was Being Used [1015] Extent of Knowledge within the Hytera DMR Team that Motorola's Source Code Was Being Used to Develop Hytera's DMR Firmware [1027] The Removal of the FPGA and the Reasons for that Removal [1107] CHAPTER X: COPYRIGHT INFRINGEMENT [1144] Introduction [1144] Legal Mechanics of Motorola's Importation and Downloading Cases [1174] Substantial Part [1228] Objective Similarity and Substantial Part (General Observations) [1256] CHAPTER XI: WERE THE 11 WORKS INFRINGED? [1301] The EMT Component [1310] The Xlate Component [1603] The UIT Component [1685] The Darwin Ergonomics Platform [1717] Mobile and Portable Firmware [1731] The L1 Timer [1799] Framer [1851] FramerLib Library [1892] The HAL Serial Buffer [1897] DSP Firmware [1935] CHAPTER XII: LIABILITY OF HYTERA FOR IMPORTATION [1986] Introduction [1986] Relevant Facts [1990] Should Mr GS Kok's Knowledge at September 2013 Be Attributed to Hytera? [1996] Conclusion on Liability of Hytera for Importation [2002] CHAPTER XIII: LIABILITY OF HYTERA FOR COPYING AND COMMUNICATING [2003] Copying and Communicating the Firmware [2004] Authorisation [2010] CHAPTER XIV: LIABILITY OF HYTERA AUSTRALIA FOR COPYING AND COMMUNICATING [2013] CHAPTER XV: INJUNCTIVE RELIEF FOR COPYRIGHT INFRINGEMENT [2015] Introduction [2015] Injunctions against Particular Conduct [2016] General Injunction against Infringement of Copyright [2019] CHAPTER XVI: DAMAGES AND ACCOUNT OF PROFITS [2029] CHAPTER XVII: ADDITIONAL DAMAGES FOR COPYRIGHT INFRINGEMENT [2030] Introduction [2030] Flagrancy: Section 115(4)(b)(i) [2033] The Need to Deter Similar Infringements of Copyright: Section 115(4)(b)(ia) [2052] The Conduct of the Defendant after the Act Constituting the Infringement: Section 115(4)(b)(ib) [2053] Whether the Infringement Involved a Conversion from Hardcopy to Digital: Section 115(4)(b)(ii) [2060] Any Benefit Shown to have Accrued to the Defendant by Reason of the Infringement: Section 115(4)(b)(iii) [2061] All Other Relevant Matters: Section 115(4)(b)(iv) [2064] Conclusions [2086] CHAPTER XVIII: ADDITIONAL DAMAGES FOR PATENT INFRINGEMENT [2087] Introduction [2087] Hytera's Scan Function Was Developed Using Knowledge of How Motorola's Scan Function Operated [2089] Whether Hytera's Scan Function Software Was Copied from Motorola's Source Code [2107] Hytera's Knowledge of the 355 Patent [2113] Conclusions [2114] CHAPTER XIX: SUPPRESSION AND NON-PUBLICATION ORDERS [2122] Introduction [2122] Relevant Principles [2124] Motorola Application [2129] Hytera Application [2198] Joint Application: EP Licence Agreement between Motorola and Hytera [2273] 'Overlap' Documents [2301] Conclusion and Disposition on Suppression Order Applications [2305] CHAPTER XX: FINAL MATTERS [2308] Outline [2308] Declaratory Relief [2309] Tender of Translations [2310] Costs [2311] Confidentiality Orders [2312] Non-Publication of Reasons [2313] Further Hearing on Quantum and Leave to Appeal [2314] Orders [2315] PERRAM J: I INTRODUCTION 1 Motorola Solutions Inc ('Motorola') sues Hytera Communications Corporation Ltd ('Hytera') and its Australian subsidiary, Hytera Communications (Australia) Pty Ltd ('Hytera Australia') for patent and copyright infringement. The alleged infringements relate to digital mobile radios ('DMR'). DMRs can be mobile (e.g. affixed to a vehicle which moves) or portable (e.g. carried around by a person). An individual DMR can communicate directly with another DMR without an intermediary, and when it does so, the two devices are said to be communicating in 'direct mode'. However, they also are frequently deployed with fixed base stations, or 'repeaters', through which they communicate with each other and by which means their range is extended. 2 Motorola alleges that Hytera's DMRs infringe three of its patents. These patents relate to a pre-existing technology which permits a frequency band within the radio spectrum (a channel) to be divided into timeslots so that more than one person may use the same channel at the same time. This technology is known as Time Division Multiple Access or, more commonly, 'TDMA'. The three patents are methods which refine the efficiency of TDMA. The first patent, No. 2005275355 ('355 Patent'), is a method and system which improves the time taken to scan a channel to determine whether there is activity on that channel. The second patent, No. 2009298764 ('764 Patent'), is a method for efficiently synchronising to a desired timeslot. The third patent, No. 2006276960 ('960 Patent'), is a method and system for accessing a base station which has been de-keyed. I will refer to the 355 Patent, the 764 Patent and the 960 Patent collectively where necessary as 'the Patents'. 3 Motorola alleges that Hytera imported into Australia DMRs which infringed the methods of the three patents and sues for secondary infringement. Hytera disputes Motorola's construction of each of the Patents and contends in each case that if construed as Motorola suggests, each patent is invalid for various reasons. I have concluded that Motorola's construction of the 355 Patent is correct and that the challenges to its validity fail. I have concluded therefore that Motorola's infringement case in relation to the 355 Patent largely succeeds although I have accepted that Hytera did not infringe the patent after November 2019 when it took steps to ensure that existing mobile stations were upgraded before reprogrammed base stations were supplied to end users (the upgrade removing the infringement). In the course of reaching this conclusion, I have rejected Hytera's submission that any infringement was required by the relevant European Telecommunications Standards Institute ('ETSI') standard. I have rejected Motorola's infringement case on the 764 Patent. Motorola's construction of that patent is not correct. If it had been correct, I would have concluded that the patent was invalid as it would not have been fairly based. I have also rejected Motorola's infringement case on the 960 Patent. Although Motorola's construction of the patent is correct, the patent is invalid for want of an inventive step. In the case of all three patents, I have rejected Hytera's contention that no manner of manufacture is involved. I have rejected Motorola's claim for additional damages for patent infringement. 4 The copyright suit relates to the firmware which was installed on Hytera devices imported into Australia. Motorola alleges that this firmware (which is in binary code) was derived from object code which had been compiled from Hytera's source code. That source code was written in the computer languages C and C++. Much of Hytera's source code has been lost. Motorola alleges that Hytera developed its source code by copying Motorola's source code. This was said to have been done in 2008 when several former employees of Motorola went across to Hytera to help it develop its DMR products. Motorola says that 11 of its computer programs have been copied by Hytera. Motorola's proof of this was hindered by the fact that much of the Hytera source code has vanished. In relation to some of the vanished source code, the object code compiled from it was available. Motorola sought to disassemble this object code back into assembly language and to prove by these indirect means that the missing Hytera source code had been copied from the Motorola source code. The proof of these matters was protracted. 5 I have concluded that Motorola has succeeded in proving that Hytera copied a substantial part of 6 of the 11 computer programs and is liable for copyright infringement. Motorola also alleged that Hytera's actions constituted a substantial industrial theft. I have accepted this submission and the allied contention that Motorola is entitled to additional damages on account of the flagrancy of the infringements. 6 The programs which Motorola alleges were copied by Hytera consisted of source code which was compiled into firmware to be installed on its DMR devices. The development of this firmware was a lengthy and complicated process of software engineering involving a large number of engineers. The entire undertaking was known as 'Project Matrix'. Taking its cue from the movie The Matrix, the individual projects within Project Matrix were known as Project Neo, Project Morpheus and Project Cypher. As the Oracle observed to Neo in the third film, The Matrix Revolutions, 'everything that has a beginning has an end'. Despite some misgivings along the way, these reasons will eventually affirm the truth of this observation, although not until paragraph [2315]. 7 The trial was conducted in two phases with the patent allegations being heard before the copyright allegations. In consequence, there are two sets of transcripts and two separate court books. The reasons for judgment dealing with the patent allegations (apart from additional damages) refer only to the transcript and court book used in the patent phase. The reasons for judgment dealing with the copyright allegations refer principally to the copyright transcript and court book but there are occasional references to the patent materials. Where this occurs, I note it. These reasons were published on 23 December 2022 in an unredacted form subject to certain non-publication orders and confidentiality arrangements which restrict its publication due to the potential presence of trade secrets in the reasons for judgment. As at 23 December 2022, only the first eight paragraphs will be publicly available. The full reasons for judgment, if necessary subject to some redaction, will be published in the New Year once the parties have had an opportunity to consider whether any redaction is necessary. 8 I deal first with the patent allegations and then the copyright allegations. In order to understand the patent allegations, it is necessary to understand two-way radio communications and, more particularly, TDMA. To these dry matters I now turn. II BACKGROUND TO TWO-WAY RADIO COMMUNICATIONS 9 To understand the issues which arise in the patents suit, it is necessary to have a grasp of the electronic engineering underpinning two-way radio communications. The purpose of this section is to equip the reader with sufficient technical understanding to grapple with the issues which divide the parties and to understand the technical context in which the inventions which are the subject of the Patents are immersed. Where necessary, I will also discuss some of the industry standards which operated, as a prelude to the subsequent discussion of the common general knowledge ('CGK'). Some aspects of this discussion are also relevant to Motorola's copyright infringement allegations in relation to its source code. 10 Mr Kuhrt provided a high-level overview of two-way radio communications technology in his first affidavit at §§70-196 which I have found useful. Mr Kuhrt's evidence was directed at information which he believed would have been well-known and generally accepted by engineers working in the field of two-way radio communications in Australia as at 26 July 2004, the priority date of the earliest patent in suit, the 355 Patent. The following discussion is largely taken from his evidence and is supplemented where necessary with the evidence of Professor Rangan. It has a particular emphasis on the three matters which are the subject of the Patents: radio scanning, repeater de-keying and re-keying, and synchronisation methods. WHAT ARE RADIO COMMUNICATIONS AND HOW DO THEY WORK? 11 Radio is a method of transmitting electromagnetic energy across distance without using a direct, wired connection. The electromagnetic energy takes the form of radio waves which have a certain frequency. Radio waves are generated and sent out through a transmitter and are then received by a radio receiver using antennas. Depending upon their length, radio waves may travel in three ways: (i) by line of sight; (ii) by being reflected off of buildings or other objects, in which case the communications will not travel beyond the horizon; and (iii) by being reflected off of the ionosphere, in which case they can return to earth beyond the horizon. Different radio frequencies ('RF') are used for these different reflective requirements. 12 Radio communications can be transmissions of audio (i.e. analogue transmissions) or of data (i.e. digital transmissions). Where a transmission is an analogue transmission, the whole of the voice transmission can be sent and decoded without any additional information being transmitted. In practical terms, this means that the radio signal carries nothing but the voice transmission. By contrast, where a digital communication is involved, the decoding of the message requires the use of what are called 'overheads'. Overheads are the bits of digital information that are not associated with the substantive transmission, or what is usually referred to as the 'payload'. Digital transmissions are thus made up of two kinds of information: information which comprises the overhead, and information which comprises the payload. 13 Two of the Patents in this case are directly concerned with overheads and a desire to reduce them and thereby make more of the signal available for the payload. One of the overheads in a digital communication arises from the need to achieve what is called 'synchronisation' between the devices which is achieved using a synchronisation pattern (I explain this more fully below). Another relates to the scanning of channels which involves the use of information to identify the devices to which a payload is to be delivered. This kind of information is referred to as 'control information'. The more of the radio transmission that is consumed by transmitting control information, the less of it is available to transmit payload. The Radio Spectrum 14 The radio portion of the electromagnetic spectrum (which radio communications are transmitted on) is divided into three sub-categories known as 'frequency bands'. These bands are the: (i) high frequency band ('HF') (3,000 kHz to 30 MHz); (ii) very high frequency band ('VHF') (30 MHz to 300 MHz); and (iii) ultra-high frequency band ('UHF') (300 MHz to 3 GHz). Each of these bands is further separated into bandwidth channels which radio users use to transmit communications. These channels reflect the frequency range occupied by a carrier signal and are separated by a space known as 'channel spacing'. The size of the bandwidth channel and the size of the channel spacing between each channel is determined by a regulatory authority which in Australia is the Australian Communications and Media Authority ('ACMA'). In 1999, ACMA determined that two-way radios would use channel bandwidths of 12.5 kHz. What this means is that each channel may occupy a range of frequencies in the radio spectrum which are no wider than 12.5 kHz. The size of this bandwidth limits the number of frequencies that can be defined inside a relevant band. 15 Generally, the wider the channel bandwidth, the better the audio fidelity or the higher the data rate will be. In other words, the larger the channel bandwidth is, the better quality the radio communication will be. For example, whilst the bandwidth for two-way radio communications is 12 kHz, the bandwidth for commercial frequency modulation ('FM') broadcasting stations is set at 100 kHz. In general, therefore, this creates a problem whereby the interests of the regulator (here, ACMA) and radio users are opposed. Whereas ACMA wishes to reduce the bandwidth of a channel, thereby increasing the number of operators that might transmit, radio users desire a greater bandwidth (for greater audio quality) which reduces the number of possible users. The Components of Radio Devices 16 A two-way radio is a device that can both receive and transmit signals from other radios operating on the same RF. There are two kinds of two-way radio devices: half-duplex devices and full-duplex devices. A half-duplex radio is one which permits the user to talk or to listen but not to do both at the same time. A full-duplex radio, by contrast, has the ability to send and receive transmissions at the same time. It does so by sending transmissions on one frequency and receiving them on another. 17 In the case of a half-duplex two-way radio, the user presses a 'Push-To-Talk' ('PTT') button which activates the transmitter. When the PTT button is not pressed, the device's radio receiver is activated. Half-duplex radios may also function by using what is referred to as 'simplex communication'. Where this occurs, the transmission and reception occurs on a single RF. In other words, the radio switches between the 'transmit' and 'receive' functions, transmitting on one frequency and then switching to receive any incoming transmissions using the same frequency. 18 To be able to transmit and receive at the same time, full-duplex radios may use two different frequencies. Typically, this means that one frequency is assigned for the radio to transmit and another is assigned to receive communications. Together, the two frequencies are known as a 'frequency pair' or a 'physical channel'. Alternatively, a full-duplex radio may use what are called frequency sharing methods. I discuss these further below, but in a digital system this involves breaking the communications up into digital packages and transmitting the packages sufficiently frequently such that the underlying process is not audible. Terminal Equipment 19 Mobile stations are typically vehicle based installations that allow for communication to other local terminal equipment (e.g. between police cars). These are also referred to as 'radios' or 'subscriber units'. They may communicate in either of two modes: (i) direct mode; or (ii) 'repeater mode'. A direct mode transmission occurs between two mobile stations (without the use of a repeater, which I discuss below) and usually takes place on the same transmit and receive frequencies (i.e. with each radio switching between transmitting and receiving communications in the fashion described above at [17]). A direct mode communication is possible so long as both mobile station users are not too far apart and there is no obstruction between the sender of the communication and the receiver. 20 Portable terminals are relatively low power but more readily moveable versions of mobile stations often worn on the body, i.e. walkie-talkies. Repeater Equipment 21 Repeaters, which are also referred to as 'base stations', are devices which relay transmissions from terminal equipment, thus extending the coverage of those terminals. They are typically located above terminals (such as on top of a mountain or building) and utilise a hard-wired power source. Thus, where a repeater is used, the sender of the communication will transmit the message from their terminal and once the transmission reaches the base station, the base station will then repeat the message to the intended receiver. In a trunked system, a repeater also repeats the transmissions which it receives from a control station. I return to the topic of trunking below. 22 Relatively simple two-way radio systems only include a single repeater. Multiple repeaters, however, may be interconnected to increase the coverage area (known as a 'cell') and to enable direct links to control stations. Repeaters typically receive and transmit on two different RFs, known as the 'uplink' and the 'downlink'. Terminals transmit information (such as voice calls) through the uplink towards the repeater. The repeater then retransmits or repeats the information through the downlink towards another repeater or terminal. In its most simple form, a repeater is therefore two terminal devices connected together, with one operating as the uplink and one operating as the downlink. This is a schematic of a single repeater two-way radio system: 23 The downlink is essential to the processes of 'de-keying' and 're-keying' which are central to the 960 Patent. In many two-way radio systems, the repeater is designed to 'de-key' after a transmission. When a repeater de-keys, it turns off the downlink. This means that the repeater cannot transmit information using the downlink unless it 're-keys'. Further, terminals listening to the repeater's downlink frequency will not receive transmissions from that repeater. A common reason why a repeater will de-key is because there is no active terminal using the repeater's cell. Since the radio spectrum is a limited and shared resource, repeaters are often programmed to de-key in order to ensure that they are not powered on when they are not in use and to allow other repeaters to use the frequency. 24 Repeaters often have a fixed timer (e.g. 10 sec) which starts when the repeater detects that there is no activity on the repeater's uplink frequency. This will occur when there is no transmission being sent from any of the terminal devices. This timer is often referred to as the 'hangtimer'. One of the purposes of the hangtimer is to ensure that the recipient has sufficient time to respond to a communication before the repeater de-keys. When the hangtimer expires, the repeater de-keys. 25 If a mobile station wants to utilise a de-keyed repeater for transmissions, it must first wait for the repeater to 're-key'. When the repeater re-keys, it reactivates the downlink and can send outgoing transmissions again. Although a de-keyed repeater's downlink is deactivated, its uplink is still monitored and is able to receive transmissions. This allows a de-keyed repeater to receive messages from terminals, enabling it to re-key. The process of re-keying, however, can take time and delay transmissions. This can be a problem for users (such as a member of the emergency services) who need to relay a communication quickly. Control Stations and Control Channels 26 Control stations facilitate communication and signalling to remote terminal equipment. They may be positioned in a control centre or a depot. A simple control station may consist of a speaker, a microphone and a PTT switch. A more complex control station may include several networked computers and remotely accessible data bases. Control stations are a common feature of trunked systems which are discussed below at [88]. 27 A control channel is a channel in a trunking system where network access is requested and assigned. They are used by radio users to be assigned to a traffic channel to begin a voice transmission. Modems 28 Modems facilitate the transfer of data using RFs. Prior to July 2004, some analogue two-way radio systems included modems as an optional component. This is because their presence allowed analogue systems to transmit data (as opposed to just voice) over the analogue signal. By allowing data to be transmitted in this way, control information could therefore be transmitted even though the system was not digital. Examples of the kind of control information that could be transmitted included: information identifying a particular terminal (terminal identification information), information identifying groups of terminals to be included in a communication (talkgroup identification information), and information as to which channels were to be used for what (channel allocation information). The word 'terminal' is used interchangeably with 'subscriber unit' or 'mobile station'. 29 In analogue systems, modems were a physical component of the radio device (i.e. hardware in the terminals and the repeaters) which turned converted data into an analogue (that is, audio) signal. In digital systems, however, modem functionality was incorporated into the software of the devices and no physical modem was needed. 30 An early example of an analogue two-way radio system which used modems to transmit data was the system used by taxi providers. The address information for jobs was transmitted to taxi drivers from a control centre as data over the analogue network which, I infer, was otherwise used to carry voice signals. Two-Way Radio Functionality 31 Cellular communication systems such as mobile phones are designed for one-to-one communications and so are usually used by individual consumers. By contrast, two-way radios are designed to be used by professionals in sectors such as government, industrial, and emergency services and so are focussed on group call communications which are also known as one-to-many communications. As a result, two-way radios utilise a feature known as 'talkgroups' (discussed in more detail below at [33]). Mobile phones are typically smaller, have lower power levels and are full-duplex devices (i.e. they can communicate and receive at the same time). Two-way radios are larger devices with a relatively higher power level and may be full-duplex or half-duplex (in which case, as explained above, they cannot transmit and receive at the same time). 32 As already noted, two-way radios can engage in direct mode between themselves, or in repeater mode via a repeater. Mobile phones do not have a direct mode and only communicate through network infrastructure. Talkgroups 33 A talkgroup is a way of organising multiple individual radio devices into groups of users who can all communicate with each other. Each talkgroup has its own 'group identity' which is programmed into the memory of each individual radio device. When a radio device that is a member of a specific talkgroup transmits, all the other members of the talkgroup are able to hear and respond to that transmission. The use of talkgroups allows for private communications between members of a particular talkgroup by excluding radio users that are not part of that group. It also facilitates effective communication, in that one user can communicate to a group with a single transmission. 34 For example, an individual firefighter who is based in Richmond in Victoria may want to communicate with a number of different groups of people depending on the situation: 35 To do so, the radio device that the firefighter uses might be assigned to different talkgroups. One talkgroup to which the firefighter is assigned may include all emergency services within 15 km of where the firefighter is based in Richmond (i.e. Melbourne CBD Emergency Services in the above diagram). This talkgroup would allow the firefighter to broadcast communications to ambulances and police officers in the nearby region. The firefighter could also be assigned to a talkgroup which is limited to firefighters from Richmond Fire Station (i.e. Station 10). This could allow the firefighter to talk and receive information from his station in private. More narrowly, the firefighter could be assigned to a talkgroup which is only his or her unit (i.e. Company 6) from the Richmond Fire Station. This would allow the firefighter to communicate with his or her team while out in the field without needing to broadcast to the entire station or to all emergency services. Scanning 36 Mobile and portable radio users tune into specific channels in order to transmit or receive communications. Users can select a channel either: (a) manually (usually through a dial or buttons) by selecting an appropriate channel; or (b) by using the radio automatically to scan channels. 37 The process of scanning involves the receiver radio searching multiple channels (known as a 'scan group') to find a 'valid' transmission. A scan group consists of a group of frequencies that may be of interest and is stored in the memory of the radio. When the radio determines that it has found a valid transmission, it will stop and lock onto that channel and then send the communication to the radio's speaker. A valid transmission is a communication which meets specific conditions, such as having certain talkgroup or address information. The conditions which will make a transmission valid are programmed into the radio device. If the receiver radio decodes the message and identifies that all of the relevant conditions are present, the transmission will be deemed valid and will be broadcast through the speaker. If the transmission does not meet all of the programmed conditions, however, it will be ignored. In the example of the firefighter above, for instance, the radio device could be programmed such that a transmission addressed to one or more of the three talkgroups would be a valid transmission. 38 There are various ways to program a radio's scanning capabilities. One way in which a radio's scanning capabilities might be programmed is called 'priority scanning', which enables the radio to scan important channels more frequently. Automatic scanning, such as priority scanning, can be advantageous because it can take time for a user manually to select channels and users may miss transmissions if they are on the wrong channel. Various systems existed for automatic scanning prior to the priority date for the 355 Patent which is concerned with scanning. Different Types of Two-Way Radios 39 Two-way radio systems are generally split into analogue and digital systems. The main difference between them is the way that signals are transmitted and received. Analogue radio systems use electrical signals which, at least conceptually, resemble sound waves to deliver voice audio over an RF. Digital radio systems, by contrast, process sounds into patterns of numbers which are then transmitted over an RF. Digital two-way radios can allow users to transmit data as well as audio. They are also more secure. Analogue Two-Way Radios 40 Early two-way radio systems transmitted voice messages using analogue methods over RFs. Communication was either direct from one terminal to another on a simplex channel (that is, on a single frequency) or it was transmitted between terminals via a repeater on different transmit and receive frequencies. 41 Without the inclusion of the repeater, the coverage of a radio system is dependent on the power of the terminal. Since terminals are often portable and therefore powered by a battery, the power of early terminals was relatively low. However, since early analogue two-way radio systems could be used in both direct mode and repeater mode (that is, with or without a repeater), simple analogue two-way radio systems often included a single repeater to relay communications between connected terminals. The coverage of such a system is restricted by the power of the single repeater. This type of system was very common in Australia before the 1980s. 42 Larger two-way radio systems include multiple repeaters that enable the system to cover a larger area. While this type of system allowed for extended coverage, a problem was that all of the connected repeaters were required for a single transmission. This meant that only one transmission could take place using connected repeaters in the system at a time. This problem is illustrated in the following diagram: Scanning in Analogue Two-Way Radio Systems before 26 July 2004 43 Early two-way radio systems required radio users (such as the user of a mobile station in a vehicle) manually to change the channel to scan the system for relevant transmissions. This meant that when a user was moving around they would need to know the channel which was associated with the closest repeater and then select that channel on the mobile station in order to receive the transmission. 44 Automatic scanning and voting functionality was then developed in around the 1980s to allow for users moving between different repeaters automatically to receive communications from different repeaters. In early analogue systems, this was achieved by a list of frequencies (each of which was associated with a different repeater) being saved in the memory of the terminal devices. When set to scan automatically, the terminal device would then step through the list of frequencies and lock onto each to determine if a transmission was taking place. 45 A problem with this automatic scanning methodology, however, was that there was no assessment of signal strength when the terminal device stepped through the list of frequencies. As a result, terminals often locked onto a repeater that was not the closest repeater to them, with the consequence that they had low signal strength. 46 Automatic voting was thus developed to ensure that signal strength was taken into account when a terminal automatically scanned RFs. Automatic voting was similar to automatic scanning in that the terminal would automatically scan through a list of frequencies saved to memory in the terminal. However, automatic voting required the terminal device to assess the signal strength of each frequency stored in memory in the terminal before deciding which frequency (i.e. which repeater) to lock onto. This type of system often included a control station that was independent of the repeaters. That control station would re-key the repeaters every minute or so to produce a burst of energy for a length of time that was sufficient for each terminal to complete the automatic voting function and record their local site (i.e. the local repeater with the strongest signal strength). 47 Techniques were also developed before 26 July 2004 that enabled analogue terminals automatically to scan frequencies for specific types of communications (e.g. communications to a specific talkgroup). One example of this kind of technique was what was known as the 'Code Tone-Coded Squelch System' ('CTCSS'). The CTCSS adds a low frequency tone to a voice communication. Terminals included in their memory a list of CTCSS tones that were associated with, for example, a talkgroup. This enabled the terminals to listen for a specific CTCSS tone. If the tone for a talkgroup which was saved to the terminal's memory was heard on a channel while it was automatically scanning, then the terminal would stay on the channel. Otherwise, the terminal would continue scanning the other channels saved in its scan list. As will become clear, the concepts of scanning and staying on a channel are important to the 355 Patent. 48 A well-known problem with both automatic scanning and automatic voting in early analogue two-way radio systems was the length of time that it took for a terminal to complete the process. This limitation was a physical limitation which was inherent in analogue two-way radio systems. It was caused by the fixed amount of time that it took the terminal to perform the automatic scanning and automatic voting processes because it involved a number of steps. First, the radio would find an RF carrier. Secondly, using the example of CTCSS tones (although other methods might be used), it would decode the CTCSS in a hardware chip or in software. Thirdly, it would 'qualify' the channel and then, if all the relevant criteria were met, it would remain on the channel to start receiving communications. By 'qualify', I understood Mr Kuhrt to mean that, having detected the relevant CTCSS tone, the device had to be sure that it had done so and that what had occurred was not a random appearance of a tone frequency. This is consistent with his explanation that automatic scanning and voting in analogue two-way radios required the device to receive a certain number of radio wave cycles before the device could qualify the radio signal. As a result of the CTCSS tone being of such a low frequency, the time spent scanning and voting was determined by the period of the waveforms. For example, a two-way radio might have to wait for five cycles of the CTCSS waveform before it could complete the process and start receiving transmissions. Mr Kuhrt thought that this problem was a well-known problem prior to the late 1980s which I accept. One solution to the problem was to limit the number of frequencies to be scanned. De-keying and Re-keying in Analogue Two-Way Radios Prior to 26 July 2004 49 Prior to 26 July 2004, analogue repeaters included a hangtimer which prevented a repeater from de-keying immediately after a transmission. This hangtimer ensured that the recipient had sufficient time to respond before the repeater de-keyed (as above, where a repeater de-keyed it would result in the repeater releasing the downlink frequency to allow for other system users to begin a transmission). 50 Mr Kuhrt then gave this evidence in Kuhrt-1 at §117: Analogue terminals often included a light that displayed to the user whether the repeater was keyed. If a transmission was sent to a de-keyed analogue repeater, the repeater searched for a CTCSS tone. The CTCSS tone was provided to safeguard the systems against inadvertently keying the repeater on any unintended transmissions. If the repeater detected a valid CTCSS tone, it re-keyed, such that the repeater is able to then repeat received transmissions. 51 The meaning of this is not entirely clear to me. In particular, I am not clear on who provided the CTCSS tone in the third sentence. Overall, the most likely reading of this paragraph is that when it re-keyed the repeater would, before selecting a frequency upon which to broadcast, check to see that that frequency did not already have a CTCSS tone on it. If it did have such a tone, the repeater would re-key to a different frequency. Digital Two-Way Radios 52 Digital two-way radios were introduced in around the 1990s. In digital two-way radios, voice (and data) is transmitted using binary digits (i.e. 1's and 0's) ('bits') over RFs. The use of the binary system allows for 'error correction embedded signalling' and 'control information' to be included in each transmitted packet. I explain these concepts below at [57]. Each packet contains an assembly of bits. For present purposes, digital radios also introduced two other relevant innovations. First, the software in a digital radio contains an algorithm which understands the difference between voice audio and background noise. As a result, unwanted background noise is not transmitted to the radio's speaker and digital radios provide users with enhanced voice capacity and higher-quality coverage. 53 Secondly, digital two-way radio technologies introduced the ability to divide single-call RF channels. By 'single-call RF channels' I mean that the frequency is devoted to the carrying of a single communication. In a digital radio communication, the fact that the transmission is made up of packets of data means that with appropriate timing protocols in place, more than one communication can be carried at one time on the same frequency. This means that multiple users could access a single channel at one time (discussed below at [75]). The first digital two-way radio systems were the: (a) MPT1327 (analogue voice with digital control messaging, discussed below at [93]); (b) APCO P25 (digital voice and data, discussed below at [100]); and (c) Terrestrial Trunked Radio ('TETRA') (digital voice and data, described below at [107]). 54 A transmission from a radio user in a digital system comprises two key elements: (a) the payload; and (b) embedded signalling information (also known as 'control information'). 55 Mr Kuhrt described transmissions in digital radio systems as having three elements and in a summary section distinguished embedded signalling information from control information. However, his subsequent discussion treated control information as embedded signalling information: see Kuhrt-1 at §§120, 122-123. For present purposes, I will assume that his substantive discussion reflects the correct view. Payload 56 As I have explained above, payload is the term used to describe the part of a transmission that contains the substantive communication (as opposed to, for example, the control information). It is a type of data that is transmitted in large blocks made up of many bits and usually relates to voice based or data based transmissions. When voice is being transmitted it is typically referred to as 'voice payload'. Similarly, when data is being transmitted it is referred to as 'data payload'. Embedded Signalling (Control Information) 57 After a process referred to as synchronisation (described below at [59]), the receiving station needs to determine what sort of transmission is in progress. This is performed using 'embedded signalling' which is also known as control information. Control information is decoded messages which consist of bits or words (which are groups of bits). These messages give information about certain parts of the transmission. For example, the control message could give information about the payload type by differentiating between voice or data, the source of the transmission (i.e. which radio device the message has come from), or the recipient of the message which could be a single radio, a talkgroup or a 'colour code'. I return to colour codes later in these reasons but, for present purposes, colour codes may be understood as referring to the geographical area covered by a particular base station. Data Frames 58 Control information is contained within what are called 'data frames'. A data frame is the frame in a digital communication system which the bits that are used to carry voice and data are packaged into. A frame is a unit of repeating structure and typically includes a specific number of bits. Bits relating to specific functions (e.g. the payload, frame synchronisation, and control messages) are assigned a specific location within a frame. A set frame structure is important as the receiving device needs to be able to decode the bits within a frame. For example, the receiving device needs to know which series of bits provide the payload portion of the received frame. Frame Synchronisation 59 In order for these data frames to be transmitted, the sending and receiving stations must be in synchronisation. Synchronisation is important for what are referred to as 'multiple access communications systems'. The current litigation is concerned with such systems. These are discussed below in more detail at [75]. Synchronisation is important in multiple access communications systems because the receiving device needs to determine which portion of the data on an RF is intended for that receiving device. When in use, a receiving device receives a constant stream of bits during the digital transmission. Frame synchronisation enables a receiving device to differentiate between the different portions of the constant stream of data so that it can determine the portion of the data that corresponds to the payload. As I understood this evidence, it means that in a data frame, if different groups of bits are assigned for different purposes, the receiving device must be able to know which part of the stream it is looking at. If a data frame is 216 bits in length, for example, and the first bit of the frame signals some particular meaning (such as whether the channel is active), then this meaning will be lost if the receiving device does not know where the frame starts. 60 To enable frame synchronisation, digital terminal and repeater devices include a crystal. The crystal is an electronic element made from quartz crystal which is used to generate an internal timing reference (like an internal clock). The purpose of frame synchronisation is to synchronise the internal clock of the receiving device (such as a terminal) with the internal clock of the transmitting device (such as a repeater). The purpose of this clock synchronisation is so that the receiving device is then able to recognise the start and end of the data frames. Once the receiving device knows this, it can locate specific portions of the incoming data within each frame. 61 To synchronise with a transmitting device, a receiving device locates what is known as a 'synchronisation pattern' or 'synchronisation word'. A synchronisation pattern or synchronisation word is a known data sequence that is transmitted at certain times or 'intervals' during a transmission. This synchronisation pattern is a series of bits that form a word and is a specific sequence of 1's and 0's that the receiving device will recognise. I would say by way of further explanation that the two devices do not need to be have been synchronised in order for the synchronisation pattern to be recognised. That is, the synchronisation pattern can be transmitted asynchronously. A useful non-technical analogy might be to think of a train made up of carriages (data frames). The synchronisation pattern corresponds to a fixed symbol in the middle of each carriage (such as a corporate logo). Since it is known how far apart the logos on each carriage are from each other, it is easy to set one's clock to the same speed as the train just by timing how long passes between each logo. Once that is known, one can access the carriages of the train in sync with its speed and access defined portions of the carriages using one's own clock. For example, the first 1 m of each carriage might contain information about where the carriage is going. 62 More technically, recognition of the synchronisation pattern allows for frame synchronisation between a receiving and transmitting device. Typically, the synchronisation pattern is located at the start or the middle of the data frame. Once a device locates the recurring synchronisation pattern (recurring because it is located in each repeating frame), the receiving device is able to determine where the pattern is in the data stream and is then able to decode the incoming frames to obtain relevant information. Frame Synchronisation in Repeater Mode 63 Terminals operating in repeater mode (i.e. where they are communicating through a repeater) synchronise to the reference timing set by the repeater. The repeater sets the reference timing (meaning the timing of the repeating frames) and, as such, the timing of the synchronisation patterns. This ensures that all of the terminals that are connected to the repeater are working to the timing reference and are synchronised to the repeater without conflicting with one another. This is important where multiple channels are included on the one frequency (a topic discussed below). Communications which are received out of synchronisation are ignored by a repeater unless the signal is a 'wake-up' message (which I discuss below at [72]). 64 Terminals can lose synchronisation for a variety of reasons. A loss of signal is generally referred to as a signal drop-out or a loss of carrier. Drop-outs can be short (such as a few milliseconds) or long (such as several seconds). Longer drop-outs may occur when the terminal moves too far away from the repeater or during periods of interference (such as when a terminal moves underground or under a bridge and is unable to maintain a signal with the repeater). 65 A phenomenon referred to as 'Rayleigh fading' causes short term drop outs in two-way radio systems. Fading may occur due to radio waves reflecting off buildings or other objects which cause an interference to radio signals. In this circumstance, the RF carrier (i.e. signal strength) may drop down to zero and then return very quickly (e.g. within milliseconds). 66 In digital two-way radio systems, terminals communicating in repeater mode may temporarily maintain data synchronisation (or reference timing) during short periods of interference. This is typically a short period of time, however, as the reference timing being maintained by the terminal will begin to drift from the timing which was being provided by the repeater before the interference occurred. The period of time that a terminal is able to maintain frame synchronisation for when there is an interference is dependent on a range of factors including the quality of the terminal's hardware such as the crystal. For example, the period of time for which a terminal is able to maintain adequate frame synchronisation may be less than one second. When the period of interference ends and the terminal again receives data from the repeater's downlink (including the synchronisation pattern), it will adjust its timing, if required, to ensure that synchronisation with the repeater remains in place. 67 The eventual drift between a terminal's reference timing and the repeater's timing means that after a period of time without receiving transmissions from the repeater, the terminal may then need to resynchronise with the repeater once again to receive and transmit data. Examples of Systems Using Frame Synchronisation 68 An example of a two-way radio system that includes frame synchronisation is a system called APCO P25 (discussed below). In P25 systems, a special sequence of 48 bits (a synchronisation pattern) is located at the beginning of a frame. In a P25 system, frame synchronisation occurs at the beginning of every message and is inserted every 180 msec throughout the voice message. MPT1327 devices (discussed below) also rely on frame synchronisation in order to decode messages. In TETRA systems (discussed below), the repeater sends out frames in a repeating structure at constant intervals. The receiving device recognises the synchronisation pattern is being received at every interval and will set its own clock to match the intervals of the synchronisation pattern. The terminal can then decode the incoming data frames to obtain relevant information such as the control information or payload. Also inbuilt into the system is a feature that is called 'forward error correction' which is designed to compensate for a small percentage of lost data stream (which can occur if the user goes out of range). Scanning in Digital Two-Way Radio Systems 69 P25 terminals (discussed below) are able automatically to scan frequencies in a conventional two-way radio system. Transmissions between repeaters and terminals include embedded control messaging that allows for the late entry into conversations (such as talkgroup conversations) by scanning terminals. 70 TETRA terminals also automatically scan. However, TETRA terminals scan control channels rather than traffic channels. This occurs periodically to determine if a control channel with an improved signal strength can be identified. Prior to 26 July 2004 (one of the priority dates), the length of time it took automatically to scan frequencies in analogue systems was a well-known problem. Prior to that date, the known digital two-way radio systems provided little improvement on the length of time it took automatically to scan frequencies. De-keying and Re-keying in Digital Two-Way Radios 71 Similar to analogue repeaters, digital receivers have a hangtimer which prevents the repeater from de-keying immediately after a transmission. This ensures that the receiving user has sufficient time to respond to a communication before the repeater de-keys. 72 In conventional digital two-way radio systems, repeaters require a 'wake-up' message in order to re-key. The repeater's uplink continues to monitor the frequency so the repeater is able to receive transmissions from terminals. This allows terminals to transmit a wake-up message to the repeater, enabling it to re-key. Although the specific type of wake-up message differs between two-way radio systems, every digital system will look for a valid transmission in order successfully to re-key. 73 As previously discussed, terminals are able temporarily to maintain data synchronisation or reference timing during short periods of interference. A short period of interference has the same effect as a condition where a repeater initially de-keys. In both circumstances, the terminal will no longer receive any data from the repeater's downlink. As such, in both circumstances, the terminal will temporarily maintain data synchronisation without requiring data (such as the repeating synchronisation pattern) to be received from the repeater's downlink. 74 An issue which exists in conventional digital two-way radio systems is that communications could be lost when a repeater's downlink is initially deactivated. This can occur because of the inability of a receiving terminal to maintain reference timing in a temporary data synchronisation state. When this occurs, it is possible that the terminal transmitting a communication may not recognise that the repeater has de-keyed. This presents an issue because the terminal may continue to transmit communications which are then not repeated to the intended receiver. Multiple Access Methods 75 There are three well-known and generally accepted methods implemented to utilise the limited RF spectrum more efficiently in two-way radio wireless communications. These methods aim to increase the number of users communicating within a specific portion of the radio spectrum. They are: (a) frequency division multiple access ('FDMA'); (b) time division multiple access ('TDMA'); and (c) code division multiple access ('CDMA'). 76 CDMA was not used for two-way radio systems before 2004 and was instead used in cellular telecommunications systems. 1. Frequency Division Multiple Access (FDMA) 77 FDMA separates RF channels by frequency. For instance, for two-way radio communications, FDMA may split a 12.5 kHz channel into two, smaller, 6.25 kHz channels which communications can each be transmitted on. FDMA was introduced into digital two-way radio systems in the 1990s. It has been implemented into both digital and analogue two-way radio systems such as the P25 digital radio system. An illustration of FDMA channel splitting is this: 78 Using FDMA, a conversation occupies a whole channel exclusively, meaning there is one user and one conversation at a time per channel. To increase the number of channels it is necessary to increase the number of frequencies. However, it can be difficult and costly to obtain channel assignments from the regulator. For example, using FDMA, four users (each of whom wishes to communicate at the same time) would need access to four 6.25 kHz channels (which would be split from the two 12.5 kHz channels). 2. Time Division Multiple Access (TDMA) 79 TDMA was introduced in or around 1979 as a common multiple access technique for wired networks. It was first introduced to digital two-way radio systems in the 1990s and is still currently implemented into digital two-way systems. TETRA was the first system to implement TDMA in two-way radios. 80 TDMA separates RF channels into different timeslots while preserving the width of the 12.5 kHz channel. Timeslots are a defined period of time (usually a very short period of time) during which the sender's communication is transmitted. TDMA allows several users to share the same channel. As a user transmits, their communication will be inserted into a timeslot of a very short, fixed period (such as 50 msec or one twentieth of a second). Usually, a mobile station operating in repeater mode will be allocated to a timeslot by a repeater whereas a mobile station operating in direct mode is able to transmit in a free timeslot which is available on the frequency. 81 Users transmit in rapid succession which gives each user the impression that they have exclusive use of the channel and that their communication is being broadcast in real time. For example, in a two-timeslot TDMA system, two users can share one frequency at the same time. The distinction between FDMA and TDMA systems can thus be illustrated in the following way: 82 In a TDMA system, User 1 utilises the frequency for the first timeslot (slot 1 in the above diagram) then User 2 transmits for the next fixed period of time (slot 2). The channel then reverts back to User 1 who transmits for the next fixed period of time. The channel then reverts back to User 2 who transmits for the next time period and so on. The process occurs so quickly that neither user is aware that they are sharing a channel and neither experiences a delay in transmission. However, if more than two users wish to transmit, additional radio channels are needed. For example, in a two-timeslot TDMA system, four users who wished to communicate at the same time would require two 12.5 kHz frequencies. 83 TDMA introduced the ability to divide the physical channels (e.g. the 12 kHz channel) into logical channels. A logical channel is a channel which has the appearance and functionality of a channel but which is, at a technical level, actually made up of quite different constituent elements. So for example, a user could select a logical channel designated as channel 1. This logical channel consists of one slot on the transmit frequency and a corresponding slot on the receiving frequency. Although the communication is happening over two frequencies, those two frequencies constitute, so far as the user is concerned, a channel called '1'. 84 A half-duplex radio device cannot transmit and receive at the same time. However, using TDMA, such a device can constantly tune between the transmit and receive frequencies which has the effect of simultaneous transmitting and receiving for the user. This is possible for mobile stations operating in either repeater mode or direct mode. Conventional Two-Way Radio Systems 85 At a high level, there are two categories of two-way radio systems: conventional and trunked systems. A 'conventional system' uses a dedicated repeater and a fixed number of RF channels. The user may manually select which channel they want to listen to. If a channel is in use, a user must wait for the channel to be free before being able to utilise that channel. Such a system may be illustrated this way: 86 In this set up, users select a channel on which to transmit. However, only one user can transmit on each channel at one time. So, the second and third users on Channel 1 (represented pictorially above in the second and third rectangles) as well as the second user on Channel 3 (the second circle) would be required to wait for the first user to finish transmitting on the frequency before they could use the channel for communications. In contrast, the police user (the sole user of Channel 2) can transmit immediately. Importantly, in a conventional two-way radio system, users cannot make use of the other channels which may be available unless they manually tune to them. In the above example, for instance, the second or third user waiting to transmit on Channel 1 (the ambulance users) could not utilise Channel 2 to transmit once the police user has finished transmitting unless they re-tuned their device to Channel 2. 87 The number of users who can successfully access a conventional system therefore directly corresponds to the number of channels that are available. As a result, conventional radios often have dedicated channels for specific users or groups of users. If an agency such as a police station wishes to add an extra channel or talk path they are required to seek a channel assignment from the regulator. Trunked Systems 88 Trunking is not directly relevant to this case. However, one of the patents involves a concept known as 'pseudo-trunking'. In order to understand what pseudo-trunking is, it is necessary to understand trunking. 89 A different category of two-way radio system is known as a trunked system, which was developed in around the 1980s. Unlike conventional two-way systems, trunked systems do not require users manually to select the channel upon which they wish to transmit. Instead, trunked systems automatically allocate users to an available channel (that is, one which is not in use) and release the channel once the user has finished transmitting (thus allowing other users to be automatically allocated to it). As a result, trunked systems increase the number of users who can use the system by more efficiently allocating the frequency resources which are available. 90 In the above example involving Channels 1-3, for instance, in a trunked system the second or third user waiting to transmit on Channel 1 would be able to utilise Channel 2 to transmit once the police user had finished transmitting without needing manually to change channels. This decreases the likelihood of the user having to wait for an available channel, increasing the number of users that can transmit using the radio system in a period of time. 91 To do this, trunked systems work by having users transmit to what is called a 'control channel'. The control channel then allocates users to what are called 'traffic channels' on which they can communicate. Traffic channels can be shared between groups of radio users (or 'talkgroups' as explained above). An illustration of a trunked system is thus: 92 In Figure 8, the ambulance user could be allocated to Channel 1, both fire users could be allocated to Channel 2 and the police user to Channel 3. This means that members of the same talkgroup can share a traffic channel (and so share a frequency). Often, if one member of the talkgroup is transmitting a message (e.g. the first fire user), the other users (the second fire user) will be listening. This means the other users in the same talkgroup will not be using the channel to transmit at the same time. WELL-KNOWN DIGITAL RADIO SYSTEMS BEFORE JULY 2004 The MPT1327 Standard 93 One of the first trunked two-way radio systems was the MPT1327 Standard. This is a standard which was developed by the United Kingdom Ministry of Posts and Telecommunications in the mid-1980s. It is a hybrid digital/analogue radio communication system in that it transmits both data (to set up a call) and analogue voice communications. It includes a trunked system controller that retains information including a list of terminal devices that are subscribed to the network, a record of the location of the terminals subscribed to the network, and the configuration of repeaters connected to the network. Each repeater in the network is connected to the traffic system controller with several cables, including a data cable for the dedicated control channel and physical cables for each of the repeaters that have traffic channels. MPT1327 systems include 'sites' that each typically include several connected repeaters. One of the repeaters in each site operates as the dedicated control channel and the remaining repeaters are associated with the traffic channels. 94 Terminals connected to an MPT1327 network communicate with the dedicated control channel in order to set up and receive calls. Unless the system includes a time shared control channel, system users are typically allocated a traffic channel on the site that they are connected to in order to communicate with another system user. In a time shared MPT1327 system, the control channel can also be allocated as a traffic channel. Scanning in MPT1327 95 Terminals in an MPT1327 system automatically scan the control channels associated with repeaters in the network on a regular basis to determine if a site with increased signal strength is able to be located. To enable the automated scanning process, the terminals include a list of frequencies associated with control channels as well as associated repeater identifications in the network that are saved to memory in the terminal. 96 MPT1327 terminals typically included more frequencies saved to the memory to which the terminal is subscribed. For example, in the 2000s, Victoria was split into geographical regions such as city and country regions. In order to use multiple regions, the terminal needed to be a subscriber to repeaters associated with sites located in the multiple regions. If the terminal was not a subscriber to a repeater in a particular region, the trunked system controller would not allow the terminal to lock onto a control channel, even if the control channel was stored to memory within the scanning terminal. 97 The repeater associated with the control channel for each site transmits control messages on the control channel to perform an action, such as setting up calls. The control messages included information such as the identification of a source terminal, the identification of a talkgroup, the identification of a site and the identification of a repeater (i.e. the traffic channel). Examples of control messages which are used by MPT1327 systems include: (1) A Go To Channel Message ('GTCM'): The GTCM is transmitted by a repeater on the control channel to connected terminals to set up calls. It can be used to allocate a terminal to a particular talk channel, which can also be the control channel for systems that utilise a time shared channel (e.g. a channel that, at different times, is used as a control channel and a talk channel). The GTCM is referred to in Section 5.4 of the MPT1327 Standard. The GTCM includes the following information: (a) Destination identification or group identification; (b) Source identification; and (c) Channel information. (2) A Vote Now Message ('VNM'): On occasion, a repeater uses a version of the broadcast message to transmit a control message on the associated control channel to the terminals connected to the site associated with that repeater to instruct the connected terminals to scan for a frequency with a higher signal strength; and (3) A Short Data Message ('SDM'): SDMs have a specified size but could be used by service providers to transmit any form of data. For example, the SDM was used to send GPS location reporting messages as this information could be transmitted using the specified data size. SDMs were transmitted on the control channel. In order to allocate specific data to an SDM, users needed to make a request to the trunked system controller. 98 MPT1327 used fast frequency shift keying ('FFSK') to transmit data over the control channel. FFSK implements a technique that allows for digital data to be transmitted using an analogue signal. An electromagnetic carrier wave is used to carry the digital data over a distance and connect repeaters with terminals in remote locations. In FFSK, the repeaters transmit data on the control channel by modulating the carrier frequency between two discrete values. Each of the discrete values correspond to a zero and a one (the components of digital data). The terminals are able to receive and decode the digital data corresponding to control messages then perform the desired functions. De-keying in MPT1327 99 MPT1327 terminals are not able to communicate with each other in direct mode but use repeaters to transmit. Similar to conventional analogue two-way radio systems, the repeaters in trunking two-way radio systems (such as MPT1327) de-key when the downlink associated with the repeater is not in use (e.g. when the traffic channel is released). At the end of a transmission, terminals leave the traffic channel that was being used for a communication. A message is then sent to the traffic system controller, indicating that the conversation is complete. After certain conditions are met, such as after the expiration of a timer, the traffic system controller sends a message to the repeater associated with the traffic channel that is no longer in use and instructs the repeater to de-key. It is not clear to me how an MPT1327 repeater in such a configuration re-keys. APCO P25 100 APCO P25 is a set of digital two-way radio standards that were produced by the Association of Public Safety Communications International ('APCO') in the United States ('US') in the 1990s. P25 is an open architecture that defines a digital radio communications system for public safety organisations. P25 was implemented by manufacturers and organisations such as Motorola, Tait, Harris/MA-COM and Simoco. 101 The P25 standards define the interfaces, operation and capabilities of P25 radio systems. Before 26 July 2004, P25 systems were both conventional and trunked digital two-way radio communication systems that transmitted data using FDMA methods. These systems are now referred to as 'Phase 1 P25'. Phase 1 systems operate using a 12.5 kHz frequency bandwidth and use Continuous 4 Level FM ('C4FM'), a type of frequency shift keying ('FSK') modulation to transmit data. P25 systems implement a vocoder to encode speech (tone and audio level) into a digital data stream. 102 P25 transmissions include a link control ('LC') message that forms part of voice transmissions to provide signalling information to terminals. The LC message is referred to as an LC word in section 5.5 of the P25 FDMA Common Air Interface. Examples of LC words are shown in the P25 standards and include: (a) A message to specify the Link Control Word's content (LCF); (b) The manufacturer's identification (MFID); (c) Talkgroup identification (TGID); (d) Source identification (Source ID); (e) Destination identification (Destination ID); and (f) An emergency indicator. Scanning in P25 103 P25 terminals are able automatically to scan frequencies that are saved to memory in the terminals. P25 transmissions between repeaters and terminals included embedded control messaging that allowed for the late entry into conversations (such as a talkgroup conversation) by scanning terminals. For example, a sequence of bits provides frame synchronisation which allows for the messages which follow to be decoded. For P25 transmissions, frame synchronisation messages are located at the start of every voice and data transmission and within transmissions (spaced at 180 msec intervals as provided for in the P25 standards) to allow for late entry by terminals. Once a terminal has synchronised to a transmission, it is then able to determine if the transmission is relevant by interrogating the LC message, that is to say, the LC word. This might occur to determine if an LC message indicates that the transmission is for a talkgroup to which the scanning terminal is subscribed. 104 The LC word is included in the Logical Link Data Units (LDU1 and LDU2) that are transmitted during a voice call. In order to receive LDU1 and LDU2 while scanning, a P25 terminal needs to decode all of the data being transmitted, including the data associated with the error correction algorithm. This was a known limitation with P25 systems and meant that it was slow to lock onto a channel. 105 An additional associated limitation with P25 systems was that a P25 terminal required several messages within a data stream to be decoded and then interrogated for the required information (such as a talkgroup identification number or an emergency status bit). Thus, automatically scanning for incoming transmissions in a P25 system was a slow process as terminals were required to decode large parts of the data stream and perform error correction of the data to allow the terminal then to interrogate the data stream for conditional requirements before locking onto a particular channel. If the transmission was a voice call, most of the packets of data were allocated to the payload being transmitted and the address information would only be transmitted every ninth frame (being every 180 msec). This meant that terminals needed to wait until the relevant information (e.g. the emergency status bit or the talkgroup ID) was received and decoded before the terminal was able to make a decision with respect to remaining on a channel. As a result, P25 did not provide much improvement to the well-known scanning problem with reference to analogue systems. This was a well-known limitation of P25. De-keying and Re-keying in P25 106 P25 two-way radio systems can be used in conventional direct mode and repeater mode. Terminal devices also may include a button that allowed for users to toggle between the different modes. Similar to conventional analogue two-way radio systems, the repeaters in P25 systems keyed and de-keyed when the downlink associated with the repeater was not in use (such as when the talk channel is released). Also, similar to conventional analogue two-way radio systems, the repeaters in P25 systems on occasion included a timer to prevent the repeater from de-keying immediately after a transmission. TETRA 107 TETRA is a digital trunking system that was standardised by ETSI in the mid-1990s. It was first introduced commercially in the early 2000s. TETRA is a digital system that implements TDMA to transmit communications between terminals and repeaters. Each TDMA frequency of 25 kHz is separated into four timeslots to allow for several communications to take place on a single frequency. 108 TETRA systems implement a vocoder to encode speech into a digital data stream. TETRA terminals are able to communicate directly with one another, without using a repeater. This is referred to as direct mode operation. Devices which implement TETRA perform frame synchronisation to transmit communications. 109 TETRA is similar to MPT1327 in that it includes a dedicated control channel. However, unlike MPT1327, because the system implements TDMA, a single repeater can be used for both a control slot and multiple talk slots. This means one timeslot can be used to communicate control messaging and the remaining timeslots can be used to communicate voice and data between terminals. TETRA implements a form of phase-shift keying (differential quadrature phase-shift keying ('4DQPSK')) to transmit data between connected repeaters and terminals. Phase-shift keying is a method of conveying data by modulating the frequency. It is not necessary for the purposes of these reasons to explore the nature of phase-shift keying. However, similar to MPT1327, the repeater associated with the control channel for each site transmits on the control slot to perform actions such as setting up calls. As also occurs in MPT1327, the control messages include information such as the identification of a source terminal, the identification of a talkgroup, the identification of a site, and the identification of a repeater. Scanning in TETRA 110 Scanning in TETRA occurs on control channels, rather than on traffic channels. The scanning issues which existed in other systems, such as P25, still exist in TETRA. However, the use of control channels means it is not as noticeable to the user as the delays occur in the background. As a trunked system, in TETRA, the network is responsible for orchestrating scanning. As a user communicates on one channel, the network operates behind the scenes continually to scan for an alternative, improved channel. The issue of timing thus still applies to TETRA trunked systems but is far less relevant to users. Colour Coding in TETRA 111 Colour coding was first introduced in TETRA two-way radio systems. Colour coding is a system in digital mobile radios which allows for the separation of groups of users (such as different service providers or systems) who are sharing the same frequency or channel. Colour coding prevents radios from one group from mistakenly crossing into another group which uses the same frequencies and so stops interference within a channel. 112 The purpose of colour codes is to differentiate multiple receivers that are within a geographical area using the same frequency. Colour coding is assigned by the system administrator and differentiates each group by their colour code. Each colour code is represented by a number (e.g. red equals one). Colour coding information is contained within control messages. 113 Mobile stations can be programmed with multiple colour codes (one for each channel) but a repeater can only be programmed with one colour code. In order for a mobile station to access a certain repeater, it must be programmed with the colour code assigned to that specific repeater. For example, if there are two repeaters with overlapping coverage areas, and both are trying to use the same frequency, Repeater 1 will be assigned the colour red and Repeater 2 will be assigned the colour blue. If there was a third repeater, but it was far enough away from Repeater 1, then Repeater 3 could also be assigned the colour red and utilise the same frequency. If a mobile station wishes to utilise Repeater 2 for transmission, it will need to be programmed with the colour blue. This is illustrated in Figure 10: The Draft DMR Protocol 114 There is a document entitled 'Draft Agenda Narrowband TDMA DMR Protocol' which all parties referred to as the 'Draft DMR Protocol': Kuhrt-1 at §291. It is dated 26 April 2004. It describes a digital two-way radio system that implements TDMA methods. It is the precursor to the 2005 DMR Standard. The Draft DMR Protocol was discussed during a working group meeting at ETSI during the development of the DMR standards. Both Mr Kuhrt and Professor Rangan agreed that if a person had been tasked with designing a method for scanning in a digital two-way radio system in July 2004, that person would have located a copy of the Draft DMR Protocol in order to understand what had already been done in this area. WELL-KNOWN DIGITAL RADIO SYSTEMS BEFORE 28 JULY 2005 115 In the field, each of the above two-way radio systems (i.e. MPT1327, P25 and TETRA) were part of the CGK prior to 28 July 2005 (the priority date of the 960 Patent). In addition to those, by 28 July 2005 the ETSI DMR standards were well-known by those working in the field of two-way radio communications. DMR Standards 116 DMR is a digital two-way radio system that was standardised by ETSI in April 2005. It was originally developed to be a secure digital equivalent to traditional analogue transmissions and the conventional P25 two-way digital radio system. The purpose of the ETSI DMR standards was to standardise digital radios worldwide, to reduce channel interference, and to increase radio spectrum efficiency. Systems which operate using the ETSI DMR standards implement a vocoder to encode speech into a digital data stream. 117 The first ETSI DMR standard evolved from an earlier Digital Interchange of Information and Signalling ('DIIS') specification for a two-way radio system. DIIS, which ETSI also attempted to standardise, was developed in the early 2000s. However, DIIS was not embraced by the two-way radio community. Many of the principles from DIIS were then incorporated into the DMR standards. 118 DMR standard compliant systems operate using two-slot TDMA to transmit communications. That is, each TDMA frequency is separated into two timeslots to allow two communications to take place on a single frequency. DMR compliant systems can operate in either simplex or duplex mode meaning that mobile stations operate on either one or two frequencies. Duplex DMR compliant systems have one frequency for transmitting and a separate frequency for receiving (known as a frequency pair or physical channel). Thus use of TDMA in DMR compliant standards means that physical channels could be divided into logical channels. 119 Similar to previous digital and analogue two-way radio systems, the DMR standards allowed for direct mode communications between terminals. The purpose of this was to allow for systems that required less infrastructure because no repeater is required for direct mode communications, or for when a repeater is unavailable. WELL-KNOWN DIGITAL RADIO SYSTEMS BEFORE 3 OCTOBER 2008 120 Each of TETRA, P25, MPT1327and the DMR standards were part of the CGK by 3 October 2008 (the priority date of the 764 Patent). Mr Kuhrt gave evidence that he became aware in 2008, whilst working on a DMR compliant device, of a problem with two-way radios which implemented the DMR standards. This problem related to the operation of such devices in direct mode and reflected the fact that in direct mode it was not possible for both timeslots to be used at the same time by two separate users. INTERNATIONAL FIELD 121 Mr Kuhrt thought, and I accept, that in Australia by both July 2004 and July 2005 persons working in the field of two-way radio communications would have been familiar with the systems described above. He thought that this might not have been so in the US and Europe. He inclined to the view that those working in Europe would have been more familiar with the standards applying in Europe (MPT1327 and TETRA) whilst those in the US would have been more familiar with APCO P25. He thought that persons practising in the field in Australia would have been familiar with the standards in both Europe and the US since Australia was something of a green fields market (i.e. there was no local standard). I accept this evidence. 122 Having set out this general background it is now useful to turn to the three patents in suit. III THE PATENT TRIAL 123 Motorola is the patentee of three Australian standard patents: Number Title Abbreviation 2005275355 Method and system of scanning a TDMA channel 355 Patent 2006276960 Method and system of accessing a de-keyed base station 960 Patent 2009298764 Method of efficiently synchronizing to a desired timeslot in a time division multiple access communication system 764 Patent 124 Motorola alleges that from at least September 2013, Hytera and Hytera Australia have distributed in Australia by various means a range of DMR devices to the public without its licence. In the case of a subset of the Hytera devices Motorola claims that Hytera has infringed claims 1 to 6 and 10 of the 355 Patent. In relation to another subset of the Hytera devices Motorola claims that Hytera has infringed claims 1 to 5, 8 to 15, 17 and 18 of the 960 Patent. Finally, in relation to another subset of the Hytera devices Motorola claims that Hytera has infringed claims 2 and 3 of the 764 Patent. In relation to the Hytera devices, Hytera has since the commencement of these proceedings reprogrammed each of its DMR devices in an attempt to ensure that they do not infringe the three patents. Motorola says that this reprogramming effort has not achieved that outcome. There is also therefore a separate set of issues in relation to each patent about the status of the reprogrammed devices. IV THE 355 PATENT INTRODUCTION 125 The issues which arise in relation to the 355 Patent are: (a) the proper construction of claims 1 and 5; (b) whether the 355 Patent is invalid for want of an inventive step; (c) whether the 355 Patent is invalid for want of utility; (d) whether Hytera is liable for secondary infringement where an unreprogrammed base station is used with an unreprogrammed subscriber unit; (e) whether Hytera is liable for secondary infringement where a reprogrammed base station is used with an unreprogrammed subscriber unit; (f) if yes to (e), whether Hytera is entitled to rely upon a defence of standards essentiality; and (g) what the scope of injunctive relief should be. The Evidence 126 Motorola's evidence both as to validity and infringement of the 355 Patent was given by Professor Rangan. Hytera's evidence about the 355 Patent was given by Professor Viterbo (as to infringement), Mr Kuhrt (as to validity) and Mr Grimmett (as to standards essentiality). Professor Rangan 127 Professor Rangan is a Professor of Electrical and Computer Engineering at New York University. Over the past twenty years he has been engaged in industry research and development at Qualcomm, Microsoft, Bell Laboratories and others. He was appointed Associate Professor at New York University in 2010 and Professor in 2018. He also has substantial experience in technology standardisation and source code writing and review. Professor Viterbo 128 Professor Viterbo is a Professor of Electrical Engineering and the Associate Dean of Graduate Research for the Faculty of Engineering at Monash University. He completed a PhD at Politecnico di Torino between 1992 and 1995, producing a thesis relating to coding for wireless telecommunications. Since about 1990, Professor Viterbo has worked for various organisations including the European Patent Office, Politecnico di Torino, Telecom Italia Labs, AT&T Labs, the University of Calabria and Monash University. He has considerable source code experience and can program in and understand the programming languages of C, C++ and Matlab. He has also been involved in projects relating to the development of technical standards. Mr Kuhrt 129 Mr Kuhrt is an electronic engineer. He completed a Bachelor's degree in Engineering (Electronics) at Swinburne University of Technology in 1984. Since that time, Mr Kuhrt has worked in various positions for Hewlett Packard, Philips Communications, Simoco Pacific, TMC Radio, Simoco Group and, most recently, Pacific Wireless Communications. Throughout his career, Mr Kuhrt has acquired substantial experience in designing and implementing two-way radio telecommunications systems. He has specialist knowledge of relevant telecommunications standards and the hardware, software and production requirements for two-way radio systems. Mr Grimmett 130 Mr Grimmett is a Technical Director. He completed a Bachelor of Science in Computer Science at Coventry University in 1992. Since leaving university, Mr Grimmett has worked in various roles, including as a software engineer, for four company groups: Mobicom (which became Simoco), Alstom Automation, Simoco, Experian and Pyronix. He has 20 years of experience working in the field of private mobile radio communications and possesses expertise in the design, development and deployment of analogue and digital radio technologies. As a member of the Digital Mobile Radio Association since 2010, Mr Grimmett has been involved in developing proposals for the improvement and development of the ETSI DMR standards (telecommunications standards of relevance to this proceeding which will be discussed in due course). Description of the Patent 131 The 355 Patent is entitled 'Method and system of scanning a TDMA channel'. It has a priority date of 26 July 2004. The patent describes the field of the invention as relating generally to 'wireless communications systems and more specifically to scanning in a time division multiple access (TDMA) system'. The patent describes the background of the invention in these terms: A wireless communications system may generally comprise a set of "subscriber units," typically subscriber units are the endpoints of a communication path, and a set of "base radios," (also known as "repeaters") typically stationary and the intermediaries by which a communication path to a subscriber unit (SU) may be established or maintained. One such type of system is a time division multiple access (TDMA) communication system where the radio medium (or RF frequency) is divided into time slots to carry the communications of the system. Because the communication system carries many communications at one time, a subscriber unit may want to monitor other communications in the system. Scan is a feature that allows a subscriber unit to monitor other communications in the system. SUs of the wireless communications system utilize a feature termed "scan" where an SU locks on to specific RF frequencies in a preprogrammed list in the SU. The RF frequencies in the scan list may be associated with more than one wireless communications system. For example, an SU may have RF frequencies from the Schaumburg fire department and the Rolling Meadows fire department in its scan list. If the preprogrammed scan list is very long and has many RF frequencies, then the scan feature takes a long time. Further, in the usual case, when many of the RF communications are normally of no interest to the scanning SU, the scanning SU spends a lot of time listening to communications that are of no interest to it. For example, this occurs when an RF frequency is included in the preprogrammed scan list, but the current communication is addressed to a SU or group of SUs that are of no interest to the scanning SU. Accordingly, there exists a need for scanning a TDMA channel which improves the amount of time that an SU spends scanning. 132 A summary of the invention is then given in these terms: According to one aspect of the present invention there is provided a method for scanning a TDMA channel by a subscriber unit in a wireless communications landscape, wherein the subscriber unit is operationally connected to at least one base radio over a plurality of channels, the method including the steps of: locking onto a channel of the plurality of channels by the subscriber unit wherein a subset of the plurality of channels is preprogrammed in a list in the subscriber unit; transmitting from at least one base radio a control message to the subscriber unit wherein the control message has a first information which informs the subscriber unit of activity present on the channel of the plurality of channels; receiving and decoding the control message for the first information by the subscriber unit; and if the first information indicates that activity is present on the channel of the plurality of channels, then determining whether the activity is of interest to the subscriber unit by comparing a second information in the control message with a third information preprogrammed in the subscriber unit and if the activity is of interest to the subscriber unit, then remaining on the channel of the plurality of channels to receive the activity present on the channel. According to a further aspect of the present invention there is provided in a TDMA system whereby the TDMA system includes a plurality of subscriber units and a plurality of base radios, a method for scanning, the method including the steps of: locking onto a channel preprogrammed in a list of a subscriber unit whereby the channel carries activity on one timeslot of the TDMA system; receiving an activity update message from a base radio of the plurality of base radios wherein the activity update message indicates in a first information the activity on the channel and indicates in a second information at least one characteristic of the activity on the channel; determining whether the activity is of interest to the subscriber unit by comparing the at least one characteristic with preprogrammed third information in the subscriber unit; and if the activity is of interest, then remaining on the channel to receive the activity; otherwise moving to the next channel in the list. 133 As will be seen, a significant issue which divides the parties is the relationship between the invention disclosed in the claims and the invention which appears in the detailed description of the invention in the body of the specification. Under the heading 'Brief Description of the Figures' there appears references to three figures in these terms: An illustrative embodiment of the invention is now described, by way of example only, with reference to the accompanying figures in which: FIG. 1 is a block diagram of an example wireless communications landscape in accordance with an embodiment of the invention. FIG. 2 is a flow diagram of an example method for providing channel access for voice transmissions. FIG. 3 is an example of a specific Common Announcement Channel message called an Activity Update. … 134 The three figures are then explained in the remaining body of the specification under the heading 'Detailed Description'. Figure 1 is as follows: 135 So far as this case is concerned, little controversy attends Figure 1. It is described in these terms at p 2 line 18 to p 3 line 20: Referring now to FIG. 1, there is shown an example of the method and apparatus of the present invention as it may be employed and incorporated into a typical wireless communications landscape 100 having system 100, system 120, and system 130. The illustrated example has three systems 110, 120, 130 whereby a system is comprised of a multiplicity of communication resources of RF frequencies, base radios (BRs) and subscriber units (SUs) optionally managed by system controllers (not shown) whereby the SUs send and receive communications with BRs (also known as "repeaters"). System 110 comprises a plurality of cells, each with a BR 3, 5, 7, 9, 11, 13 typically located at the center of the cell, and a plurality of SUs 12, 14, 16, 18, 20, 22 all of which are communicating on RF frequencies assigned to system 110. The SUs 12, 14, 16, 18, 20, 22 in system 110 may include all the RF frequencies associated with the BRs 3, 5, 7, 9, 11, 13 in system 110 in their preprogrammed scan lists. System 120 comprises a plurality of cells, each with a BR 26, 28, 30 typically located at the center of the cell, and a plurality of SUs 34, 36, 38 all of which are communicating on RF frequencies assigned to system 120. The SUs 34, 36, 38 of system 120 may include all the RF frequencies associated with BRs 26, 28, 30 in their preprogrammed scan lists. Further, SU 36 may include RF frequencies associated with the BRs in system 110 and with the BR in system 130 since the SU 36 is sufficiently close to all three systems 110, 120, 130. System 130 comprises a cell with a BR 24 and SUs 32, 40 all of which are communicating on RF frequencies assigned to system 130. Further, BRs 3, 13, 24, 28 may all be operating on the same RF frequency, but using a different color code since the BRs are separated by great geographical distance. A BR preferably comprises fixed equipment for communicating data/control and voice information to and from the SUs for facilitating communications between the SUs in the wireless communication landscape 100. A subscriber unit (SU) preferably comprises mobile or portable devices (such as an in-car or handheld radios or radio telephones) capable of communicating with a BR using time division multiple access (TDMA) or time division duplex (TDD) techniques as further described herein, in which specified time segments are divided into assigned time slots for individual communication. As is known in the art, each RF frequency in the system carries time slots whereby each time slot is known as a "channel." Thus, for the BRs shown in FIG. 1, each BR has two channels associated with the coverage area. 136 The description then turns to an illustrative embodiment of the invention. The first part of this is at p 3 line 21 to line 29: In an illustrative embodiment of the present invention, the wireless communications landscape 100 assumes a two slot TDMA communications system; however, other slotting ratios may be used in the TDMA communications system and still remain within the spirit and scope of the present invention. In an illustrative embodiment, the SU determines time slot numbering by decoding a TDMA channel field in a Common Announcement Channel (CACH) burst whereby the CACH burst is used for signalling information in the wireless communications landscape 100. In the illustrative embodiment of a two slot TDMA communications systems, the CACH burst is common to timeslot 1 and to timeslot 2. 137 The priority date for the 355 Patent is 26 July 2004. By this time, the DMR Standard had not yet come into effect and would not come into effect until 2005. That standard prescribed a two timeslot TDMA system. The illustrative embodiment proceeds on the same basis. An important aspect of this paragraph is its reference to the Common Announcement Channel ('CACH') burst. The CACH burst is used for signalling information and, in the illustrative embodiment, is common to both channels. Later in the description it becomes important to know this fact – the illustrative embodiment proceeds on the basis that the CACH burst is the same for both channels. An implication of this, borne out later in the description, is that the CACH burst carries signalling information for both channels. 138 The description then continues at p 3 line 30 to p 4 line 9: As is known in the art, "color code" is a common identifier used by a group of SUs which utilize the same BR. For example, as shown in FIG. 1, SUs 12, 14, 22 are in one color code because they utilize the same BR, namely BR 9. Further, a color code field may be present in an embedded signaling message and a general data burst to provide a means of addressing a radio network or a specific repeater so that cochannel interference may be rejected. Further known in the art, a "talkgroup" is a group of SUs that share an RF frequency and timeslot and have the same color code. In an illustrative embodiment, a talkgroup is identified by a 16-bit talkgroup identifier (TGID and an individual subscriber unit is identified by a 24-bit subscriber unit identifier (SUID). Thus, in an illustrative embodiment, SUs that share a color code are further subdivided into talkgroups so that SUs in one talkgroup do not hear SUs in another talkgroup. 139 This accords with the discussion of colour coding set out above in Chapter II. Important concepts are the ideas of the Talkgroup Identification ('TGID') and Subscriber Unit Identification ('SUID'). It will be noted that in the illustrative embodiment, these are 16 bit and 24 bit fields respectively. As will be seen later in the discussion of the CACH burst, the length of the SUID and TGID are important elements of the debate between the parties. 140 The description then continues at p 4 line 10 to line 21: As used herein, the terms "communication" and "transmission" are used interchangeably and refer to contiguous TDMA bursts emanating from one radio in one timeslot. As such, transmissions may generically refer to voice, data or control information relating to the wireless communications landscape 100. The term "call" refers to related voice transmissions between SUs in the wireless communications landscape 100. As is known in the art, the term "burst" refers to the smallest standalone unit of a TDMA transmission. In an illustrative embodiment, for a burst found in a Motorola Low Tier Digital system, a defined transmission is 216 bits of payload and 48 bits of synchronization or embedded signaling. The defined transmission takes 27.5 msec to transmit and may be followed by 2.5 msec of guard time or the CACH burst. Thus, a "burst" in such a Motorola Low Tier Digital system is 30 msec. 141 Again, this is important for some of the disputes between the parties. The defined transmission used in the illustrative embodiment is 264 bits in length. It takes 27.5 msec to transmit. It is followed by a period of 2.5 msec which can be used as guard time or for a CACH burst, it being recalled from the above that the CACH burst is used for signalling information and is transmitted on both slots 1 and 2. The total burst is therefore 30 msec. A little later in the description there is a discussion of a particular kind of CACH message known as an 'activity update message' which is transmitted by means of four CACH bursts: page 6 line 24. What this means is that the activity update message is transmitted in the last 2.5 msec in each of four 30 msec bursts. It is not clear from the description at this stage whether these bursts are successive or whether other signalling information is conveyed by means of the CACH bursts. Later in the description, however, it becomes apparent that more signalling information in the form of seven CACH bursts, known as the full LC message, also utilise this 2.5 msec portion. I will return to the activity update message shortly, but it may be noted that, as Professor Rangan confirmed at T806.1-4, in the illustrative embodiment, the activity update message is itself 28 bits in length: MR BURGESS: Thank you, Professor. And the activity update message described in the body of the 355 patent is 28 bits in size; correct? PROF RANGAN: I believe that's correct. 142 It may be surmised from Figure 3 that each of the four CACH bursts occurs as the last 2.5 msec of the burst, that three of the four bursts contain 8 bits, and that one of the bursts contains 4 bits: 143 Very important also is the fact recorded at p 6 line 24 to 27 that the activity update message (transmitted by means of the four CACH bursts) is 'used to assist in identifying whether there is an active transmission (also termed "activity") on the channel'. It also 'provides information that indicates whether the scanning SU should dwell on the channel or should resume scanning'. Jumping ahead a little, determining that there is no active transmission on the channel would be a good reason for resuming scanning. But even if there is activity on the channel, the information contained in the activity update message may indicate to the subscriber unit that the activity is not of interest to it. That observation will in due course feed into the question of the meaning of some of the claims. Part of the controversy between the parties concerns the nature of the information contained in the activity update message. For present purposes it will be seen, however, that the illustrative embodiment proceeds on the basis that the activity update message both indicates whether there is activity on the channel and also provides unspecified (at this stage) information to determine whether to 'dwell' on the channel or move to the next channel. The word 'dwell' does not appear in the claims and prefigures one of the debates between the parties which concerns whether the decision to dwell is a permanent decision or whether the subscriber unit, once confronted with further information, might decide to stop dwelling on the channel and move on to scanning for the next channel. Hytera's construction case is that this is not permissible. 144 The description then continues to discuss the nature of scanning at p 4 line 22 to 28: In an illustrative embodiment, a scan is performed in at least one of three situations: 1) when the SU powers on where the receiver automatically changes "channels" in a set order with a list preprogrammed in the SU, 2) when a user of the SU manually taps a button or turns a dial to manually step through frequencies preprogrammed in the SU, and 3) when a user of the SU sets the SU to scan mode where the receiver automatically changes frequencies in a set order with a list preprogrammed in the SU. 145 At p 4 line 29 to p 5 line 14, an important connection is made, in the case of the illustrative embodiment, between scanning and the concept of a characteristic of a communication: Further, there may be different types of scanning that a SU performs. An SU may be programmed to perform scan based upon a characteristic of the active transmission such as whether the active transmission is voice, data, group, individual, emergency, and non-emergency. For example, a scanning SU may be programmed to scan for channels only carrying voice transmissions. Further, a scanning SU may be programmed to scan for channels only carrying data transmissions. Further yet, a scanning SU may be programmed to scan for channels carrying voice transmissions that are addressed to individual SUs and not voice transmissions that are addressing talkgroups. Further yet, a scanning SU may be programmed to scan for channels carrying data transmissions that are addressed to individual SUs and not data transmissions addressing talkgroups. Another example, a scanning SU may be programmed to scan for channels carrying any emergency transmissions regardless of the group that the active transmission is associated with. Yet another example, a scanning SU may be programmed to scan for channels carrying only non emergency transmissions regardless of the group that the active transmission is associated with. As can be imagined, there are numerous examples combining the characteristics to program a scanning SU to only search for specific active transmissions and the examples listed above are only illustrative and not exhaustive. 146 There appear to be six characteristics discussed but in fact they may be grouped into three sets of pairs each member of which is complimentary. For example, a communication is either a voice communication or a data communication. It is either addressed to a group or to an individual. It is either an emergency transmission or it is not. These binary pairs and their susceptibility to being represented by bits is a matter to which it will be necessary to return. As the passage describes, the scan function can be set so as to scan for channels which are only carrying voice transmissions. Or it could be set to scan for communications which are both voice transmissions and addressed to an individual subscriber unit. By doing this, the scan function is able to exclude communications which are not of interest to the subscriber unit. For example, if it is set to scan for voice communications addressed to an individual subscriber unit, the fact that the communication is not of that nature can be discerned from the characteristics. I return below to how the illustrative embodiment in fact does this. 147 The description then introduces Figures 2A and 2B which are important for the debate between the parties. Between the two figures is a single flow chart. Figure 2A is concerned with how the illustrative embodiment processes a voice transmission and Figure 2B deals with a data transmission. They are as follows: 148 It will be seen that Figure 2A is connected to Figure 2B at Block 226. The explanation of Figure 2A occupies much of the specification. It begins at p 5 lines 15 to 30: Referring to FIG. 2, in operation, an SU performs the function of scanning by tuning to a specified channel enumerated in a scan list preprogrammed in the scanning SU (Block 202). As is known in the art, a channel is also known as a "personality" where a personality is typically a radio frequency (RF) with additional qualifying information. The scanning SU pauses on the selected personality for a specified time period and tests whether an RF carrier is detected (Block 204). In one embodiment, a scanning SU which is programmed to scan only for voice transmissions pauses for 25 msecs before continuing. As is known in the art, the specified time period depends upon the type of signal expected to be received by the scanning SU such as analog voice, FDMA digital, and TDMA digital. Further, the specified time period may depend upon the type of scan being performed. As mentioned above, the type of scan may depend upon a characteristic of the active transmission such as whether the active transmission is voice, data, group, individual, emergency, and non-emergency. For example, if the scanning SU is programmed to scan for channels only carrying data transmissions, then it may wait for 65 msecs before continuing. 149 The significance of the time delays was not something which the evidence touched upon and appears immaterial to the debates between the parties. It is not obvious to me why the pause times might vary depending on the nature of the signal expected to be received or why the description includes reference to FDMA and analogue systems when it is concerned only with TDMA systems. In any event, this does not matter. 150 The description then continues at p 5 line 31 to p 6 line 12: If an RF carrier is present, then the scanning SU remains on the selected personality and performs synchronization (Block 206). In an illustrative embodiment, performing synchronization between the BR and the SU involves waiting a predetermined period of time for detecting a time slot synchronization signal. The time slot synchronization signal is a 48 bit (also known as 24 symbols) frame sync word. The time slot synchronization signal identifies the center of a TDMA burst and the type of communication present on the TDMA channel so that a receiver in the scanning SU may be able to receive transmissions on the TDMA channel. Performing synchronization is complete upon detection of the time slot synchronization signal within a predetermined period of time. In one embodiment, the scanning SU must receive the time slot synchronization signal within 335 msecs. If the communication between the SU and the BR is in synchronization or the SU is successfully able to perform synchronization between the BR and the SU, then the SU determines a color code for the active transmission on the channel (Block 208). 151 Synchronisation is, as I explained above in Chapter II, an essential element of TDMA architecture. The reference to colour code at p 6 lines 11 to 12 harks back to the explanation of colour codes at p 3 line 30 (discussed above). The description then continues at p 6 lines 13 to 20: As is known in the art, regardless of whether a carrier is detected (Block 202), a scanning SU that receives a frame synchronization message further decodes the personality. Thus, if frame synchronization is performed, then the scanning SU remains on the personality an additional amount of time to determine whether there is a match of the color code for the active transmission on the channel (Block 208). If there is not a match of the color code (Block 208), frame synchronization (Block 206), or carrier detect (Block 204), then the scanning SU tunes to the next channel in the preprogrammed scan list (Block 220). 152 At least for the illustrative embodiment, a failure to establish the presence of a carrier on the RF, or if having done so, if frame synchronisation is not achieved or, if it is, if the colour associated with the communication does not match the colour of the subscriber unit, then it moves to the next channel. If all of those matters are, on the other hand, satisfied then it follows that the subscriber unit has detected a carrier signal, has achieved frame synchronisation, and has determined that the subscriber unit and the base radio sending the communication are part of the same colour group. In this circumstance, the illustrative embodiment then decodes what it refers to as an 'activity update message'. This appears from p 6 lines 21 to 27: If there is a match of the color code for the active transmission on the channel, then the scanning SU remains on the channel and decodes a specific CACH message termed an "activity update" message 300 (Block 210). In an illustrative embodiment, the activity update message 300 is a 4-burst CACH message used to assist in identifying whether there is an active transmission (also termed "activity") on the channel. The activity update message 300 provides information that indicates whether the scanning SU should dwell on the channel or should resume scanning. 153 The nature of the four CACH bursts is described a little later. The description then continues to describe the activity update message used in the illustrative embodiment in more detail. It does so by reference to Figure 3 which is extracted above at [142]. 154 This diagram is not easy to follow. However, it is reasonably clear that its four horizontal layers represent the four CACH bursts which, as I have said, are either 8 or 4 bits in length (or 2.5 msec). Although, as will shortly be seen, the description of the illustrative embodiment explains the lower three horizontal layers in terms which are clear, this is not so in relation to the first layer. It is not clear, for example, what the '4-BURST CACH MSG. OPCODE (4 bits)' is. Since it is an opcode, I am inclined to conclude that it is an instruction to the subscriber unit to receive the following three CACH bursts as data. The view that the opcode is part of an instruction set is supported by an observation appearing later in the description where it is contrasted with the balance of the activity update message which is said to be data ('besides the opcode field 302, the rest of the activity update message 300 is considered to be data': p 7 lines 19 to 20). 155 Returning then to the explanation of Figure 3, the description continues in these terms at p 6 line 28 to p 7 line 14: As shown in FIG. 3, the activity update message 300 includes an activity field 304, 306 specific to each timeslot that indicates whether the channel is presently supporting a call or transmission on either of the timeslots. For example, as shown in FIG. 3, one-bit field 304 indicates whether timeslot one is supporting a call or transmission and one-bit field 306 indicates whether timeslot two is supporting a call or transmission where a value of "0" indicates that the timeslot is not active and "1" indicates an active transmission on the time slot. If there is an active transmission on the timeslot (Block 211), then the scanning SU determines whether the active transmission is of interest to the scanning SU. Otherwise, the scanning SU moves to the next personality in the preprogrammed scan list (Block 220). Further, if an active transmission is present, then the activity update message 300 also has other information to identify the type of transmission. For example, the transmission may be voice, data, an emergency, talkgroup or individual transmission as shown in FIG. 3. As shown in FIG. 3, a voice or data transmission is signaled by one-bit fields 314, 318 where a value of "0" indicates that the active transmission is a voice transmission and "1" indicates that the active transmission is a data transmission. As shown in FIG. 3, an emergency or non emergency is signaled by one-bit fields 312, 316 where a value of "0" indicates that the active transmission is a non emergency transmission and "1" indicates that the active transmission is an emergency transmission. 156 There is much which is important in this passage for an understanding of what the dispute between the parties is. The first matter to understand concerns the second row which contains 8 bits marked as A1, E1, D1, I1, A2, E2, D2 and I2. It will be recalled that the illustrative embodiment concerns a two timeslot TDMA system. The first four bits concern timeslot 1 and the second four concern timeslot 2. The bits A1 and A2 (the 'activity indicators') indicate whether activity is present on timeslot 1 and 2 respectively, 1 signifying activity and 0 signifying no activity. The bits E1 and E2 signify the presence of an emergency broadcast if set to 1 or no emergency broadcast if set to 0. The bits D1 and D2 signify a data communication if set to 1 or a voice communication if set to 0. The bits I1 and I2 indicate whether the transmission is intended for an individual if set to 1 or a talkgroup if set to 0. 157 It will be seen from the nature of some of these fields that the decoding of the four burst CACH message and the rendering of these 8 bits is unlikely, except perhaps in the case of the emergency bit, to provide enough information to the subscriber unit to ascertain that the communication to which the activity update message relates is, in fact, a communication which the subscriber unit wishes to receive. What most of them do is to operate either in a negative fashion to indicate that the communication is not one in which the subscriber unit is interested, or alternatively, in a provisional fashion, to indicate that the communication could be of interest. For example, if the activity bit is set to no activity then the subscriber unit may move on to the next channel. Similarly, if the subscriber unit is not interested in data transmissions the fact that the D1 bit is set to 1 provides the subscriber unit with sufficient information to know to move on to the next channel. 158 Because it will be relevant when it comes to the claims, it is to be noted also that the activity bit has the consequence that the subscriber unit will not continue scanning on a timeslot which is indicated to be inactive. This activity indicator is important for the debate between the parties. Also important are the other bits in the second row in Figure 3 which, in various ways, signify the presence or absence of communications with certain characteristics. It is possible to think of these separate signifiers as a form of information. It is also possible to think of the activity indicator as a form of information. As will be seen in due course, the claims in the 355 Patents speak in terms of a 'first information' (signifying whether activity is present on a timeslot) and the existence of a 'second information' (which signifies whether the communication is of interest to the subscriber unit). 159 Another matter worth noting at this stage is an implication flowing from the inclusion of the activity update message in the 2.5 msec interval at the end of each 30 msec burst. Plainly enough, the activity indicator is useful for saving the subscriber unit from wasting time scanning an inactive timeslot. The other bits (E, D and I) perform a similar although less dramatic purpose. In terms of the signal architecture in the illustrative embodiment, the 2.5 msec is used not just to signal activity but also to convey other information about the communication. Whether this is a feature of the invention as claimed, as opposed to a feature of the illustrative embodiment, is an issue between the parties. 160 The description then continues at p 7 lines 19 to 23: Further, besides the opcode field 302, the rest of the activity update message 300 is considered to be data and is populated by information from a full Link Control (LC) message for a voice transmission and from a data header for a data transmission. For example, the emergency one bit fields 312, 316, the group one bit fields 320, 322, and the addresses 308, 310 are recovered from the LC message or a data header. 161 Here will be seen the reference to the opcode not being data which I have mentioned above. It appears from this that in the illustrative embodiment, the data in the activity update message is populated by information from a full LC message for a voice transmission or from a data header for a data transmission. The description does not explain at this point what a full LC message or a data header is. However, it would appear that it contains at least all of the information which is in the activity update message. I return to the topic of the full LC message shortly. 162 The description then continues at p 7 line 24 to p 8 line 2: If an active transmission is present and if the scanning SU is programmed to check the active transmission (Block 222) for a transmission addressed to a SU of interest, then the scanning SU determines whether the active transmission is addressed to a SU of interest (Block 212). Otherwise, the scanning SU checks to see if the scanning SU is programmed to receive the active transmission (Block 224). For example, the scanning SU may be programmed to receive all emergency calls regardless of identification (ID) of the source or destination of the active transmission. If the active transmission is of interest to the scanning SU, then the speaker is unmuted and audio is rendered to the user of the scanning SU (Block 218). Otherwise, the scanning SU moves to the next personality in the preprogrammed scan list (Block 220). 163 This passage and Blocks 222, 212 and 224 are, at first blush, a little obscure. However, they are important and it is necessary to dispel the obscurity. First, it will be noted that Block 222 is only reached after it has been determined at Block 211 that there is an active transmission on the timeslot. Translated back into Figure 3, this means that bit A1 (or if timeslot 2 is involved, bit A2) has been set to 1. Secondly, Block 222 reflects the programming of the subscriber unit. It will either be programmed to check for identification or it will not. Thirdly, if is programmed to check for identification, then the subscriber unit proceeds to Block 212. Block 212 is further expanded upon in the following paragraph. Fourthly, if the subscriber unit is not programmed to check for identification then it proceeds to Block 224 and checks to see if the transmission is nevertheless of interest. This it does by checking the remaining bits in the same row of Figure 3. As the description notes, if the subscriber unit is programmed to receive emergency transmissions and the emergency bit is set in the second row then the speaker is unmuted and the audio rendered (Block 218). 164 It is then necessary to say a little more about the process of identification if the subscriber unit has been programmed to receive transmissions addressed to a subscriber unit of interest. As I have explained above, the process of identification does not take place at Block 222 which instead just reflects a programming choice which has been made in the subscriber unit. If it is programmed to see if the transmission is from a subscriber unit of interest, then the actual process of identification occurs at Block 212. Of this process the description then continues in these terms at p 8 lines 3 to 15: Further yet, if an active transmission is present, the activity update message 300 also identifies the SUID or TGID of the active transmission. As shown in FIG. 3, the identification field 308, 310 is an 8-bit hashed field as shown in FIG. 3. Further, because there are a limited number of bits in the activity update message 300, the ID field 308, 310 is hashed. For example, if the active transmission on timeslot 1 is directed to SU 16 and SU 16 is identified by a 24 bit SUID, then the ID field 308 is hashed to 8 bits. Another example is an active transmission on timeslot 2 directed to an SU in a talkgroup, e.g. SU 12, where the talkgroup is identified by a 16 bit TGID. Thus, the ID field 310 is hashed from the TGID of 16 bits to 8 bits. As is known in the art, there are many algorithms that can be used to perform the function of hashing and one such well known algorithm is a CRC-8 checksum with a generating polynomial of g(x)=x8+x2+x+1. With an input of a 16 bit TGID or a 24 bit SUID, the output is an 8 bit CRC hashed ID field 308, 310 as shown in FIG. 3. 165 This takes one back once again to Figure 3. The third and fourth rows of Figure 3 are 8 bits in length. The bottom row is for Channel (timeslot) 2 and the second from the bottom row is for Channel (timeslot) 1. As has previously been noted, the activity update message is sent across both timeslots. To that extent it contains redundant information, for the information in bits b0 to b3 concern timeslot 2 in the row which indicates the characteristics of the transmission whilst those at b4 to b7 concern timeslot 1. Similarly, the two 8 bit 'hashed IDs' are each only relevant to one of the two timeslots. As above, the SUID and TGID are shorthands for 'subscriber unit ID' and 'talkgroup ID'. 166 The immediate problem facing the illustrative embodiment is that the SUID is 24 bits long and the TGID is 16 bits long. The two ID fields in the activity update message are, however, only 8 bits long. The passage effectively teaches that the SUID and TGID are to be subject to a compression algorithm which will reduce them in length to an 8 bit structure. The expression 'hashed ID' therefore refers to a compressed form of the SUID and the TGID. As will be seen shortly, an ID match at Block 212 does not definitively determine that the transmission is for the subscriber unit of interest. As was accepted by all parties, this is because the compression algorithm can cause more than one subscriber unit identified by a 24 bit SUID to have the same 8 bit hashed ID (a similar problem affects subscriber units identified by a 16 bit TGID). It is therefore necessary for a complete ID check to be done. This is apparent from Blocks 213, 226 and 214 (if the transmission is a voice transmission) and from Blocks 213, 226 and, in Figure 2B, Blocks 228, 230, 232 and 234 (if the transmission is a data transmission). 167 The description returns to these matters shortly, but before it does so it notes that the activity update message may be received before the colour code of the active transmission is known. This it says at p 8 lines 16 to 22: As is known in the art, the activity update message 300 may be received before knowing the color code for the active transmission on the channel. In any case, knowing the color code for the active transmission on the channel and whether it matches the color code of the scanning SU is important to deciding whether to stop scanning or not. As mentioned above, if there is not a match of the color code (Block 208), then the scanning SU tunes to the next channel in the preprogrammed scan list (Block 220). 168 Returning then to the process of identification, once it has been determined from the hashed IDs in rows 3 and 4 of Figure 3 that the subscriber unit the transmission is addressed to is of interest, the subscriber unit then asks whether the transmission is voice or data (Block 226). This it can do from the D bits in row 2 of Figure 3 which, it will be recalled, provide that information. So much is stated at p 8 lines 23 to 25: If the ID field 308, 310 of the activity update message 300 matches the SUID or TGID of the scanning SU (Block 212), then the scanning SU determines whether the active transmission is voice or data (Block 213). 169 It is useful to pause at this point and to note what might not otherwise be obvious: that the flow chart in Figure 2A therefore uses all four of the characteristic bits in row 2 of Figure 3. The activity bit ('A bit') is used at Block 211 to determine whether there is activity on the channel or not. The emergency bit ('E bit') is used at Block 224 to determine, if the transmission is not directed to a subscriber unit of interest, whether it is an emergency transmission or not and, if it is an emergency transmission, unmutes the speaker. The individual bit ('bit I') is used at Block 224 to determine whether the transmission is directed to an individual or a talkgroup. Finally, the data bit ('D bit') is used at Block 226 to determine after identification at the level of the hashed IDs has occurred, whether the transmission is voice or data. The illustrative embodiment therefore deploys all four of the characteristic bits in the second row of the activity update message as well as the hashed IDs (and does so in respect of both timeslots). 170 This understanding of the invention depicted in Figure 2A is important for the construction issue between the parties. The language of claim 1 (to which I will return in more detail shortly), requires the invention to determine whether the activity is of interest to the subscriber unit and if it is, to remain on the channel to receive the activity. Hytera submits that the determination of whether the activity is of interest can happen only once and cannot be, as Block 212 suggests it can be, provisional. Put another way, under Hytera's construction, the subscriber unit cannot decide that the transmission might be of interest and then carry out further acts to determine whether it actually is of interest. It will be apparent from what has been said in the preceding paragraph that in Figure 2A, this is not what is happening except in the case of an emergency transmission. In that case, the determination that the transmission is an emergency transmission, because the E bit is set to 1, leads the subscriber unit to receive the audio. However, leaving aside the position of the activity bit itself (which fits into claim 1 in a different way), all of the other information in the activity update message leads to determinations which are at best provisional. Thus, the matching of the hashed IDs at Block 212 (of which more below) requires two further determinations to be made before any audio is received: a determination using the D bit (data or voice) that the transmission is a voice communication (Block 226) and a further determination that there is a full ID match after decoding the full LC message (Block 214) (I return to the full LC message in more detail below). The information in the D bit in the activity update message also requires further determination. If the transmission is voice (Block 226), then the full LC message must be received and an ID match performed (Block 216). On the other hand, if the transmission is data (Block 226), then the subscriber unit must go through the ballet in Figure 2B which involves several steps including potentially an ID match at Box 234. In any event, the point is the same: only in the case of the E bit does the invention in Figure 2A operate in accordance with claim 1 construed as Hytera would have it. Everything else in Figure 2A is outside claim 1 construed in that fashion. 171 The description then continues at p 8 line 26 to p 9 line 11 in these terms: If the active transmission is data (Block 226), then the scanning SU remains on the channel to recover the data message (Block 228) and waits until the end of the data transmission to receive a data terminator (Block 230). In an alternative, the scanning SU remains on the channel to receive embedded qualifying information. Continuing, the data terminator is decoded to identify addressing identification (or an "ID") (Block 232). If the ID is of interest to the scanning SU (Block 234), then the data message is further processed. Otherwise, the scanning SU tunes to the next channel in the preprogrammed scan list (Block 220). Continuing, the scanning SU determines whether confirmed delivery is requested (Block 236) for the data message. If confirmed delivery is requested, then the data message is processed until the entire data message is recovered (Block 238). In one embodiment, recovering an entire data message is performed by sending Selective Automatic Repeat Request (SARQ) messages to the BR. When the entire data message is recovered, the scanning SU tunes to the next channel in the preprogrammed scan list (Block 220). If confirmed delivery is not requested, then the scanning SU waits on the channel a predetermined amount of time for a possible redundant or subsequent transmission (Block 242). At the expiration of the predetermined amount of time, the scanning SU tunes to the next channel in the preprogrammed scan list (Block 220). 172 These relate to what occurs if the transmission is a data transmission. The data aspect of Figure 2B was not the subject of contention between the parties and as such may be passed over. The description then continues at p 9 lines 12 to 28: If the active transmission is voice (Block 226), then the scanning SU remains on the channel to perform a full link control (LC) qualification of the active transmission by decoding an LC message which identifies whether the active transmission is addressed to an individual SU or a talkgroup, an emergency or non emergency, and the source and destination of the active transmission (Block 214). In an illustrative embodiment, the LC message is a 7-burst CACH message. Performing full LC qualification means that the scanning SU waits for a LC message on the timeslot of interest and decodes an ID field of the LC message to determine whether the active transmission is of interest to the scanning SU. In an illustrative embodiment of the wireless communications landscape 100, because LC messages are available once every 360 msec, having to wait to decode a full LC message is time consuming for the scanning SU. If the ID field of the LC message is an ID of interest to the scanning SU (Block 216), then the speaker is unmuted and audio is rendered to the user of the scanning SU (Block 218). If the ID field of the LC message is not of interest to the scanning SU (Block 216), then the scanning SU tunes to the next channel in the preprogrammed scan list (Block 220). 173 It will be recalled from above that the full LC message at least includes the information in the activity update message. From this it also appears that it contains the full SUID or TGID. Consequently, it is apparent that the full LC is larger than the activity update message. This is confirmed by the fact that whereas the activity update message is transmitted as four bursts of 2.5 msec duration (at the end of each 30 msec burst), the full LC is transmitted in seven bursts (presumably of 56 bits). The statement that the full LC message is available every 360 msec suggests that it is available after 12 bursts (recalling that the bursts take 30 msec). The activity update message takes four bursts and the full LC message takes seven bursts. This suggests, but it is unclear, that the activity update message bursts and the full LC message bursts alternate at the end of the 30 msec block, i.e. one burst uses the 2.5 msec for the next burst of the activity update message and the following burst uses the 2.5 msec for the next burst of the full LC message. In any event, it is clear from what the description says in the next paragraph that the activity update message is received in full more often than the full LC message. 174 The description then continues at p 9 line 28 to p 10 line 3: If the ID field 308, 310 of the activity update message 300 does not contain an id that is of interest to the scanning SU (Block 212), then the scanning SU moves to the next channel in the preprogrammed scan list. In such a case, the scanning SU does not have to wait for a LC message. Because the LC message only is sent once every 360 msec, not having to wait for a LC message improves the time that the scanning SU spends during the function of scanning. By not having to wait for a LC message, the scanning SU is able to quickly determine that the active transmission is not of interest and the scan function is improved. 175 The point being made here is that the activity update message operates as a rapid negative criterion of exclusion and is faster than waiting for a full identification through the full LC message. The description then continues at p 10 lines 4 to 12: As is known in the art, the timing of events relating to color code, the activity update message 300, and the LC message may occur in any order. For example, the activity update message 300 may be received by the scanning SU before 1) the color code of the active transmission is known or 2) the full LC message is received. Also, a full LC message may be received before 1) the activity update message 300 is received by the scanning SU or 2) the color code of the active transmission is known. Further, as shown in FIG. 2, the color code of the active transmission may be known before 1) the activity update message 300 is received by the scanning SU or 2) the full LC message is received. 176 There was not a lot of discussion of this. However, it appears that its import is that where the subscriber unit actually receives the full LC message before the activity update message, it can use the full LC message. 177 The description then continues at p 10 lines 13 to 26: In any case, determining whether to remain on the channel and render audio to the user of the scanning SU is based upon whether the received information is of interest to the user. Specifically, a match of the color code and the full LC message stops the function of scanning and renders audio to the user of the scanning SU. A match of the color code and ID field 308, 310 of the activity update message 300 stops the function of scanning but requires a match of the full LC message before rendering audio to the user of the scanning SU. In an illustrative embodiment, a match of the ID field 308, 310 indicates that the active transmission may be of interest to the scanning SU. In such a case, the scanning SU remains on the channel and performs Link Control (LC) qualification of the active transmission before committing itself to remaining on the channel and rendering audio to the subscriber unit user. Alternatively, if there is not a match of the ID field 308, 310 then the scanning SU continues to scan with the next personality in the scan list. 178 This is an important passage and highlights the difference between the full LC message and the activity update message. The matching of colour codes, it will be recalled, relates to whether the subscriber unit is associated with the base radio which has sent the transmission. A matching of the 'ID field 308, 310' is a reference to a matching of the hashed ID codes in the activity message (that is, the last two rows of Figure 3). What appears from the last sentence reflects the fact, referred to above, that by compressing the SUID and TGID using a compression algorithm, a certain amount of information is lost in the process so that a match between the compressed 8 bit SUID or 8 bit TGID in the activity update message and the 24 bit SUID or 16 bit TGID which the subscriber unit is programmed to be interested in, does not entail with certainty that the SUID and TGID actually match. Only when the full LC message is received (and decoded) can a match be carried out using the full 24 bit SUID or 16 bit TGID. It is only then, according to this paragraph, that audio is rendered to the user. 179 This paragraph is important for the construction issues between the parties. As alluded to above, Hytera submits that on its proper construction, the expression in claim 1 'determining whether the activity is of interest to the subscriber unit' entails a decision making process that is once and for all; or, to put it another way, that once the subscriber unit has determined that activity is of interest to it, that is the end of the process and nothing more remains to be done but to remain on the channel to receive the communication. It is not necessary to say anything about the correctness of this argument at this stage, but it will be noted that the use of the activity update message as described in this paragraph (and more generally in the illustrative embodiment) does not accord with such a construction. The determination that the activity is of interest because there is a match in the hashed IDs is inherently provisional in this paragraph and there remains the further steps of checking the full LC message before the subscriber unit commits to remaining on the channel to receive the activity. For present purposes, what should be taken away from this paragraph is that it uses the expression 'is of interest to the user' (at p 10 lines 14 to 15) in a way which suggests that 'interest' may be a provisional state of affairs. 180 The description then continues at p 10 lines 27 to p 11 line 5: By utilizing an activity update message 300 in the wireless communications landscape 100, the time spent while scanning is reduced. For example, in the embodiment described, a scanning SU is able to identify an active transmission of no interest on average in 152 msec. In a worst case, a scanning SU takes up to 335 msec to identify an active transmission of no interest. Without the use of an embodiment of the present invention, experimentation has shown that in an average TDMA system, a scanning SU is able to identify an active transmission is of no interest on average in 512 msec and in the worst case in 695 msec. Further, without the use of an embodiment of the present invention, experimentation has shown that in an average FDMA system, a scanning SU is able to identify an active transmission is of no interest on average in 360 msec and in the worst case in 540 msec. 181 This passage explains the point of the activity update message and confirms that its advantage lies in its ability more rapidly to conclude that a transmission is not of interest. The illustrative embodiment is able to determine that a transmission is not of interest on average in 152 msec whereas without the use of the activity update message this takes on average 512 msec. In other words, the illustrative embodiment shows that the use of the activity update message allows the subscriber unit to ascertain that a transmission is not of interest more than twice as fast. 182 The description then continues at p 11 lines 6 to 12: Further yet, by utilizing an activity update message 300 in the wireless communications landscape 100, a SU that is a party to a call may quickly join the call if the SU is not currently a party to the call. Such an SU is called a late entry SU. For example, in the embodiment described, a late entry SU may join a call in a minimum of 120 msec. In a worst case, the late entry SU may join in about 300 msec. Without the use of an embodiment of the invention, experimentation has shown that a late entry SU takes about 360 msec and in the worst case about 720 msec to join a call. 183 This is a reference to the problem of late entry subscriber units. Nothing particularly turns on this. Finally, the description concludes at p 11 lines 13 to 21 in these terms: While the invention has been described in conjunction with specific embodiments thereof, additional advantages and modifications will readily occur to those skilled in the art. The invention, in its broader aspects, is therefore not limited to the specific details, representative apparatus, and illustrative examples shown and described. Various alterations, modifications and variations will be apparent to those skilled in the art in light of the foregoing description. Thus, it should be understood that the invention is not limited by the foregoing description, but embraces all such alterations, modifications and variations in accordance with the spirit and scope of the appended claims. 184 Nothing turns on this. CONSTRUCTION The Proper Construction of Claims 1-6 and 10 185 Claims 2-6 are dependent on claim 1. Claim 7 (which is not sued upon) is said by Motorola to be relevant to the construction of claim 1. Claim 7 is dependent on claim 6. Claim 10 is an independent claim. Claim 1 186 It is useful to set claim 1 out again, this time identifying its integers with numerical parentheses: 1. A method for scanning a TDMA channel by a subscriber unit in a wireless communications landscape, wherein the subscriber unit is operationally connected to at least one base radio over a plurality of channels, the method including the steps of: [1] locking onto a channel of the plurality of channels by the subscriber unit wherein a subset of the plurality of channels is preprogrammed in a list in the subscriber unit; [2] transmitting from at least one base radio a control message to the subscriber unit wherein the control message has a first information which informs the subscriber unit of activity present on the channel of the plurality of channels; [3] receiving and decoding the control message for the first information by the subscriber unit; and [4] if the first information indicates that activity is present on the channel of the plurality of channels, then [5] determining whether the activity is of interest to the subscriber unit by comparing a second information in the control message with a third information preprogrammed in the subscriber unit and [6] if the activity is of interest to the subscriber unit, then remaining on the channel of the plurality of channels to receive the activity present on the channel. 187 The parties are in disagreement about the construction of integers 5 and 6 and in particular about the meaning of the phrases: (a) 'determining whether the activity is of interest to the subscriber unit'; and (b) 'remaining on the channel … to receive the activity'. The Competing Constructions 188 Motorola submitted that the first expression ('determining whether the activity is of interest…') was a reference to an assessment that the activity is of relevance or utility to the subscriber unit, in the sense of having some bearing on a subsequent communication step. It involved evaluating that the activity was of interest based on satisfaction of the test appearing in the fifth integer of claim 1, i.e. 'by comparing a second information in the control message with a third information preprogrammed in the subscriber unit'. It did not, however, exclude the possibility of further steps including a further confirmation. 189 Hytera, on the other hand, says that both phrases are clear and prescriptive and require a determination to be made as to whether the activity is of interest to the subscriber unit and, if it is, that the subscriber unit must remain on the channel to receive the activity. On this view of claim 1, the method does not include the possibility that the determination of whether the activity is of interest to the subscriber unit may happen more than once. Motorola described Hytera's construction as involving a once and for all determination. I consider this an accurate description. Whilst Hytera said that these were Motorola's words and not its own, in argument Mr Dimitriadis SC accepted that the effect of Hytera's construction was that once a determination was made, the process was concluded: T88.11. 190 The debate between the parties is best illustrated by reference to one of the preferred embodiments referred to in the specification and the figure with which it is accompanied. The relevant figure is Figure 2A. Figure 2A is described at p 2 lines 7 to 8 of the detailed description as 'a flow diagram of an example method for providing channel access for voice transmissions'. What is key for present purposes are Blocks 212, 216 and 222 in Figure 2A (which is already set out above, but is also set out again below for convenience). 191 It will be seen that 'ID Match' appears at Blocks 212, 216 and 222 although in Block 222 the wording is slightly different. It should also be noted that in the order specified by the flow chart, the blocks are addressed in the order 222, 212 and 216. Jumping somewhat ahead to make it easier to follow, the parties agree that the reference to 'ID Match' at 212 is a reference to that part of integer 5 of claim 1 which refers to 'determining whether the activity is of interest to the subscriber unit'. They also agree that the reference to 'ID Match' at Block 216 is an example of a determination of whether the activity is of interest to the subscriber unit. They disagree, however, on whether this second reference is within claim 1. The difference between them in relation to claim 1 is thus whether 'determines' means determined once and for all (as Hytera in substance contends) or whether it does not exclude the possibility of further subsequent determination (as Motorola contends). 192 If Motorola's construction is correct, then both Block 212 and Block 216 may be a 'determination' within the meaning of claim 1. On the other hand, if Hytera is right, then the fact that it is not in dispute that a 'yes' answer to Block 212 is a determination within the meaning of claim 1 necessarily implies that Block 216 cannot be a determination within the meaning of claim 1. 193 Most, but not all, of the debate between the parties was generated by the interpretative tension between claim 1 and the preferred embodiment illustrated in Figure 2A. Motorola emphasises that claim 1 is to be interpreted in the context of the specification as a whole, including in light of the nature and purpose of the invention disclosed, and the CGK in the field. The presence in the preferred embodiment illustrated in Figure 2A of two steps involving a determination that the activity was of interest to the subscriber unit, led Motorola to submit that claim 1 should be construed in that light. On the other hand, Hytera emphasises that it is the language of the claims which must be construed and that it is not legitimate to expand the boundary of the monopoly as fixed by the words of claim 1 by adding a gloss drawn from the preferred embodiment illustrated in Figure 2A or the description of that embodiment in the specification. Both statements of principle are correct. The main question, therefore, is whether what Motorola seeks is a legitimate contextual construction of the word 'determine' or an impermissible attempt to gloss claim 1 by reference to one of the preferred embodiments. 194 Turning then to the precise issues between the parties, Motorola submitted as follows. First, as noted in the previous paragraph, it submitted that Block 212, and the preferred embodiment it illustrated, showed that the determination could be non-conclusive. There was no dispute that Block 212 is non-conclusive and I accept Motorola's submission that the preferred embodiment and Block 212 involve a determination of whether the activity is of interest to the subscriber unit which is not on a once and for all basis. I also accept, and it was not disputed, that Block 216 involves another step where it is determined whether the activity is of interest to the subscriber unit. I also accept Motorola's submission that the word 'determines' when used in the part of the description of the preferred embodiment corresponding to Block 212 must bear a meaning which encompasses the possibility of a subsequent determination at Block 216. The relevant part of the specification was at p 7 lines 24 to 27: If an active transmission is present and if the scanning SU is programmed to check the active transmission (Block 222) for a transmission addressed to a SU of interest, then the scanning SU determines whether the active transmission is addressed to a SU of interest (Block 212). 195 I do not accept Motorola's submission that Mr Kuhrt had agreed that the word 'determines' when used in the patent did not exclude a subsequent further step of confirmation. The relevant evidence is at T678.34-679.24. It was clear that Mr Kuhrt was being cross-examined about the preferred embodiment rather than claim 1. Although it is true that one of the questions he was asked included a reference to the meaning of the word 'determines' 'as used in the patent', I do not think Mr Kuhrt can be taken in the full context of the questions he was being asked to have been expressing a view about the meaning of that word in claim 1. 196 Secondly, Motorola submitted in relation to integer 6 of claim 1 that there was a distinction between 'remaining on the channel' (the words used) and committing itself to remain on the channel. This distinction was also to be found in the preferred embodiment. The relevant portion of the description of the preferred embodiment was at p 10 lines 20 to 24: In an illustrative embodiment, a match of the ID field 308, 310 indicates that the active transmission may be of interest to the scanning SU. In such a case, the scanning SU remains on the channel and performs Link Control (LC) qualification of the active transmission before committing itself to remaining on the channel and rendering audio to the subscriber unit user. Alternatively, if there is not a match of the ID field 308, 310 then the scanning SU continues to scan with the next personality in the scan list. 197 The reference to fields 308 and 310 takes one again to Figure 3. Figure 3 is described at p 2 lines 9 to 10 as 'an example of a specific Common Announcement Channel [CACH] message called an Activity Update'. 198 Figure 3, which I have already extracted above, is once again as follows: 199 Motorola submitted, and I accept, that this is a discussion of what occurs in the preferred embodiment when there is a match of the 'hashed ID'. It submitted, and I accept, that this shows that the subscriber unit would remain on the channel until committing itself to remain on that channel. I do not accept Hytera's submission that the reference in p 10 line 21 to 'may' alters this analysis. Hytera's answer to this was that what was happening at p 10 line 21 when the question was posed whether the activity 'may be of interest' was not relevant to the construction of integer 6 of claim 1 because the expression there used was 'is of interest'. What the preferred embodiment did when the activity 'may be of interest' threw no light on that issue. On this view, the kind of commitment to remain on the channel required by integer 6 only occurred when the comparison with the full ID field in the full LC message took place (at p 10 lines 22 to 24). I do not accept this submission. The passage at p 10 lines 20 to 24 clearly contemplates a situation where remaining on the channel has a contingent quality about it at one time and a definitive quality at another. I also do not accept Hytera's submission that its position is supported by the reference to 'is of interest' at p 10 lines 14 to 15. The following sentence shows that two determinations take place before that occurs (i.e. colour matching and the full LC message). 200 I therefore accept that this portion of the description of the preferred embodiment observes a distinction between remaining on the channel and committing itself to remain on the channel. The question, however, is whether this distinction accords with the meaning of 'remaining on the channel' in integer 6 of claim 1. Professor Rangan thought that 'remaining on the channel' did not mean committing itself to remaining on the channel. Mr Kuhrt accepted that this was an available reading of integer 6 of claim 1 although it was not the one which he preferred. In his view, 'remaining on the channel' was what happened after it was determined that the activity was of interest to the subscriber unit. 201 Thirdly, Motorola submitted (in relation to integer 6 of claim 1) that the expression 'remaining on the channel … to receive the activity present on the channel' was an example where the use of the infinitive 'to receive' connoted a purpose or function. It followed that so parsed, integer 6 of claim 1 did not have as one of its elements the actual receipt of the activity. Whilst I accept the grammatical parsing, on balance, I regard this consideration as of little weight as it appears to involve giving considerable significance to the use of the infinitive as the expression of a function or purpose. Whilst I would accept that such reasoning would be appropriate in the construction of a statute (see, e.g. Sunchen Pty Ltd v Federal Commissioner of Taxation [2010] FCAFC 138; 190 FCR 38 at 55 per Jessup J) it would appear to be the kind of 'meticulous verbal analysis' which the authorities counsel against in the construction of patents: Catnic Components Limited v Hill & Smith Limited [1982] RPC 183 at 242-243 per Diplock LJ. 202 Fourthly, Motorola submitted that the main embodiment set out in the specification plainly involved a process where an initial determination was made followed by a subsequent, more definitive determination. By this, Motorola intended a reference to the method illustrated in Figure 2A which is described at p 2 line 7 as 'a flow diagram of an example method for providing channel access for voice transmissions'. If Hytera's construction were correct, then it would follow that the preferred embodiment lay outside the patent. Here the point was not so much that the preferred embodiment had elements which were not within the claims but that the preferred embodiment would itself not be within the claims. This was said to be unusual and not something that a construction of the claims, in light of the patent as a whole including the specification, would ordinarily yield. 203 As I understood it, Hytera developed three answers to this. The first was in Mr Dimitriadis' opening address at T88.35-89.18 and, although Mr Dimitriadis did not refer to the graphic elements of Figure 2A specifically, was to the effect that Figure 2A also disclosed the possibility of a single determination consistent with his construction. This argument centred on Block 224 which was said to involve a determination within integer 6 of claim 1. Assuming that to be correct, the logic of the submission is that a 'yes' answer to Block 224 leads to the unmuting of the speaker at Block 218 and the delivery of the transmission. In such a state of affairs, there would be but one determination. Consequently, so Hytera submitted, Figure 2A was consistent with its construction of claim 1. To the extent that it had matters in addition to claim 1 – such as Blocks 212 and 216 – this did not mean that Figure 2A did not embody claim 1: Lockwood Security Products Pty Limited v Doric Products Pty Limited [2004] HCA 58; 217 CLR 274 ('Lockwood (No 1)') at [69] per Gleeson CJ, McHugh, Gummow, Hayne and Heydon JJ. 204 I accept this submission. It is not the case therefore that if Hytera's construction is correct Figure 2A does not embody claim 1. 205 The second answer was also given by Mr Dimitriadis in opening at T92.15 and was to the effect that the argument could not succeed because claim 11 in fact claimed the method 'substantially as herein described with reference to the accompanying drawings'. Motorola did not rely on claim 11 which is no answer to the point. There may be questions about the validity of a claim such as claim 11 or at least about the manner in which it is to be interpreted. In the circumstances where I have accepted that Figure 2A does embody claim 1, it is not necessary to consider claim 11 further. 206 Hytera's third answer appeared in a different part of its closing written submissions on claim 1 at [32(c)] and was to the effect that to the extent that any part of Figure 2A was not within claim 1, it was within claim 11. In light of my acceptance of the first argument I do not need to reach a view on this second argument. 207 In writing, Hytera also advanced three further reasons to reject Motorola's contention about the preferred embodiment not implementing the invention on Hytera's construction. The first was that there was no reference to an initial determination that the activity 'is of interest'. Secondly, it was said that Motorola's reference to 'remaining on the channel rather than switching to the next channel' was not the wording of integer 6 of claim 1. I accept both of these points but observe that neither appears to be responsive to Motorola's submission unless they are understood to serve as examples of Hytera's third argument. That third argument is that Motorola's construction impermissibly borrows language from the specification to place a gloss on claim 1. I return to this point below. 208 In any event, for the reasons I have given, I reject Motorola's submission that Hytera's construction has the effect that Figure 2A does not embody the invention as claimed in claim 1. 209 Fifthly, Motorola relied upon claim 7. Claim 7 was dependent on claim 1. Motorola does not assert claim 7 in its infringement suit but rather says that claim 7 offers support for its construction of claim 1. Claim 7 refers to a process of recovering and decoding an LC message for identification information and determining whether the LC message is of interest to the subscriber unit by comparing the identification information with a fourth information preprogrammed in the subscriber unit. If there is such a match then the subscriber unit is to remain on the channel to receive the activity present on the channel. Motorola's point is that claim 7 necessarily assumes that the determination in claim 1 cannot be once and for all and that the 'remaining on the channel' it contemplates need not be permanent either. 210 Motorola submitted that if claim 1 meant as Hytera contended, then claim 7 could never be enlivened. It noted the evidence of Mr Kuhrt. Mr Kuhrt was not asked by Hytera to consider the significance of claim 7 for claim 1. Under cross-examination, he agreed that if one read claim 1 consistently with claim 7 this would be a pointer that Motorola's interpretation of 'determining' in integer 5 and 'remaining' in integer 6 of claim 1 was correct. 211 On its face, if Hytera's construction is correct this would mean that claim 7 could never be enlivened. However, Hytera disputed that this was of any significance. It submitted that there were limits on the extent to which a dependent claim such as claim 7 can inform issues of the claim upon which it depends. If the plain meaning of a claim has the effect that one or more dependent claims are redundant then the consequence of redundancy would not drive the construction of the claim itself. For this proposition Hytera cited Davies v Lazer Safe Pty Ltd [2019] FCAFC 65 ('Davies') at [65] and Nichia Corporation v Arrow Electronics Australia Pty Ltd [2019] FCAFC 2 ('Nichia') at [41]. 212 I do not think that Nichia assists Hytera. The relevant passage is at [40]-[41] in the reasons of Jagot J (with whom Besanko and Nicholas JJ agreed). There, her Honour said: In contrast to the primary judge, I also consider claim 6 does not provide assistance for the resolution of this issue of construction. Claim 6 merely raises the same issue of construction. Claim 6 can function as a dependent claim, narrower than claim 3, whether "contains" is construed to mean "includes" or "contains only". Either way, claim 6 is narrower than claim 3 and can depend on claim 3 because there must be at least two fluorescent materials of different compositions within the general formula to satisfy claim 6 whereas one single fluorescent material represented by the general formula would satisfy claim 3. Nor do I consider that the existence of a degree of overlap between claims 3 and 6 provides a sound basis to prefer one construction of claims over another. Even if, as the primary judge said at [97], claim 6 is "largely redundant" because claim 3 also covers two or more fluorescent materials of different compositions represented by the general formula, the redundancy is not complete as claim 6 specifically defines and claims a sub-set of claim 3 devices. In any event, some, even extensive, redundancy in the drafting of patent claims seems more an indicator of an abundance of caution than a guide to the meaning of "contains" which appears in both claims 3 and 6 (and other claims) and thus should generally be construed as having the same meaning wherever it is used. 213 So the issue Jagot J was dealing with was whether claim 6 (which required two fluorescent materials) was made redundant by claim 3 which could be satisfied by one single fluorescent material. The point was that the trial judge had found that claim 3 could also cover two or more fluorescent materials and had concluded therefore that claim 6 was redundant (on the relevant construction). Jagot J rejected that analysis but then observed, 'some, even extensive, redundancy' in the drafting of patent claims seemed more to indicate an abundance of caution in the drafting of the claims. 214 That is not the situation here. The present situation is that the construction of claim 1 for which Hytera contends has the effect that there can never be an invention embodying claim 7 because the criteria of operation for claim 7 is inimical to claim 1 on which it depends. This is not a case of redundancy, therefore, but rather inconsistency. The effect of the inconsistency, it is true, is that claim 7 can never have any work to do. But to describe the problem in that way would be to obscure the textual significance of the fact that claim 7 takes as its point of departure an operation for claim 1 which is contrary to that now contended for by Hytera. 215 In Davies, the Full Court (Greenwood, White and Burley JJ) said at [65]: Finally, in ground 6 the appellants contend that in construing claim 1, the primary judge erred at [239] by failing to construe claim 1 in the context of the dependent claims, and in particular in the context of claim 2. Having regard to the conclusion that we have reached in relation to grounds 3, 4 and 5, it is unnecessary to address this ground in detail. The appellants submit that the primary judge's construction of integers (1.5) and (1.6) is not "harmonious" with the scope of dependent claims 2 and 8 – 11. The appellants do not, however, submit that the construction adopted by the primary judge renders those claims redundant. If that were the case, then the Court would endeavour to construe claim 1 in a manner that avoided redundancy; see Bodkin, Patent Law in Australia, 3rd ed, 2019, at [21910]. This is consistent with the proper approach to claim construction that construes claims in the context of the specification as a whole, including the other claims. Nevertheless, if the plain meaning of a claim has the effect that one or more dependent claims are redundant, then the consequence of redundancy would not drive the construction of the claim itself … 216 Again, I do not think this assists since the current circumstance does not involve redundancy in the sense being discussed. 217 Sixthly, Motorola submitted that its interpretation was more consistent with the function of the patent as a whole. This argument went as follows: the patent was to be seen as primarily concerned with a method by which a subscriber unit could make faster decisions that activity on the channel was of no interest before moving on to the next channel. On this view of the invention, the critical determination was the determination to move on to the next channel or alternatively to remain on the current channel. Textual support for this understanding of the function of the patent as a whole was to be found in two passages in the description of the invention. These were at p 10 lines 1 to 3 and p 10 line 27 to p 11 line 2. These passages are as follows: By not having to wait for a LC message, the scanning SU is able to quickly determine that the active transmission is not of interest and the scan function is improved. … By utilizing an activity update message 300 in the wireless communications landscape 100, the time spent while scanning is reduced. For example, in the embodiment described, a scanning SU is able to identify an active transmission of no interest on average in 152 msec. In a worst case, a scanning SU takes up to 335 msec to identify an active transmission of no interest. Without the use of an embodiment of the present invention, experimentation has shown that in an average TDMA system, a scanning SU is able to identify an active transmission is of no interest on average in 512 msec and in the worst case in 695 msec. 218 Hytera made three points about this. First, it was said that the advantage identified was an advantage obtained by the subscriber unit moving on to the next channel where a transmission was not of interest. Secondly and by extension, Hytera submitted that its construction took account of that claimed advantage because where a determination was made that the activity was not of interest, the subscriber unit would not remain on the channel. I do not accept these submissions. Where multiple determinations are possible, the determination based on the information which is then available that the activity is not of interest causes the scan to move to the next channel. Hytera's construction requires that to be done only once so that all of the information must be unpacked – in this way, Hytera's construction detracts from, rather than supports the advantage which claim 1 confers. 219 Thirdly, it was submitted that many of the embodiments described in the specification were within claim 1 on Hytera's construction and to the extent that they were not within claim 1, they were within claim 11. In response to this, Motorola submitted that a claim like claim 11 would ordinarily be understood as narrower in scope than all of the other claims and would not have the effect of broadening an invention or replacing an integer. For this proposition Motorola relied on the decision of the Full Court (Allsop CJ, Yates and Robertson JJ) in GlaxoSmithKline Australia Pty Ltd v Reckitt Benckiser Healthcare (UK) Ltd [2016] FCAFC 90; 120 IPR 406 ('GlaxoSmithKline') at [74]-[80]. The patent under consideration in that case was for a liquid dispensing apparatus comprising a bottle, a bottle neck liner, and a syringe, used for the administration of Children's Panadol. Claim 1 contained a consistory statement which, read together with the specification, disclosed the essential elements of the invention: at [80]. One of those elements was that the syringe claimed in claim 1 was 'flat-nosed'. The example given in the patent depicted a flat-nosed syringe. Claim 9, in the omnibus style of claim 11 of the 355 Patent, claimed 'a liquid dispensing apparatus, substantially as described with reference to the drawings and/or examples'. The defendant's product used a syringe which was not flat-nosed. The trial judge accepted the patentee's argument that although this product did not infringe claim 1, it nonetheless infringed claim 9 because, for the purposes of that claim, it was an example of a syringe 'substantially' as described in the patent: [54]-[56]. The Full Court reversed this holding on appeal, stating at [80]: The word "substantially" provides no warrant for departing from what the specification itself mandates to be the essential features of the invention. A flat-nosed syringe dimensioned as described in the consistory statement is one of the essential features of the invention. Thus, whatever work the word "substantially" is to perform in claim 9, it cannot transform a feature made essential by the description of the invention into one that is now inessential. Put another way, an embodiment that does not possess the essential features of the invention as described, cannot be one that is "substantially as described". Thus, the word "substantially" in claim 9 does not do the work which the primary judge held that it did. 220 This holding does not squarely rebut Hytera's argument. Hytera's point is not that claim 11 extends the inventive monopoly in a way that transforms essential features of the invention claimed in claim 1 into non-essential ones. Rather, its point is that, to the extent the drawings depict features not found in claim 1, those features may be picked up by the omnibus claim 11. Motorola's reliance on GlaxoSmithKline is therefore somewhat misplaced. That said, I do not accept Hytera's argument. Claim 1 is to be construed in light of the specification as a whole, which includes the examples and drawings. The elements of claim 1 with which we are presently concerned – the subscriber unit 'determining' that an activity is of interest and 'remaining on the channel' – are elements that can readily be seen to be depicted in Figure 2A once they are understood in the way that Motorola suggests. This is therefore a construction of claim 1 which makes sense in light of the specification including the drawings. The alternative view, that Figure 2A partly depicts the narrow concept of 'determining' and 'remaining' (claimed in claim 1) and then a range of other features claimed non-specifically (via the omnibus claim 11), is not one that I have found persuasive. 221 I therefore accept Motorola's sixth submission. It is consistent with the statement under the heading 'Background to the Invention' at p 1 lines 31 to 32 where the problem which the patent was intended to solve was identified: 'Accordingly, there exists a need for scanning a TDMA channel which improves the amount of time that an SU spend scanning'. I also accept that Motorola's construction of 'determining' and 'remaining' would achieve that purpose but Hytera's would not. Consideration 222 Motorola's construction of integers 5 and 6 of claim 1 is to be preferred to that of Hytera. Their wording is capable of bearing the meaning for which both parties contend, as Mr Kuhrt accepted at least in relation to 'remaining on the channel … to receive the activity present'. The fact that Mr Kuhrt and Professor Rangan disagreed about the construction of 'determining' underscores my own conclusion that the word is capable of bearing both meanings as does the expression 'remaining on the channel … to receive the activity present'. 223 Embracing either party's construction does not therefore involve the importation into claim 1 of some feature appearing in the preferred embodiment: cf. Rehm Pty Ltd v Websters Security Systems (International) Pty Ltd (1988) 81 ALR 79 at 89 per Gummow J; Lockwood (No 1) at [69]; Australian Mud Company Pty Ltd v Coretell Pty Ltd [2011] FCAFC 121; 93 IPR 188 at [72] per Bennett, Gilmour and Yates JJ; Fresenius Medical Care Australia Pty Limited v Gambro Pty Limited [2005] FCAFC 220; 67 IPR 230 at [94] per Wilcox, Branson and Bennett JJ. Rather, it involves construing claim 1 in the context of the specification as a whole, including in light of the nature and purpose of the invention disclosed and the CGK in the field. 224 Motorola's construction is preferable for two reasons. First, it is consistent with the function of the patent whilst Hytera's is not. Secondly, claim 7 is drafted in a way which assumes that claim 1 does not operate as Hytera submits. Claim 5 225 Claim 5 is as follows: 5. The method of any one of the preceding claims wherein the activity is of interest if the control message indicates that the activity is targeted for the subscriber unit. 226 Also relevant for the way in which Motorola initially put its case is claim 6: 6. The method of claim 5 wherein the second information indicates a characteristic of the activity wherein the characteristic is chosen from the group consisting of identification, voice, data, group, individual, emergency, and non emergency. 227 As the case was opened by both parties, the issue of construction which arose concerned the meaning of the word 'targeted'. Motorola's position, based on the evidence of Professor Rangan, was that the word 'targeted' was not limited to the use of addressing information. Hytera's position based on the evidence in chief of Professor Viterbo, was that 'targeted' meant targeted to a particular identified subscriber unit. 228 During the course of the trial, the position of Professor Viterbo altered. Under cross-examination he conceded that 'targeted' could have the broader meaning contended for by Professor Rangan. In Motorola's closing written submissions, the evidence about this was extensively set out. In Hytera's submissions in response, no attempt was made to engage with this evidence. Instead, it was simply said that Professor Viterbo 'disagreed' with Professor Rangan's view without dealing with what had occurred during Professor Viterbo's cross-examination. Hytera then submitted that the difference between the two professors 'does not appear to be a critical point of difference'. The same position was taken in Hytera's oral closing submissions. 229 Where Hytera has not advanced any submission as to why the evidence which appears to suggest that Professor Viterbo had accepted that 'targeted' had the broader meaning advanced by Motorola, I see no reason why I should not accept Motorola's submissions about it. I therefore accept that the position of both Professor Rangan and Professor Viterbo was, by the end of the trial, that 'targeted' was not limited to the use of addressing information. 230 That agreement reflects my own view. There are several ways in which activity might be targeted for a particular subscriber unit. It might be because the subscriber unit is programmed to receive a class of activity such as emergency transmissions which does not involve targeting by means of addressing information. Nevertheless, the word 'targeted' comfortably covers that situation as a matter of ordinary English. I therefore conclude that 'targeted' has the meaning submitted by Motorola. I am fortified in this view by Hytera's failure to make any substantive submissions about the topic at the end of the trial beyond the formal ones to which I have referred to above. INVENTIVE STEP Introduction 231 Hytera's opening case on obviousness was that the invention disclosed in the claims to the 355 Patent was obvious in light of the CGK and therefore lacked an inventive step. As an alternative case, Hytera submitted that the invention disclosed by the claims was obvious in light of the CGK, together with two other documents it submitted that the skilled person could reasonably be expected to have ascertained, understood, and regarded as relevant under s 7(3) of the Act. These were the Telecommunications Industry Association's 'Project 25: FDMA – Common Air Interface' Standard ('P25 Standard'), and the ETSI Draft DMR Protocol. It was accepted, by the conclusion of the trial, that these two documents were s 7(3) documents. It is not useful therefore to determine whether they also formed part of the CGK. 232 Hytera's case on obviousness was based on the evidence of Mr Kuhrt and, as I discuss later, Professor Rangan's evidence in cross-examination. Mr Kuhrt had been asked to identify what scanning method he would have proposed if asked to develop a conventional digital two-way radio system that improved the amount of time a radio spent scanning channels before July 2004. In his first affidavit, Mr Kuhrt identified such a scanning method. In his second affidavit, he gave further evidence that his method fell within claims 1-6 and 10 of the 355 Patent. He also gave evidence that no ingenuity on his part had been required in formulating his method. Mr Kuhrt's method was subsequently criticised in certain ways by Professor Rangan. In consequence, Mr Kuhrt clarified and revised his method to address each of Professor Rangan's concerns. This revised method, he claimed, also fell within the claims of the 355 Patent and similarly involved no ingenuity. Motorola did not submit that Mr Kuhrt's method lay outside the claims of the 355 Patent. It did however propose its own formulation of what the inventive step of the invention was. Relevant Principles 233 An invention is taken to involve an inventive step unless it is 'obvious' to a person skilled in the relevant art in light of the CGK considered alone (Patents Act 1990 (Cth) s 7(2) ('Patents Act')), or together with information in particular documents as defined in s 7(3). The CGK and the s 7(3) documents have a negative aspect to them as well. As the High Court observed in Lockwood Security Products Pty Ltd v Doric Products Pty Ltd (No 2) [2007] HCA 21; 235 CLR 173 at [111] ('Lockwood (No 2)'): Practical and technical issues can affect the means by which a concept may be implemented in respect of an already vendible product, and scepticism can inhibit recognition of the utility of applying a concept or idea to a known set of integers. These are matters within the knowledge of relevant witnesses. 234 In its written closing submissions, Motorola emphasised this negative aspect of the CGK as having particular aptness in a field such as wireless communications systems because the standards environment imposed practical and technical constraints on the developments in the relevant technology: at [33]. In Dyson Appliances Ltd v Hoover Ltd [2001] RPC 26 at [156], the English Patents Court recognised the negative aspects of the CGK when discussing how the skilled addressee might have approached the idea of cleaning air in a vacuum cleaner, not by means of bags, but instead by using cyclonic action alone: In terms of its impact on the issue of obviousness, I believe that this negative thinking which as Mr Kitchin suggested amounted to prejudice, would at least have caused the addressee to regard modification to any of these prior art proposals with considerable reserve if not overt scepticism. 235 As at the priority date, the only TDMA system in existence, as disclosed by the evidence, was the system embodied by TETRA. ETSI was considering introducing a TDMA standard and did so the following year in the form of the 2005 DMR Standard. As at the priority date, it did not exist, although it was in preparation. As I discuss later, a draft of the standard, the Draft DMR Protocol, was available to those in the industry. The point, for relevant purposes, is that as at the priority date, there was no standardised TDMA system although it was apparent that one was soon to be forthcoming. Accepting therefore Motorola's submission that in a field such as wireless technology the standards environment can impose practical and technical constraints on development, such restrictions in this case are those which can be discerned from 1998 TETRA Standard and the Draft DMR Protocol. As will be seen, Mr Kuhrt's initial proposed method of scanning would not have been compatible with either of these. When Professor Rangan pointed this out, particularly in relation to the Draft DMR Protocol, Mr Kuhrt revised aspects of his method which to an extent, although not completely, would have brought it within the Draft DMR Protocol. He was explicit in this exercise in doing this only as a response to Professor Rangan's criticisms. 236 Various expressions have been used to describe what is obvious. It must be 'very plain' (Lockwood (No 2) at [51]); it is something that is 'lying in the way' (not in the sense of an obstacle but in the sense of something encountered on the path) (Elconnex Pty Ltd v Gerard Industries Pty Ltd (1991) 32 FCR 491 at 507 per Burchett J); 'you can go straight to it' (American Cyanamid Company v Berk Pharmaceuticals Limited [1976] RPC 231 at 257); or it is something which 'would at once occur to anyone acquainted with the subject, and desirous of accomplishing the end' (Vickers, Sons & Co Ltd v Siddell (1890) 15 AC 496 at 502). Another expression coined by Lockhart J in R D Werner & Co Inc v Bailey Aluminium Products Pty Ltd (1989) 25 FCR 565 at 574 is that there must be 'some difficulty overcome, some barrier crossed', an expression noted by the High Court in Lockwood (No 2) at [52], and often referred to in this Court as a convenient metric. Some inventiveness is therefore required although it is also accepted that only a 'scintilla of invention' is required under Australian law: Aktiebolaget Hässle v Alphapharm Pty Ltd [2002] HCA 59; 212 CLR 411 at [48] ('Alphapharm'). This perhaps may be seen as the obverse corollary of the requirement that obvious means 'very plain'. 237 The question of obviousness is not to be addressed by asking whether each integer or step is obvious. The question is rather whether the combination of integers as a whole is obvious in the requisite sense: Alphapharm at [60]-[72]. As will be seen, this principle has some relevance to the issues which arise. 238 As articulated at [21] of Alphapharm, in considering what is very plain, one is to look forward and to avoid the perils of hindsight: In those circumstances, the warnings in the authorities against the misuse of hindsight are not to be repeated as but prefatory averments and statements of trite law. The danger of such misuse will be particularly acute where what is claimed is a new and inventive combination for the interaction of integers, some or all of which are known. 239 In this case, as will be seen, Mr Kuhrt was aware of the 2005 DMR Standard which was published in April 2005. As I discuss below, that standard included within it a scan message which used an activity indicator bit and ID information. Although he was asked to formulate his method before being shown the 355 Patent, it must be borne in mind that Mr Kuhrt already knew (and had known for a long time) that the 2005 DMR Standard used an activity indicator bit and identification information. In assessing his proposed revised method, it is to be borne in mind, therefore, that in a sense he had already seen the solution in the 355 Patent because it was the solution in the 2005 DMR Standard. Whilst I do not doubt that Mr Kuhrt genuinely believed that he put himself in the position he would have been in as at July 2004, that is, that he knew nothing except for pre-existing standards (such as the P25 Standard, the 1998 TETRA Standard and the Draft DMR Protocol) at a remove of 14 years, it must be doubted in my view whether it is reasonably possible to put out of one's mind the existence of the 2005 DMR Standard. I return to this topic below. 240 Whether an invention is obvious is a question to be answered by the Court (AstraZeneca AB v Apotex Pty Ltd [2014] FCAFC 99; 226 FCR 324 at [543] ('AstraZeneca')) and is a kind of 'jury question': Lockwood (No 2) at [51]. The Court poses the question for itself from the position of a hypothetical construct, the non-inventive skilled person: Wellcome Foundation Ltd v VR Laboratories (Aust) Pty Ltd (1981) 148 CLR 262 at 270-271; AstraZeneca AB v Apotex Pty Ltd [2015] HCA 30; 257 CLR 356 at [18] and [23] per French CJ. 241 It is useful then to begin with the CGK. The Common General Knowledge 242 I have touched on much which follows in Chapter II and there is, to a degree, some overlap. However, the present discussion is more focussed on the issues relating to the 355 Patent. Much, but not all of it, is uncontroversial. Where there is a controversy, I explain it. 243 There are two categories of two-way radio systems: conventional and trunked. In conventional systems, users monitor traffic channels (i.e. channels that facilitate transmissions between users) to select one for transmission purposes. In trunked systems, users monitor control channels which then assign them to traffic channels for transmission purposes. Mobile stations in two-way radio systems have been able automatically to scan frequencies for transmissions since the 1980s. 244 In conventional two-way radio systems, mobile stations scan traffic channels. Mobile stations are pre-programmed with a list of channels for scanning purposes. When scanning, a mobile station locks onto channels in this list to locate active transmissions. While scanning, if a mobile station determines that a transmission is, for example, a valid voice transmission, it will stop scanning and render the transmission to the mobile station's speaker. 245 FDMA separates channels by frequency. For example, FDMA could be implemented to facilitate multiple access by splitting a 12.5 kHz frequency into two 6.25 kHz frequencies that form separate channels. FDMA was introduced as a multiple access method to two-way radios in the 1990s. In FDMA systems, a transmission occupies the whole channel. APCO P25 is an example of a two-way radio system that was developed in the 1990s that implements FDMA as the multiple access method. 246 On the other hand, TDMA separates channels into timeslots while preserving the channel bandwidth. For example, a 12.5 kHz frequency may be split into two timeslots, referred to as 'logical channels', and a transmission occupies one timeslot on the frequency. TDMA was introduced as a multiple access method to two-way radios in the 1990s. TETRA is an example of a two-way radio system that implements TDMA as the multiple access method. The distinction between FDMA and TDMA systems may be understood diagrammatically in this way: 247 As at July 2004, the standardised two-way radio systems that were known to persons working in the field of two-way radios in Australia included the TETRA, P25 and MPT1327 systems. TETRA implemented TDMA as the multiple access method. The 2005 DMR Standard, which became a standardised TDMA two-way radio system, was known to be in its draft stage. 248 Two-way radio systems utilise control messaging for scanning purposes. The use of control messages allows scanning mobile stations to determine information about the transmission taking place on a channel. Analogue two-way radios implement frequency tones as a form of control message for scanning purposes. Analogue mobile stations often included in their memory a list of frequency tones that were associated with, for example, a talkgroup. When the frequency tone is detected during scanning, the station would stay on that relevant channel emitting that tone. 249 Digital two-way radio systems implement control messages in the form of embedded signalling within a data stream for scanning purposes. These messages may be contained within the transmission itself (conventional systems) or separately transmitted on a control channel (trunked systems). In digital systems, control messages are used to provide information about transmissions on a traffic channel. 250 MPT1327 two-way radio systems utilise digital GTCM as a form of control messaging for scanning purposes. The GTCM is transmitted by a repeater on the control channel to broadcast control information to connected terminals about transmissions on traffic channels. Similarly, TETRA two-way radio systems also utilise digital control messages that are transmitted on a dedicated control channel to broadcast information about transmissions on traffic channels. However, unlike MPT1327, because TETRA implements TDMA, a single repeater can be used for both control slots and multiple talk slots. APCO P25 two-way radio transmissions include LC messaging that forms part of a digital voice transmission to provide signalling information to scanning mobile stations in a conventional (non-trunked) system. 251 The control messages used for scanning purposes in MPT1327, TETRA and APCO P25 systems included addressing information such as TGID and/or SUID information. The inclusion of addressing information allows for a scanning mobile station to determine if it is an intended recipient of an active transmission by comparing the addressing information in the control message with addressing information stored in its memory. Control Information and Activity Indicators 252 Control messages used in FDMA two-way radio systems do not require signalling information that indicate timeslot activity since timeslots are not used in FDMA systems. Hytera submitted that TDMA systems require control information indicating timeslot activity because one frequency can carry several concurrent transmissions on different timeslots. It submitted that it was within the CGK that control information was generally sent in control messages which could be split over multiple bursts to reduce the amount of overhead used in a single burst (i.e. in a 30 msec burst, the more of the burst that is devoted to the transmission of control information, the less of it that is available for the delivery of the substantive payload). The evidence about this needs to be attended to with some care. Hytera relied on three items of evidence to make good its submission. 253 The first was §39 of Professor Rangan's first affidavit where he said: This control information may include signalling information about each timeslot on each channel, such as whether the channel is presently supporting a call or transmission on each timeslot, for example as described on page 6, lines 28 to 30 of the AU 355 patent. 254 Later at §41, Professor Rangan also said that his explanation of the 355 Patent, including at §39, reflected his understanding as at July 2004. I therefore accept that it was part of the CGK in July 2004 that control information could be used in TDMA systems to indicate whether there was activity on a channel. It is important to be clear, however, that this did not involve a recognition that control information could be used to signal information about timeslot activity as part of a scanning methodology. 255 The second arose from the cross-examination of Professor Rangan. At T800.11, he was cross-examined to suggest that the CGK prior art systems did indicate information as to whether activity is present or not on each timeslot: MR BURGESS: Let's take a moment back. What I was putting to you originally – go back a couple of steps. The first proposition we discussed was that it was part of your background knowledge in July 2004 that the control information in a TDMA system included signalling information about each timeslot on the channel such as whether the channel is presently supporting a call or transmission on each timeslot. PROF RANGAN: Yes. I think that – yes. Prior art systems did indicate information as to whether activity is present or not on each timeslot. 256 Two things should be noted about this. First, the cross-examination was directed to eliciting an answer about information indicating timeslot activity rather than the use of an activity bit. As I have previously mentioned, whilst the illustrative embodiment for the 355 Patent used a 28 bit CACH message which contained an activity indicator bit for each timeslot (the A bits), the claims of the patent are not expressed in terms of an 'activity indicator' but rather, in terms of a 'first information'. On the other hand, it is clear that Professor Rangan's evidence was directed to information which indicated activity. 257 Secondly, the cross-examination did not linger on which prior art systems included information indicating whether activity was present on each timeslot. An untutored reading suggests that the Draft DMR Protocol included an activity indicator bit. For example, section 5.5 contemplated a 24 bit CACH message which included an activity bit: The CACH exists on the outbound channel only. This field provides framing and access information for the bursts as well as low-speed data. A subscriber unit that decodes the CACH can be assured that it has received an outbound transmission from a repeater or an RFSS. This channel is not tied channel l or 2 but is common between them. Of the 24 bits present in each CACH burst, 4 are dedicated to framing and indicators, leaving 20 bits for payload and FEC. … AT (Access Type) – Indicate whether the next inbound slot is busy or idle. 0 = idle on the inbound channel 1 = busy on the inbound channel TC (TDMA Channel) – Indicates whether the next inbound and outbound burst is channel 1 or channel 2. 0 = following outbound Burst is TDMA channel 1 1 = following outbound Burst is TDMA channel 2 … 258 It will be seen that the Access Type ('AT') bit is an indicator of whether the next timeslot is active or idle. However, as Motorola pointed out, at [62] of its written opening submissions, the Draft DMR Protocol did not concern itself with a scanning methodology. Thus, whilst I am willing to accept Professor Rangan's evidence that the prior art did include the use of control information which indicated whether there was activity on a timeslot, his evidence did not go so far as to suggest that it did so as part of a scanning method. 259 The only prior art otherwise referred to was the P25 Standard. I was not taken to any part of this to reveal the use of control information to indicate activity on a timeslot as part of a scanning method. 260 Hytera also relied on §57 of Professor Rangan's third affidavit. There it was said: In addition, because the P25 Standard is describing an FDMA system, this document does not describe a system in which a channel (i.e. RF frequency with additional qualifying information) is divided into timeslots. This is a significant distinction because in a TDMA system (as in the method of scanning described in the Relevant AU 355 Claims) any method of scanning must be capable of checking activity on multiple timeslots on each radio frequency. By contrast, a method of scanning in an FDMA system, which only has one user allocated to a given radio frequency, does not need to be able to check activity on multiple timeslots on each radio frequency. It follows that substantial changes would be required before implementing any method of scanning in a TDMA system based on the requirements of the FDMA system described in the P25 Standard, in order to enable a subscriber unit to check activity on multiple timeslots on each radio frequency. (emphasis added) 261 Again, I do not think this reveals the use of control information to indicate activity on a timeslot as part of a scanning method. 262 Into this picture must then be introduced the evidence of Mr Kuhrt under cross-examination at T776.41-777.30: MR MOORE: Yes. And so you will agree that at the time you came to do your hypothetical task, you were familiar with the short LC message in the 2005 standard. MR KUHRT: Yes. I don't remember specifically of - - - MR MOORE: Yes. MR KUHRT: But it doesn't really matter. I – I could have read it. Yes. MR MOORE: Yes. And including – you were familiar with the use of an activity bit as referred to in the standard. MR KUHRT: Yes. MR MOORE: Yes. And you would agree, wouldn't you, that the prior art prior to July 2004 had not used an activity bit as such? MR KUHRT: Not that I was aware of. MR MOORE: Yes. Now - - - MR KUHRT: But I would like to say - - - MR MOORE: Yes. Yes. MR KUHRT: The bits are used as, you know, there's things called flags in the software which are used to indicate all sorts of things. MR MOORE: Yes. MR KUHRT: So it's – it's common to use a flag or a bit to indicate different states of – of events. MR MOORE: Yes. But being specific to the issue here, that use of a bit, a one-bit, to indicate activity or no activity had not been used in the prior art - - - MR KUHRT: Not that I was aware of. 263 One therefore has this situation: Hytera sought to make good its case on this point based on the evidence of Motorola's expert, Professor Rangan, whilst Motorola sought to make good its case based on the evidence of Hytera's expert, Mr Kuhrt. Professor Rangan said that the prior art did indicate the use of information to indicate whether activity was present on a timeslot (T800.11) but Mr Kuhrt thought that nothing in the prior art had used a single bit to indicate timeslot activity: T777.27-30. It is not clear to me that Mr Kuhrt was speaking of the use of control information to indicate activity on a timeslot as part of a scanning method. Since the Draft DMR Protocol does include the use of control information in which a bit is used (outside a scanning method) to indicate timeslot activity, I am inclined to understand Mr Kuhrt's answer as a statement that the prior art did not indicate a method of scanning in which an activity bit was used as part of a scanning methodology. Mr Kuhrt was aware of the Draft DMR Protocol and to read his evidence otherwise would involve attributing to him an ignorance of that document which I am satisfied he did not have. 264 At a factual level, I therefore find that: (a) there was no prior art scanning method which included the use of an activity indicating first information as part of a control message; and (b) the prior art did include the use of information in a control message to indicate whether there was activity on a timeslot. In the Draft DMR Protocol, this took the form of an activity bit. However, this use of activity indicating first information did not form part of a scanning method. Scan Speeds 265 An issue with two-way radio systems as at July 2004 was that existing scan speeds presented a short delay for users. The scan speed issue was a known issue for analogue two-way radio systems and continued to be a known issue for conventional digital two-way radio systems such as APCO P25. In APCO P25 conventional two-way radio systems, the full LC message (i.e. the control message that provided addressing information for scanning purposes) was split over several bursts and could not be decoded immediately. This meant that mobile stations had to wait for the relevant information to be received and decoded before the mobile station was able to make a decision with respect to remaining on the channel. 266 As at July 2004, reducing scan time was generally considered desirable although the delay it engendered for users was only very short. It was a relatively low priority issue in July 2004. The P25 Standard 267 Although Hytera contended that the P25 Standard was part of the CGK or was s 7(3) information, in its closing submissions it did not develop any submission in relation to obviousness based upon the P25 Standard. While I accept that the standard is s 7(3) information, its significance would appear only to be that it involved the use of an LC message. The Draft DMR Protocol 268 As I mentioned earlier, the Draft DMR Protocol was discussed during a working group meeting at ETSI during the development of the 2005 DMR Standard. This was the unchallenged evidence of Mr Seedle who also explained that no one who was present at the meeting would have regarded the document as confidential. Mr Seedle also indicated that the document was thereafter shared and discussed in the industry. It is not surprising therefore that both Mr Kuhrt and Professor Rangan thought that the Draft DMR Protocol was a prior work which would have been located and read by a skilled addressee in order to understand what had already been developed in the field of two-way radios. Because it is a draft, it could not be regarded as part of the CGK, but given this agreement, it is plain that it is s 7(3) information. 269 In the manner in which Hytera pursued its case on obviousness in its closing submissions, the relevance of the Draft DMR Protocol arose from section 10 at page 63. This was in these terms: 10 LC Words Two example LC words are shown in Figure 10-1. Actual LC words will vary with circumstance and application. MFID (Manufacturers ID) – This is asserted when non-standard features are included in the voice message by the manufacturer E – Emergency indicator. Source ID – This identifies the transmitting subscriber unit Destination ID – This identifies the receiving subscriber unit in cases where the destination is a single subscriber. TG1D (Talkgroup ID) – This identifies the talk-group for the message in cases where the transmission is addressed to a group. 270 The example LC words are both 72 bits in length. Professor Rangan thought that a person of ordinary skill would have considered using the LC word discussed here for scanning purposes: T822.3-7. However, he did not think that it met the requirements of claim 1 since it did not have a 'first information', that is to say, it did not include an activity indicator: Joint Experts Report at Q11(c) ('JER'). Professor Rangan was cross-examined about this and he accepted, at T823.36-824.47, that the LC word in the Draft DMR Protocol had all of the features of claim 1 apart from the first information. Outline of Debate 271 Hytera's case on obviousness had two main limbs. In the first limb, Hytera submitted, as I have found, that it was part of the CGK that in TDMA systems, control information was sent to identify whether a physical channel was presently supporting a call or transmission on each timeslot. Hytera characterised this kind of control information as the 'first information' referred to in claim 1. Hytera submitted that it was CGK at the priority date that scanning messages could include identification information. Hytera submitted that this kind of information was the second and third information referred to in claim 1. Consequently, the invention disclosed in claim 1 was an obvious combination of two elements which already existed in the CGK: the first information was just an example of the use of information to identify activity on a channel; the second information was the kind of information found in LC messages such as those used in the P25 Standard. To make good this point, Hytera relied on the evidence of Mr Kuhrt. 272 In the second limb, Hytera submitted that the LC word disclosed in the Draft DMR Protocol had all of the integers in claim 1 apart from the first information. However, given that it was CGK that TDMA systems used control information which identified whether a physical channel was presently supporting a call or transmission on a timeslot, it followed that the first information in claim 1 was part of the CGK. Consequently, the invention disclosed in claim 1 was an obvious combination of these two matters such that the 355 Patent lacked an inventive step. To make good this point, Hytera relied on the evidence of Professor Rangan. 273 Motorola's response to this case was threefold. First, it denied that the combination of the first information with the second information in claim 1 was obvious and therefore not inventive and submitted that Mr Kuhrt's evidence that it was obvious ought not to be accepted. Secondly, it denied that the combination of the LC word in the Draft DMR Protocol combined with the first information, which was CGK, meant that the invention was obvious. It submitted that Professor Rangan's evidence did not establish to the contrary. Thirdly, it advanced its own identification of the inventive step. Turning then to the detail: Professor Rangan and Mr Kuhrt 274 Although submissions were advanced that Mr Kuhrt had more specialised expertise than Professor Rangan in the field of two-way radio communications, I did not regard this as a material consideration. Mr Kuhrt's First Method 275 At §211 of his first affidavit, Mr Kuhrt explained that he had been asked by Hytera's instructing solicitors to explain what, if any, scanning method he would have proposed if, at 26 July 2004, he had been asked to develop a conventional two-way radio system that improved the amount of time a radio spends scanning channels. At this time, Mr Kuhrt had not been provided with the 355 Patent. He gave evidence that in responding to this request, he took into account only information of which he was aware and which he regarded to be well-known and generally accepted in Australia in the field of two-way radio communications as at 26 July 2004. 276 In Mr Kuhrt's initial method, a repeater would regularly transmit a message (or burst) on the downlink frequency which would be received by the mobile station. The burst would contain a synchronisation pattern that enabled the mobile station to synchronise to the transmission. The synchronisation pattern would be present in the middle or at the beginning of each timeslot (or data frame) that was transmitted from the repeater to the mobile station: Kuhrt-1 at §213. 277 Mr Kuhrt would then carve out a portion of the payload in the latter half of the same burst and insert a scan message. The scan message would consist of: (a) information that distinguished between an idle frequency and an active frequency such as a data bit which indicated if the frequency was currently being used for a transmission or was idle; (b) identification information such as data bits that indicated the transmission source identification details and/or the talkgroup identification details; (c) information that provided encryption information if required; and (d) in a TDMA system, the design would also include information that indicates which timeslots on the frequency were active. 278 Mr Kuhrt thought that the scan message would speed up the automatic scanning process because it would provide the mobile station with all of the necessary information in a single burst. By doing so, the mobile station would not need to decode other bursts in the data stream to determine if it should remain on the frequency. The addition of a complete scan message, as part of every frame, would remove the need for mobile stations to wait on a frequency to receive additional bursts. The method would therefore be faster than a system which required the decoding of multiple messages in order to determine whether to remain on the frequency. 279 Mr Kuhrt would have located the scan message after the synchronisation pattern. Doing so would have permitted for both synchronisation and interrogation of the transmission to determine if it was valid within the same timeslot. As a result, after a mobile station received the synchronisation message, it would then be able almost immediately to locate and process the scan message. This would improve the amount of time that it took to scan frequencies automatically because it would avoid a scenario in which synchronisation occurred in one burst and where the mobile station would then have to wait for another burst to receive the scan message. Mr Kuhrt illustrated his method this way: 280 Mr Kuhrt thought this design was a 'simple solution' (at §222) to improve the speed and efficiency of automatic scanning. At the priority date, he would have expected that both he, and other engineers working in the field of two-way radios, could easily have implemented the method using routine software coding as only minimal software changes would be required. In his second affidavit, Mr Kuhrt said that his design had all of the features of claims 1 to 6 and 10 of the 355 Patent: Kuhrt-2 at §73. In Kuhrt-2 at §138ff, he explained that he did not think that claims 1 to 6 and 10 of the 355 Patent involved any ingenuity. In his view, it was well-known and accepted in the field as at 26 July 2004 that: (a) control messages were used in automated scanning to enable mobile stations to make determinations about whether channels contained active transmissions of interest to the terminal. He instanced the MPT1327 and APCO P25 systems as examples where this was the case (Kuhrt-2 at §§140-141); and (b) control messages could be used to inform a terminal whether there was activity on the channel: Kuhrt-2 at §146. Professor Rangan's Criticisms of Mr Kuhrt's First Design and Mr Kuhrt's Response 281 In his third affidavit, Professor Rangan expressed his view that he would not have proposed Mr Kuhrt's design as a solution to the task set for him by Hytera's instructing solicitors. That is to say, he did not consider Mr Kuhrt's design to be a 'desirable or viable solution': Rangan-3 at §§87-91. Professor Rangan had four substantial criticisms of the method. Overhead 282 Professor Rangan thought that the method would result in a large amount of overhead being included in each burst. In particular, he felt that because the scan message included the identification information for the transmission source and the talkgroup or destination, this would require a large number of data bits to be encoded in each burst, which would comprise a large portion of each burst. He explained, as an example, the consequences of the method under the Draft DMR Protocol. In that protocol, the LC message contained data that uniquely identified the transmission source and talkgroup or destination. It was 128 bits in length in which 56 bits were for error correction. He observed that this would be approximately 50% of the payload size in a TDMA burst under the Draft DMR Protocol which was 216 bits. Indeed, to avoid such a large consumption of the payload, the Draft DMR Protocol described transmitting the full LC message over seven bursts. Splitting it up in this way reduced the amount of payload which had to be sacrificed to control data in each burst. Professor Rangan thought, in consequence, that Mr Kuhrt's method was not viable and that an improvement in scanning speed that came at the expense of payload would be a distinct disincentive to developing a new scanning mechanism. 283 Mr Kuhrt did not accept this criticism. He had three points. First, he began by observing that in his method he had not provided any details about the size of the payload or control messages. Since the Draft DMR Protocol was just a draft at this point, I incline to the view that Mr Kuhrt cannot, in principle, be criticised for not including such details since, at this point, there was, as yet, no standard. On the other hand, since it was known that the 2005 DMR Standard was in the pipeline, there may be a certain degree of unreality in formulating a scan method which would have been incompatible with the draft. I return to this issue later. 284 Secondly, Mr Kuhrt noted that Professor Rangan had assumed that his control message was the same in length as the full LC message in the Draft DMR Protocol (i.e. 128 bits). In his first affidavit describing his method, Mr Kuhrt had not specified what was in his control message other than in general terms (i.e. an activity indicator and identification information). He now explained in his third affidavit that his scan message would use 20 bits: Kuhrt-3 at §84. It was as follows: 285 This message included a single bit to identify timeslot activity ('TSA'), a single bit to identify if the next timeslot was active ('NSA'), a single bit that identified whether the payload was encrypted ('ENC'), 9 bits that are used to provide address information ('ADR'), and 8 bits of error correction ('CRC'). The TSA and NSA bits provided information which distinguished between idle and active frequencies. In relation to the 9 bits allocated to identification information, the Draft DMR Protocol, it will be recalled, provided 24 bits for the destination ID and 24 bits for the source ID for a total of 48 bits (for a unit to unit call), and 16 bits for TGID information where a group call was involved. Mr Kuhrt's control message is therefore quite a bit smaller than what, at that time, was to be found in the Draft DMR Protocol. 286 However, as Mr Kuhrt explained, 9 bits still provided for 512 unique identifiers or combination of bits (29=512). From this 512, he deducted one to be reserved for a broadcast function. Splitting the 511 remaining identifiers up, Mr Kuhrt reasoned that, for example, this could be configured for 31 talkgroups and 480 individual terminals (31+480=511). Mr Kuhrt noted that as at 26 July 2004, for a small to medium sized fleet with which he was familiar, the largest number of talkgroups was about 15 and the largest number of subscriber units was around 150. He did not say this but I infer from this evidence that a 9 bit ID field may not have been sufficient for a large fleet. However, that it could not be used in a large fleet does not deny that it could be used in a small or medium sized fleet. The existence of this possibility is relevant to assessing, in due course, Motorola's criticism that Mr Kuhrt's solution was not practical. 287 Thirdly, with Mr Kuhrt's revised 20 bit scanning message now in play, he did not think that deducting 20 bits from the payload in the Draft DMR Protocol was unacceptable. He noted that the control information for the Draft DMR Protocol was 72 bits. Using his 20 bit scanning message, this left 52 bits available for the remainder of the control information without in any way impinging on the payload. However, the Draft DMR Protocol also provided for there to be a synchronisation pattern of 48 bits within the control information. Mr Kuhrt now suggested that it was not necessary to use a synchronisation pattern of that size and that a 28 bit synchronisation pattern would suffice. His control message therefore consisted of 20 bits of scanning information and a 28 bit synchronisation pattern for a total of 48 bits. Even under the Draft DMR Protocol, this left 24 bits left over to be used for other purposes. Distinguishing Idle from Active Frequencies 288 It will be recalled that Mr Kuhrt's initial method included information which indicated whether the frequency (separate from the timeslot) was active. Professor Rangan took issue with the point of this. His point was that since the scan message included identification information, the entire message had to be decoded, and there was therefore no point in including such an indicator: Rangan-3 at §88(b). Using the identification information, the terminal would either conclude that there was an identification match, in which case it was obvious that the frequency was active, or it would not, in which case it would not matter. 289 In response, Mr Kuhrt explained that he had included the activity information 'to allow scanning mobile stations to quickly determine if a frequency is active without having to consider the addressing information': Kuhrt-3 at §98. This is an example of a negative criterion in operation – the time saving comes from the fact that once it is determined there is no activity there is no need to process the identification information. There is ambiguity in Mr Kuhrt's evidence about the difference between an indicator of activity on a frequency, and activity on one of the timeslots. However, neither Mr Kuhrt nor Professor Rangan appeared to be concerned about this at this stage and I will disregard it. In any event, in Mr Kuhrt's revised method, his 20 bit scan message (see above at [284]) does not include a bit to indicate activity on the frequency but only a bit to indicate activity on the timeslot i.e. the TSA. This issue appears, therefore, no longer to matter in relation to Mr Kuhrt's revised method. Timeslot Activity Indicator 290 Professor Rangan made the same criticism of the use of an activity indicator for the timeslots. Mr Kuhrt's response was the same. I accept Mr Kuhrt's evidence. Once the 20 bit scan message has been received, processing time can be saved if the first bit indicates there is no activity on the timeslot because there will be no need to compare the ID information bits. There was some evidence in relation to the addition of an activity bit to the full LC word which I discuss below at [317]. Both Professor Rangan and Mr Kuhrt thought that it would not have been logical to have added an activity bit to the full LC message because the saving in processing time would have been outweighed by the overhead costs of receiving and decoding the additional bit. I have considered whether this evidence may be applied to this situation. Whilst I suspect that it may, the question is not quite the same and I do not think I can conclude on the balance of probabilities that it does. Routine Software Changes 291 It will be recalled that Mr Kuhrt thought that this method could be easily implemented using 'very minimal software changes'. Professor Rangan disagreed. He thought it would have been desirable to implement the method in a way which was compatible with existing software 'which would have been developed to meet the requirements of previous systems or standards': Rangan-3 at §90. This would ensure that devices adopting the method remained interoperable with devices which used existing scanning technologies. Doing so might entail significant software changes and would require testing and troubleshooting. This was particularly so because the method proposed sending scan messages by carving out a portion of the payload which was quite different to the way in which the control messages had been transmitted prior to July 2004. 292 There is a degree of unreality about the position of both Mr Kuhrt and Professor Rangan on this aspect. As at the priority date, the only system using TDMA was TETRA and there was no ETSI standardised TDMA technology. Although an ETSI standard was in the offing at this stage, it found expression only in the Draft DMR Protocol which was, in truth, a draft. I would accept that Mr Kuhrt's method would be radically inconsistent with the Draft DMR Protocol. The idea of using a single burst of control information following the synchronisation pattern would have been impossible to make work with any system which was using the kind of system described in the Draft DMR Protocol. 293 It is also clear that Mr Kuhrt's solution is quite incompatible with the 1998 TETRA Standard if only because TETRA implemented a control channel. It will be recalled that TETRA split a 25 kHz frame into four timeslots. One multi-frame was comprised of 18 such frames, one of which was devoted to a control channel. 294 Part of the problem is that the argument that Mr Kuhrt and Professor Rangan have on this issue takes as its point of departure some form of software, not identified by either. Working out whether the software changes, which would need to be made to this unidentified software, would be significant (as Professor Rangan thought) or routine and straightforward (as Mr Kuhrt thought) is therefore a potentially meaningless enquiry. If the starting point is the 1998 TETRA Standard or the DMR Draft Protocol, then I accept Professor Rangan's evidence and, indeed, might go further and express some scepticism that Mr Kuhrt's method could ever be integrated into the then existing systems which had a radically different approach to control messages. I accept Professor Rangan's evidence that this might, at least in theory, be surmounted. However, I correspondingly accept his point that this would be a significant software undertaking as it would involve fitting into one system, two quite different approaches to control information. 295 On the other hand, if the starting point is that there is no pre-existing system and that the writing of the software takes place on a blank canvas, then I accept Mr Kuhrt's point that this would not have been especially difficult since the interoperability issues referred to by Professor Rangan would not arise. Conclusions on Mr Kuhrt's Revised Methodology 296 I conclude that Mr Kuhrt's revised methodology would have provided an improvement in scanning time which could have been used as a system suitable for small or medium size fleets. It would not have been suitable for large fleets. It is evident that the system would have included less forward error correction and smaller synchronisation patterns. Although Mr Kuhrt's initial method would have compromised call quality by reducing the payload, his revised methodology does not suffer from this vice. I am unable to assess the impact of the decreased forward error correction and synchronisation patterns on the utility of Mr Kuhrt's method. It was evident that Professor Rangan looked askance at this approach. But I am unable to find that Mr Kuhrt's revised method was unworkable for these reasons. There was no explicit evidence about the practical effect that these economies would have had on the operability of any such system. I accept that Mr Kuhrt's revised methodology falls within the claims of the 355 Patent (which was not disputed) and that the patent makes no stipulations about control message size, the size of synchronisation patterns, or the extent of forward error correction. 297 That said, having regard to the direction in which the Draft DMR Protocol was heading, Mr Kuhrt's revised methodology strikes me as being a very unlikely solution as at July 2004. To solve the relatively lesser problem of scan time by coming up with a methodology with diminished forward error correction and reduced synchronisation patterns (which was radically inconsistent with the direction in which the industry appeared to be heading) was possible, but it was most unlikely that anyone would have actually embarked on the search for such a method. Mr Kuhrt accepted that if he had been developing a new device at the priority date, he would have obtained the Draft DMR Protocol because it would have been instructive to him as to what was likely to become standardised in the future: MR MOORE: Yes. And if you working in Australia were interested in developing some new device at that time, presumably, you would have obtained this standard because it would have been instructive to you as to what was likely to become standardised in the very near future? MR KUHRT: Yes. MR MOORE: And you would be very interested in what's the technology being employed and how is that going to operate, and you would start thinking along those lines if you were going to be involved in any development task at that time? MR KUHRT: Yes. MR MOORE: Yes. And you mention in your opening paragraph there, there was little scope within the specifications to improve scan time. What you meant by that is that if you have a different mode of scanning it's not going to be consistent with the scan mode in the specification? MR KUHRT: Yes, if there was something that you're proposing that would be outside what was planned in the specification. Yes. MR MOORE: Yes. And you wouldn't have been engaged in any task of departing from the specification in that way; correct? MR KUHRT: Correct. 298 In my view, the problem of scan time was not a major issue and not one which the skilled addressee would have regarded as justifying such an approach to forward error correction and synchronisation patterns. Motorola's Submissions 299 First, Motorola emphasised that in a field such as two-way radio communications, it was a mistake to focus solely on a single problem such as improving scan speed: MCS(P) ch 2A at [80]. Every problem in the field had impacts on other problems. To take a neutral example, one could improve voice quality by enlarging the size of the payload in each burst but this would come at the expense of trimming the control information (or, more likely, slowing its delivery down by spreading it over a large number of bursts). One could increase the speed of decoding control messages by increasing the size of the control information, and thereby decreasing the number of bursts required for such information to be transmitted, but this would come at some cost to something else, for example, the size of payload. Within the control information, one could increase the size of the identification information but there is no such thing as a free lunch, and this would need to be made up somewhere else, for example, by making economies with the extent of forward error correction or the size of the synchronisation patterns. 300 Motorola denied, therefore, the legitimacy of the task which had been given to Mr Kuhrt. There was, on this view, no such thing as setting out to improve scan time as a technical task pursued in isolation. Any solution to the problem of improving scan time necessarily had to exist in a broader context of other technical constraints. By way of analogy, imperfect perhaps, it would be artificial to set the skilled addressee the task of designing the optimally safe motor vehicle without taking account of the real world facts that motor vehicles have to meet other problems too, such as fuel efficiency and cost. It might be obvious that constructing the motor vehicle out of titanium alloy would achieve this outcome, but it could not be ignored that no person designing a motor vehicle would do so given the weight and cost of the titanium solution. 301 Secondly, Motorola submitted that it was important to be alert to the perils of hindsight reasoning: MCS(P) ch 2A at [82]. Given that an activity indicator bit was present in the 2005 DMR Standard as part of a scan method of which Mr Kuhrt was aware, this was apt to have suggested to him, subconsciously, the idea of using such a bit in his methodology. At the very least, one needed to approach his evidence with some care given that context. Whilst Mr Kuhrt had said that he had only used what he knew at the priority date, the mental task of divesting oneself of certain knowledge in a question to identify the obvious was far from straightforward. I accept this submission so far as it goes. I do not think it proves necessarily that Mr Kuhrt's evidence about obviousness is to be rejected outright but it does require some circumspection in its assessment. 302 Motorola next submitted that Mr Kuhrt's revised method did not assist Hytera on its case on obviousness: MCS(P) ch 2A at [91]-[98]. It made five criticisms: first, the task which had been set for Mr Kuhrt was not a task that would have been attempted in the real world. The issue of scan time would never have been implemented in isolation but, for the skilled addressee, would only have arisen in the broader context of designing an entire two-way TDMA system. In such a context, the question posed for Mr Kuhrt would never have actually been posed. 303 Secondly, in any event, Mr Kuhrt's revised method involved reductions in the size of the ID information message to 9 bits (which meant it could not be used for large fleets), a reduction in forward error correction and a reduction in the size of the synchronisation patterns. Although I have not found it possible to gauge what degradation the last two matters would have had upon a system using Mr Kuhrt's revised method, I do accept that it is inevitable that they would have had some deleterious impact. No comment needs to be made in relation to Motorola's submission that Mr Kuhrt's first method reduced audio quality since his revised method did not lead to a reduction in the size of payload. 304 Thirdly, Motorola submitted that Mr Kuhrt's revised method was not obvious because it had not occurred to Mr Kuhrt at all. What had occurred to Mr Kuhrt was his initial method and it was only once Professor Rangan pointed out the difficulties which it entailed that Mr Kuhrt had formulated his revised method. Thus, the revised method was the result of him having been asked a highly artificial question by Hytera's instructing solicitors and having been prompted by Professor Rangan's criticism further to refine what he had done. As such, it did not reflect what a skilled addressee would have done at the priority date. 305 Fourthly, as I have already noted, Motorola pointed out that Mr Kuhrt's revised method used an activity indicator bit. This had been present in the 2005 DMR Standard, but not in the prior art as at July 2004. Mr Kuhrt accepted that he was aware of the 2005 DMR Standard: T777.3-6. Motorola therefore submitted that the clean slate approach Mr Kuhrt had endeavoured to take in relation to the formulation of his method (and then his revised method) was incurably affected by hindsight. 306 Fifthly, Mr Kuhrt was also aware, as a result of his familiarity with the 2005 DMR Standard, of the use of the shorter LC message. I accept, as Motorola submitted, that the shorter LC message in the 2005 DMR Standard is essentially the same as the 28 bit activity update message disclosed in the illustrative embodiment in the 355 Patent. Motorola submitted that it was therefore impossible to disentangle Mr Kuhrt's revised method from his knowledge of the use of a shorter LC message. I do not think that Mr Kuhrt's revised methodology was affected by hindsight in this regard. The one thing Mr Kuhrt's revised method does not use is a shorter LC message of the kind in the 2005 DMR Standard. To the contrary, its control message is effectively a full LC message. Hytera's Submissions 307 In its opening written submissions, Hytera had placed emphasis upon Mr Kuhrt's revised method to show that the claims of the 355 Patent were obvious in light of the CGK alone. It also advanced a submission that it was obvious in light of the P25 Standard and the Draft DMR Protocol. By the close of the trial, however, the role of Mr Kuhrt's revised method had retreated in prominence. Hytera did not, however, abandon its reliance on Mr Kuhrt's evidence. 308 The first point made by Hytera in its closing submissions was that what was required to be inventive was the invention as claimed. It was not enough that the illustrative embodiment disclosed in the body of the specification contained an inventive step if the claims themselves did not disclose that inventive step. Whilst I accept that: (a) the invention is defined by the claims which must be interpreted in light of the specification and the CGK; and (b) that the invention must involve an inventive step, I do not accept that it follows that the inventive step must itself be specified in the claims (if that is what Hytera intended). On the other hand, I do accept that the question is whether a method of scanning using a combination of a first and second information etc. is the invention whose inventiveness must be assessed. The question is not whether the use of the 28 bit CACH message described in the specification is inventive. 309 Hytera next submitted that the evidence showed that it was part of the CGK that control information was used in TDMA systems (HCS(P) ch 3 at [87]) to identify whether a physical channel (i.e. a frequency) was supporting a communication. It referred to Professor Rangan's evidence at T800.11-12 which I have referred to above. I accept that Professor Rangan's evidence does establish that the CGK included the use of control information to indicate activity on a timeslot. However, it does not establish, for the reasons I have given, the use of this control information as part of a method of scanning. 310 However, Hytera also submitted that Professor Rangan had accepted that if he had been designing a scan method before July 2004, he would have considered using the control information to indicate whether the timeslot was active or not: MR BURGESS: And so for the reasons we just discussed, the detection of the carrier presence alone will not inform the scanning mobile station whether a given timeslot is busy or idle; correct? PROF RANGAN: That's right. In general, it would not. MR BURGESS: Yes. Therefore, if you had designed a system to automatically scan at least the physical channels in a TDMA system before July 2004 you would have used control information to inform the scanning mobile station whether each timeslot was active or idle when a carrier was detected; correct? PROF RANGAN: That – that seems logical, yes. 311 I take this to be evidence that the inclusion of activity indicating information in a control message as part of a scanning method, is something which would have occurred to Professor Rangan as at the priority date. Whilst the prior art indicated that such control information had been used, it had not been used as part of a scanning method. However, Professor Rangan's evidence bears out Hytera's contention that the use of such information as part of a scanning method was obvious. Certainly, it was obvious to Professor Rangan. 312 Hytera also submitted that the use of addressing information as part of a scanning method was obvious in light of the CGK. Here, Hytera relied upon the Draft DMR Protocol's use of the LC message. It submitted that it had all the features of claim 1 apart from the 'first information'. I accept these submissions. Professor Rangan thought that the person of ordinary skill would have thought of using this message for scanning: JER at Q11(c). Further, he accepted under cross-examination that the LC message in the Draft DMR Protocol had all of the features of claim 1 of the 355 Patent apart from the first information: MR BURGESS: And you say there: However, he – ie, you – believe that the full LC does not meet the claims of the standard. In particular, it lacks a first information. Correct? PROF RANGAN: That's right. MR BURGESS: Yes. And that is the only sense in which the full LC messages disclosed in the draft email protocol do not meet claim 1 of the 355 patent. Correct? PROF RANGAN: By "only sense", if hypothetically one were to add the full LC out of first information that satisfied this claim and then practiced the scanning as was typically done, I think – I think it would - - - MR BURGESS: Yes. The method would be within the claim. 313 I accept this submission. Hytera's point was therefore that the use of the first information was obvious, as was the use of the second information. Consequently, so the argument ran, claim 1 was obvious. Motorola's Response and Conclusions 314 As Motorola observed in its closing written submissions in reply, it is apparent that Hytera had shifted its position somewhat by the end of the trial. Whereas it had opened the case on the basis that Mr Kuhrt's revised methodology showed that the invention was obvious, it had retreated from Mr Kuhrt somewhat by the close of the trial. Rather, by the end of the trial, its position was that Professor Rangan had accepted that the use of a control message, containing information indicating whether activity was present on the channel, was something which would have occurred to him at the priority date and had therefore accepted that the use of the first information in claim 1 was obvious. Further, he had accepted that the use of the second information was also obvious. 315 I do not accept Motorola's objection that it was unclear what design Hytera was putting forward. Whilst it was open to Hytera to seek to prove the lack of an inventive step by reference to the method composed by Mr Kuhrt, this did not prevent it from also relying on the evidence of Professor Rangan, if it could, to show that the invention was obvious. Hytera bore the onus of proving that the invention was obvious. As a matter of trial procedure, it was not confined, in seeking to discharge that onus, to rely solely upon the evidence of Mr Kuhrt. If it wished, it was entitled to rely upon the evidence of Professor Rangan too. 316 More substantial is Motorola's submission that Hytera's submission skated over the question of combining the first and second information in claim 1. Whilst it is true that Professor Rangan said that the full LC message had all the features of claim 1 apart from the first information, and that he would have considered using a first information as part of a scanning method, he also gave evidence that it would have been illogical to combine an activity indicator with the full LC message in the Draft DMR Protocol. Following the exchange between Professor Rangan and Mr Burgess extracted above at [312], Professor Rangan stated at T824.42-43: PROF RANGAN: It would – it would then – it would then – it would likely satisfy the claim. It wouldn't be a logical design, but it would likely satisfy ..... the claims. 317 Hytera's submission overlooks this evidence. Although it was obvious as part of a scanning method to use a first information to indicate the presence of activity, and it was obvious to use a second information of the kind which appeared in the full LC message, it was not obvious to give the full LC message an activity indicator because such a design would not have been logical. In re-examination, Professor Rangan explained why it would not be logical in these terms: MR MOORE: Professor Rangan, you were asked some questions a few minutes ago about the link control message possibly supplying the second information on the claims, call that, and the possibility of adding a first information to the link control message and in answer to the question you said it wouldn't be a logical design. Can you explain why you say it would not be a logical design? PROF RANGAN: Because while – if you took the current link control as the baseline and – we refer to, let's say, in the draft DMR or in the P25 standard and you added the first information, there would be potentially small benefit in reduction in scan time simply because you could process the – the message slightly quicker, but there would be no – that would be outweighed by the increase in overhead from adding that one bit because you already have the full information with the ID and other fields to determine all the characteristics about the activity of interest, so you're not getting the benefit of this. In fact, even – so there would – you would be kind of torn away – or maybe I shouldn't say torn away, but any reasonable designer would not choose to put in that bit at that time. MR MOORE: Yes, thank you. Mr Kuhrt, I don't know whether you were following that, but do you agree with that answer? MR KUHRT: Yes, you would – adding the extra bit would make it – message longer and therefore you wouldn't get any benefit of a - - - MR MOORE: Yes, thank you. I have no further questions, your Honour. 318 That is to say, the minimal increase in speed would be offset by the overhead from the extra bit. I accept this evidence and that a person of ordinary skill would not have sought to combine an activity indicator bit with the full LC message. In my view, Hytera's submission poses the risk identified in Alphapharm of dividing the invention into integers and then addressing the question of whether each integer was of itself obvious, rather than as a combination. 319 Thus, whilst I accept that it was open for Hytera to rely upon Professor Rangan's evidence to prove that the invention was obvious, I do not accept that his evidence does in fact do so. 320 This then directs attention to the question of whether Hytera has otherwise discharged its burden of proving that the invention was obvious. The only other way it sought to do this was through the evidence of Mr Kuhrt which it did not formally abandon even if its reliance upon it was somewhat muted. 321 Whilst I accept that Mr Kuhrt's revised methodology does theoretically implement claim 1, there are several reasons why I do not accept that it demonstrates that claim 1 was obvious. First, I am not persuaded that Mr Kuhrt's revised method is something which a person of ordinary skill would ever have put forward as a method of improving scan time. A solution which led to a reduction in synchronisation patterns and forward error correction and which was inconsistent with the Draft DMR Protocol, is not something which anyone in the field of two-way radios would have contemplated as being sensible as at the priority date. Whilst I accept, as Hytera submitted at [98] of its closing written submissions, that Mr Kuhrt's solution was viable, in the sense that it would actually work if anyone sought to implement it, I do not accept that it was plausible. As finally presented, it was a method which: (a) was inconsistent with the Draft DMR Protocol and hence with the direction in which the industry was heading. As Mr Kuhrt accepted at T767.13-24, what was likely to be standardised in the future was relevant to the design task; (b) involved reductions in the size of the synchronisation patterns and forward error correction as the price to be paid for solving what Mr Kuhrt described, at §33 of his third affidavit, as the 'relatively minor issue' of scan speed. The fact that the scan speed problem was regarded as a relatively minor issue means that it would be most unlikely that a design solution would be reached which involved, as the price to be paid for that solution, reductions in forward error correction, synchronisation patterns and incompatibility with what was likely to become the standard; and (c) was not suitable for large fleets. 322 Secondly, this unreality is itself a function of the fact that the question which Mr Kuhrt was asked was the wrong question. No person would have sought to create an improvement in scan time without this being done in the context of the design of an overall system. Indeed, Mr Kuhrt accepted that what he understood his task to be was to 'create the ultimate scanning machine': T770.39. As such, he did not consider weighing up advantages of his method against the disadvantages it might pose to other aspects of the device's performance: T770.30-34. One consequence of this is Mr Kuhrt's inevitable acceptance that the task he had been given was artificial and was not a task that he would be likely to have undertaken at the priority date: T771.22-26. Mr Kuhrt would not have embarked upon this task and I am satisfied that no other person of ordinary skill working in the field of digital two-way mobile radios would have done so either. 323 Thirdly, Mr Kuhrt's revised methodology suffers from the further vice of not only resulting from the wrong initial question but also of being infected with the views of Professor Rangan as to the deficiencies of the first methodology. Mr Kuhrt's final design was the result of an implausible technical task combined with the views of one of the other expert witnesses in the case. The first method would have resulted in reduced audio quality which makes it an unlikely candidate for something which the person of ordinary skill would have embarked upon. It is even less likely that having embarked on such a course that the person of ordinary skill would, without the interposition of Professor Rangan's criticisms, come up with the revised method. 324 Fourthly, I am not satisfied that Mr Kuhrt's scan methodology was not the result of his exposure to the 2005 DMR Standard. Whilst I do not doubt for a moment Mr Kuhrt's honesty in saying that he had only answered the question he was asked with the knowledge he had at the priority date, I am doubtful whether that was really possible. (This may be contrasted with a similar question under the 764 Patent where I later conclude that it has not been shown that Mr Kuhrt had actually seen the 2012 DMR Standard). 325 Therefore, I am satisfied that Mr Kuhrt's method is not something that a person of ordinary skill would ever have done. 326 Consequently, I do not accept that Hytera has demonstrated that the invention disclosed in the 355 Patent was obvious and therefore lacked an inventive step. 327 This disposes of Hytera's 'obviousness' case. Neither Professor Rangan's nor Mr Kuhrt's evidence establishes that the invention was obvious. Motorola's Identification of the 'Inventive Step' 328 Independently of Hytera's burden to prove that the invention was not obvious, Motorola in fact identified what it said was inventive about the invention. Since Hytera has not demonstrated that the invention was obvious, it is not necessary to assess whether Motorola's identified inventive step was in fact inventive. 329 For completeness, however, I record my conclusion that the identified step was inventive: 330 It is reasonably clear from the illustrative embodiment that one way of implementing claim 1 is to use a second information which is provisional and shorter than the full LC message. In the illustrative embodiment, this is achieved by making the second information contain characteristic information in the form of 6 bits: the D1 and D2 bits (voice/data), the I1 and I2 bits (individual/group), and the E1 and E2 bits (emergency/non-emergency). Together with the two 8 bit hashed IDs, which are compressed but provisional versions of the full IDs, these 22 bits constitute the second information. The activity bits, A1 and A2, constitute the activity indicators, that is to say, the first information. In the embodiment, it is plain that this arrangement permits the terminal to determine whether the activity is not of interest more quickly than it would if it remained on the channel to receive the full LC message. 331 As Hytera correctly observed at [94] of its closing written submissions, the combination of the first and second information in claim 1 is silent about the size of the control message. It also does not refer to the payload. Further, claim 1 does not refer to an activity update message or any requirement that the activity update message should be shorter than the full LC message. What is missing from claim 1 is any suggestion that the first and second information should be compressed or abbreviated in some way to achieve the improved scanning time. However, I do not accept that this prevents a finding that the invention involves an inventive step. For reasons I have already given, it is not necessary for the inventive step itself to be defined in the claims. It follows that Hytera's submission has no bearing on the question of obviousness. 332 When Hytera raised this in its closing written submissions, it elicited this response from Motorola in reply: HS [100] suggests that the inventiveness in the solution as characterised by Professor Rangan is limited to an embodiment, not the claimed invention. That is not correct. Professor Rangan indicated that the inventiveness of the combination of the first and second information was that it allowed the designer to compress the information in the control message; he explained an example in relation to the hashed ID and explicitly stated that the other embodiments disclosed in the patent demonstrated the same principle (see MS [102]). The entire discussion ignores the advantage of the claimed invention. The 355 Patent discloses a compressed means of conveying information for scanning, thus allowing for faster scanning. It departs from the prior art in significant respects. Mr Kuhrt would not have arrived at the solution. There is no evidence that anyone else would have. 333 What Motorola had said at [102] was this: Indeed, this illustrates the inventiveness of the claimed method. Conventional considerations taught against lengthening the control message by including an activity indicator. What had not been recognised was that the use of an activity indicator could permit the compression of other information, including (though not limited to) using a hashed ID rather than a full ID. That is because the presence of an activity indicator would allow the device to dispense with the "null ID", which was otherwise used in the case of no activity (or idle messages). Hashing the null ID would be unacceptable because it may no longer be identifiable as the null ID and accordingly would not fulfil its purpose. Consistently with this, Professor Rangan identified that what was clever was the idea in general of using first and second information (T807.1-3). He explained that the patent enabled the use of more compressed information than the Full LC message, not just because of the possibility of using hashing (although that was one embodiment), but because of the idea of using different types of "second information" (T792.24-T793.3; T807.9-34; T809.18-T810.46). In this respect, he and Mr Kuhrt were in agreement that the point of the patent was to reduce the number of bursts required before channel rejection (T782.41-46 (Kuhrt); T812.40-42 (Rangan)). 334 There are two elements to this somewhat dense submission. The first concerns the null ID. Professor Rangan gave this evidence at T792.33-793.3: PROF RANGAN: … Now, just to understand that, because I – it had not been discussed up to now, suppose you try to compress, for example, the full ID, say, using hash ID, hashing, but without the – in absence of using the first information. So in this – the issue that would arise is what happens when there's no activity on the channel. Now, in the event there's no activity, standard procedure is when you have the full ID to transmit what's called a null ID. A null ID is the reserved value, typically all zeros, which no actual subscribing unit would have as an ID. So no one will think that it's for them. So that's fine if you transmit the full ID. But if you hash it, as we talked about yesterday, there's a possibility that the hash of the actual user subscriber ID will match the hash of the null ID. In this case, you will – the subscriber unit will get a match on that compressed or hashed data in every time the base radio is transmitting to no one. And that would greatly reduce the ability to benefit from the reduction in scan time. On the other hand, by adding the first information, you avoid this problem, because that separately indicates that there's no activity, and then this situation doesn't arise, so that's really where the advantage is coming from in this case. Sorry. It's a bit long explanation. I hope that adds a little bit to the discussion. 335 So the point here is that it was not possible simply to apply a compression algorithm to the full LC message. The usual indicator of no activity, the null ID, might be rendered by the compression algorithm into something which was no longer the null ID. As such, it could not be relied upon, if compressed, to indicate that there was no activity. 336 Professor Rangan's evidence about this was at T809.14-811.35: MR BURGESS: Yes. I might approach it a different way, your Honour. Professor Rangan, you made some introductory remarks a little earlier today about what you saw as being part of the value of the invention described in the 355 patent. Correct? PROF RANGAN: That's right. MR BURGESS: And you referred to one value of the first information, which you said Mr Kuhrt had identified, which was that if you had the first information active, inactive, then you can just look at that first bit without considering the rest of the control information, if there's no activity. Correct? PROF RANGAN: That's right. MR BURGESS: Yes. So that's one benefit of the first information. But you then refer to a second benefit, which you linked to the hashing of the second information. Correct? PROF RANGAN: It wasn't linked specifically to hashing. It's linking to the concept of compressing information in general, having reduction in information in general. And I mentioned hashing as an example. MR BURGESS: Yes. So some form of data compression, which is either hashing or some other technique. Is that right? PROF RANGAN: Some other technique. Yes. MR BURGESS: Yes. PROF RANGAN: That's fair enough. MR BURGESS: Thank you. And you were – what you said, if I understood it right, was that you were hashing or otherwise compressing the identification information, and that enables you to get a smaller control message that can be sent more frequently. Correct? PROF RANGAN: Yes. But it could involve, just to be clear, you may not even involve the – hashing or compressing the ID would be - - - MR BURGESS: Yes. PROF RANGAN: - - - one way of getting it. But you could, for example, just not have the ID at all - - - MR BURGESS: Yes. PROF RANGAN: - - - and look at some other characteristic of it. MR BURGESS: Professor Rangan, I appreciate that. PROF RANGAN: Okay. Sorry. MR BURGESS: Would you agree that that was not the – those other arrangements were not the ones that you referred to in your introductory remarks. Correct? PROF RANGAN: No. I thought I said it – I – maybe I don't remember the exact words I said, but I – I think I said that it allows you to – the concept of the patent allows you to compress the information. And then I said, for example, consider the case of compressing the ID. MR BURGESS: Yes. And your point was if compress the ID, unless you have the first information, there's a possibility that the subscriber unit may mismatch where there's no activity. Correct? PROF RANGAN: That's right, in that example. Correct. MR BURGESS: Yes. And I think you were intending to convey that that was a key advantage that you saw in the embodiment described in the 355 patent that uses the hashing. Correct? PROF RANGAN: The key advantages – just so I'm clear, and maybe we're saying the same thing. The key advantages allows compression in general and so, for example, in the particular case of hashing, it has disadvantage. But it would have it in other cases, as well, other types of compression that maybe are not even associated with the ID. MR BURGESS: Yes. Would you pardon me one moment. PROF RANGAN: Sure. MR BURGESS: Yes. And just to be clear, in addition to the first benefit of the first information we've talked about separately, the point you were making is that the first information addresses the problem of hashing or compression of the second information leading to a potential mismatch where there's no activity. Correct? PROF RANGAN: In that example. Correct. MR BURGESS: Yes. Thank you. And what I was putting to you is that when you say that this 355 patent is clever, that is a key part of what you perceive as being clever. Correct? PROF RANGAN: It's an example of – I'm just – I – I just don't want to say "key", because I think you might – I might be being unclear, because you might think that the key is associated with hashing. And I'm ..... trying to say that the – a benefit that arises from the patent is that – and a very – a valuable benefit that arises from the patent is that you can compress information in general of which hashing is a particular example. MR BURGESS: Yes. Thank you. And of which other compression techniques could be used an alternative. That's your point. Correct? PROF RANGAN: Yes. MR BURGESS: Thank you. So could I ask you now, please, to turn to claim 1 of the 355 patent. PROF RANGAN: Sure. MR BURGESS: Now, I think you agreed yesterday that claim 1 does not refer to the hashing of any data contained in the control message. Correct? PROF RANGAN: That's right. Hashing doesn't appear here. MR BURGESS: Yes. And claim 1 also doesn't refer to any other compression of the data contained in the control message by other techniques; correct? PROF RANGAN: No, it doesn't have, for example, the word "compression" in it. 337 So the claimed advantage of claim 1 is that it permits the skilled addressee to compress or abbreviate in some way the second information. What permits this to occur is the use of the activity indicator constituted by first information which effectively takes over the role of the null ID and permits what could otherwise not occur, namely, the compression or abbreviation of the full LC message. 338 It is true that claim 1 does not require the second information to be compressed or abbreviated in this way as Professor Rangan accepted. Indeed, Motorola did not contend for a construction of claim 1 which required the first and second information to be shorter than the full LC message because claim 1 does not mention the full LC message or even a concept like it. Further, whilst there is a reference to a LC message in claim 7, Motorola did not develop a construction argument which saw the first and second information in claim 1 as being shorter than the LC message in claim 7. The illustrative embodiment, and in particular Figure 3, does involve an implementation of claim 1 and claim 7 in which the second information of claim 1 is compressed (by hashing the SUID or TGID using a compression algorithm) or abbreviated (by the use of the D, I and E bits) or both and, it is true, that as such, they are in fact shorter than the LC message of claim 7 as it is embodied in the illustrative embodiment. But this shortening is not in terms required by the patent. Nevertheless, in light of Professor Rangan's evidence, the person skilled in the art would not implement the invention disclosed in claim 1 without the use of some form of compression of the second information. The insight of the patent is that the first information permits this to be done whereas before it could not. 339 Was it inventive as a scanning methodology, to use information which indicated whether activity was present on the channel together with information which indicated whether the transmission was of interest to the subscriber unit? The important point seems to be this: the presence of the activity indicator (the first information) permits what could not be done in the prior art, namely, the compression or abbreviation of the full LC message. Without the first information, compression of the full LC message gives rise to the possibility of the null ID being compressed to a form which is no longer the null ID. 340 Where the claimed inventiveness relates to the potential for an arrangement that permits the compression of the second information, I am not persuaded that such a solution was at all obvious either by reference to the CGK or s 7(3) documents. Certainly both concepts existed in the prior art, but they had not been combined in a way which proffered to the person of ordinary skill the further potential for compression or abbreviation. The inventive step is realising that the use of the first information to indicate activity would then allow compression or abbreviation. 341 Hytera submitted that the consequence of the fact that claim 1 did not impose any limitations on the size of the control message or the payload meant that it could be implemented in a variety of ways including Mr Kuhrt's proposed method. However, the fact that the claim can be implemented without regard to the size of the control message or payload does not impact on whether the inventive step identified by Motorola is present. The nominated inventive step is that the combination of the first and second information provided the person of ordinary skill with the potential to make the first and second information shorter than the full LC message. This it certainly does. Whilst framing the inventive step in terms of the potential it gave the person of ordinary skill to do something that the patent did not require may perhaps bring into question the utility of the invention, it does not provide a basis for inferring that an inventive step was not involved. The insight is the one identified by Professor Rangan – the activity indicating first information solves the problem that the full LC message could not be compressed because of the problem presented by the null ID. 342 The first information, it is true, existed in the prior art, but had not been used as part of a scanning method. The second information existed in the prior art as well. But it had not been grasped that combining the first and second information in a scanning method would give rise to the possibility of compression or abbreviation of the identification information. Had it been necessary, I would therefore have accepted Motorola's identification of the inventive step. 343 In that circumstance, I do not accept that Mr Kuhrt's evidence demonstrates that claim 1 was obvious. I also reject Hytera's case that the invention was obvious in light of the evidence of Professor Rangan. Hytera's attack on the other claims was premised on the same point and fails for the same reasons: HCS(P) ch 3 at [101]. Voir Dire 344 Professor Rangan was cross-examined by Mr Burgess on the possibility of the LC message supplying the first information. I have referred to this above when referring to Professor Rangan's evidence that to do so would be illogical. Why it was illogical was then elicited by Mr Moore SC in re-examination at T830.1-16 (see above at [317]). 345 Mr Burgess then sought to ask Professor Rangan a further question which, as ultimately expressed, was in these terms at T831.31-33: MR BURGESS: And if ETSI decided that it wanted to obtain that benefit you referred to in having the first information in these LC messages it could have used part of those reserved bits for that purpose; correct? 346 Objection was taken to this course on the basis that Hytera had no procedural right to ask Professor Rangan this question since Mr Moore's question had been in re-examination. I accept this submission. The answer given by Professor Rangan at T832.17-44 was admitted on a voir dire basis pending my determination of this issue. It will not be admitted into evidence. Mr Burgess' subsequent attempt to ask Mr Kuhrt's a similar set of questions at T833.1-27 depends, for its efficacy, on the answers given by Professor Rangan and will be rejected for the same reason. Utility 347 Hytera's point here was a short one. Once it was accepted that claim 1 could be implemented without regard to the size of the control message or the payload, then it followed that the promise of the patent – an improvement in the time taken for scanning – need not be delivered. I accept that it is true that claim 1 can be implemented in the way suggested by Hytera. This is a consequence of Motorola not seeking to contend that any such limitations were present as a matter of construction. 348 An invention is not a patentable invention if it is not, so far as claimed, useful: s 18(1)(c). This requirement is two-fold. The claimed invention must do what it is intended by the patentee to do, and the end obtained must itself be useful: Ranbaxy Australia Pty Ltd v Warner-Lambert Co LLC [2008] FCAFC 82; 77 IPR 449 at [141]. Thus, the invention as claimed must attain the result promised by the patentee. This issue is to be tested against the breadth of the claim. 349 Hytera submitted that the promise of the 355 Patent was an improvement in the amount of time that a mobile station spends scanning a pre-programmed list of channels. Because claim 1 would permit the control message to be split over any number of bursts, including the 7 burst full LC message described in the body of the specification, there need not be any reduction in scan time at all. 350 Motorola submitted that both Mr Kuhrt and Professor Rangan agreed that it would be perverse to implement claim 1 using a second information which was longer than the prior art full LC message. I accept this submission. In relation to Mr Kuhrt, he gave this evidence under cross-examination: MR MOORE: And you wouldn't understand claim 1 of the patent as specifying the use of information that is longer than the full LC message. MR KUHRT: It depends on the construction. If it's within the construction of the claim, then I would still read it that way. MR MOORE: It's not the point of the patent, as you understand it, is it, Mr Kuhrt? MR KUHRT: It's not the point of the patent. MR MOORE: Yes. MR KUHRT: I agree. MR MOORE: And so you wouldn't read claim 1 as referring to information that was longer than the prior art LC message, would you? MR KUHRT: Again, it wouldn't be the point of the patent. MR MOORE: No, and that would be a perverse application of claim 1, wouldn't it, to use information that's longer than the prior art message? MR KUHRT: It would be a pointless application. MR MOORE: Yes. MR KUHRT: Because it's already there. Yes. MR MOORE: Yes. And you would agree, wouldn't you, that what the patent is disclosing to you is that whatever method or code word is used to convey full control information, including information about the message or about other control information, that you can use a shorter method by utilising particular criteria or particular information that is shorter than the full message. MR KUHRT: Yes. MR MOORE: And if you had this patent as at July 2004, you certainly wouldn't implement claim 1 by selecting a second information that was longer than the prior art LC message, would you? MR KUHRT: No, because you would be creating a system that would take longer to scan. MR MOORE: Yes. Yes. And you would agree that would be a perverse way of implementing claim 1? MR KUHRT: Yes. 351 Further, Professor Rangan gave evidence that any reasonable embodiment of claim 1 would not increase the number of bursts over whatever the base system was from which the skilled addressee was commencing. He said this at T811.43-812.3: MR BURGESS: Yes. And you also agreed yesterday that claim 1 does not require the control message to be split over any identified number of bursts; correct? PROF RANGAN: That's right. Although I think, as we were discussing earlier this morning, of course any – I think the terms used were "any – any reasonable embodiment" or the term "no unpointless" or "no un-perverse embodiment" wouldn't increase the number of bursts on whatever the base system you're starting but – yes. 352 Thus, whilst I accept that claim 1 on its proper construction does permit both a second information which is longer than the full LC message and the transmission of the second information in more bursts than existed in a base system, I do not accept that these would be reasonable implementations of the claim. As such, I do not accept that they are relevant to the question of utility. In Apotex Pty Ltd v Warner-Lambert Co LLC (No 2) [2016] FCA 1238; 122 IPR 17 at [169], Nicholas J observed: It is often said that the principle that a claim is bad if it is wider than what is useful is one that must be applied with great caution. As Blanco White explains at para 4–409: It follows from what has been said that it is often a convenient test of the utility of the invention contained in a claim to consider whether the claim includes forms of the invention which are not useful, but that this test must be applied with very great caution. The function of a claim is to delimit the monopoly given by the patent, not to give instructions for the working of the invention, and it is consequently not necessary that the claim should contain these instructions; even the body of the specification is required to contain only those instructions that the reader cannot supply for himself. It would be unreasonable to expect the claims to contain more. A distinction should accordingly be drawn between cases in which the invention claimed is not useful unless an additional feature or features be added to those claimed (the claim then being invalid), and cases where the qualifications and expedients necessary to make the article claimed work can be, and on a true construction of the claim are, left to the reader to supply for himself. Since in cases where the reader can make the thing work the courts tend wherever possible to construe claims as requiring him to do so, it is not in practice enough to ask whether the claim includes things that are not useful; it is necessary to ask also whether there is anything in the language of the claim positively pointing to some useless construction. The successful utility attacks are nearly always in cases of that sort. Examples are: where a claim specifies two alternative processes or constructions of mechanism, of which only one is useful; or the claim specifies the use of any of a group of chemical compounds, and it is not substantially true that all will work; or the claim includes a series of constructions, and only certain members of the series are useful; or more generally, the claim contains a limitation directed to a particular feature and further limitation of that same feature is needed for utility; or the feature needed for effective working is expressly made optional-as when it is added by a subsidiary claim. 353 In my view, this is a case 'where the qualifications and expedients necessary to make the article claimed work can be, and on a true construction of the claim are, left to the reader to supply for himself'. Consequently, I reject Hytera's challenge to validity on the basis of a lack of utility. MANNER OF MANUFACTURE 354 In its opening written submissions, Motorola identified the 355 Patent as a method of scanning which can be used in a TDMA system to reduce the time required for completing scan operations: at [5]. 355 Section 18(1)(a) of the Patents Act imposes a requirement that a claimed invention be a 'manner of manufacture' within the meaning of s 6 of the Statute of Monopolies 1623, 21 Jac 1 c 3. The general principles governing that question are set out in the High Court's decision in National Research Development Corporation v Commissioner of Patents (1959) 102 CLR 252 at 276-277. More recently, the High Court has affirmed and expanded those principles in D'Arcy v Myriad Genetics Inc [2015] HCA 35; 258 CLR 334 at 351. 356 It has been accepted in this Court that a computer-implemented invention will be patentable if, in substance, it constitutes an improvement in computer technology rather than a use of that technology: CCOM Pty Ltd v Jiejing Pty Ltd (1994) 51 FCR 260; Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150; 227 FCR 378; Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177; 238 FCR 27; Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2018] FCA 421; 130 IPR 387; Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202; 163 IPR 231 ('Aristocrat'); Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223; 164 IPR 1. I do not read Aristocrat as departing from any of the authorities which preceded it. An appeal in that case to the High Court was dismissed by force of s 23(2)(a) of the Judiciary Act 1903 (Cth) when the Court split 3-3: Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29; 96 ALJR 837. As such, the High Court's decision has no ratio decidendi and stands only for the proposition that the Full Court's decision stands. As a single judge, I am bound by that decision. What the Full Court is to make of the High Court's decision is another matter but the approach for a single judge is clear. 357 At [57] of its opening submissions, Hytera submitted that the 355 Patent was a computer-implemented invention which I accept and which I do not understand to be resisted by Motorola. Hytera's primary submission was that there could be no manner of manufacture where what is claimed merely involves the new use of a known thing for a purpose for which its known properties made it suitable: Commissioner of Patents v Microcell Ltd (1959) 102 CLR 232 at 249-250; NV Philips Gloeilampenfabrieken v Mirabella International Pty Ltd (1995) 183 CLR 655 at 663-664. It then submitted that the 355 Patent, as a matter of substance, was to be seen as being in the nature of a scheme, working directions or directions for use, rather than as an 'improvement in computer technology'. It did not involve or contribute to any new hardware or software. The patent was merely a method achieved by programming existing hardware to carry out specified steps. There was no claimed ingenuity in the manner in which the methods were to be implemented in the subscriber units, and the patent gave no guidance on how such implementation was to be carried out. In fact, the claimed ingenuity lay in the steps identified in the claims which were no more than a scheme or set of directions. 358 I do not accept this submission. The invention claimed is of the same quality as the curve drawing algorithm in International Business Machines Corporation v Commissioner of Patents (1991) 33 FCR 218 ('IBM'). The 355 Patent improves the way a particular class of computers – base stations and subscriber units – scan frequencies. The problem of the scanning speed is a problem of computer programming and is relevantly indistinguishable to the problem in IBM of curve drawing on computers. Curve drawing on computers required the use of processing-expensive floating point arithmetic. This kind of floating point arithmetic was expensive in terms of system resources. The solution in that case – the deployment of an algorithm which removed the need to use floating point arithmetic – resulted in an improvement in computer technology. The same is true here. The problem which existed was the problem of how to improve scanning times in a TDMA system. The solution was the use of an activity indicating first information which could permit the abolition of the null ID and therefore permit compression of ID information in the second information. To my mind, these are conceptually indistinguishable. The 355 Patent is plainly an improvement in computer technology. 359 I therefore reject Hytera's defence that the 355 Patent as claimed does not disclose a manner of manufacture. INFRINGEMENT Introduction 360 The 355 Patent involves method, not product, claims. The supply by Hytera of mobile stations and base stations therefore does not per se constitute a primary infringement of the patent since such an act does not involve using the method in the patent. Necessarily, therefore, Motorola put Hytera's liability on the secondary basis that by supplying the subscriber units and base stations for use together, Hytera had put end users in a position to infringe the patent by using the method. Secondary liability in such circumstances may arise under s 117 of the Patents Act and under the principles of authorisation and joint tortfeasorship. 361 Motorola's case on infringement differed as between Hytera's subscriber units and base stations which had not been reprogrammed and those which had. In relation to the former, the 'Updated Version of Hytera's Annexure C to its Outline of Opening Submissions' ('Updated Annexure C') classifies the allegedly infringing devices into three categories. Category 1 covers mobile stations that formerly used the short LC message while scanning and includes devices MD652/652G, MD782/782G, PD502, PD562, PD602/602G, PD662/662G, PD682/682G, PD702/207G (UL913), PD702/702G, PD712 EX, PD782/782G, PD792 EX, PD982/982G, X1e, X1p, X1p (UL913) PD502(UL913), PD562(UL913), PD602(UL913), PD662(UL913), PD682(UL913) PD712IS, and PD792IS. Category 2 covers repeater devices that sent the short LC message to Category 1 mobile stations and includes devices RD622, RD962, RD982, and RD982S. Category 3 covers mobile station devices that have never used the short LC message while scanning and includes devices PDC760, and PDC680. At this point, it is useful to note that the 'short LC message' refers to a control message in the 2005 DMR Standard that resembles the activity update message in the 355 Patent, including the use of an activity indicator and hashed ID information. As to the latter, Motorola alleges that Hytera's supply of reprogrammed base stations in a market where unreprogrammed subscriber units continue to be used makes Hytera liable on a secondary basis. 362 It is convenient to deal first with its case on infringement relating to unreprogrammed devices. Unreprogrammed Devices 363 There are three clusters of issues to be resolved: (a) whether an end user who uses an unreprogrammed subscriber unit with an unreprogrammed base station infringes the method of the 355 Patent; (b) the legal nature of Hytera's alleged secondary liability; and (c) the particular position of subscriber units known as the PDC760 and PDC680. Whether the Unreprogrammed Devices Use the Method of the 355 Patent 364 By the end of the trial, Hytera accepted that if the construction issues were resolved against it and the patent was valid, then the use of unreprogrammed subscriber units with unreprogrammed base stations would involve the use of the method of the 355 Patent. 365 There was an irrelevant debate as to whether the base stations infringed the method of the 355 Patent. In my view, neither the subscriber units nor the base stations by themselves infringe the method of the 355 Patent. What infringes the method is when the two types of devices are used together and the subscriber unit is set to scan mode. So much is clear from: (a) the evidence of Professor Viterbo who explained how the Hytera devices operated; and (b) the correct construction of the patent which I have previously explained. 366 Professor Viterbo gave evidence for Hytera about, inter alia, the manner in which the Hytera devices operated in relation to the scan function. This was contained in §5 of his Confidential Annexure EV-6. Motorola submitted, at [40] of their closing submissions, that this was indeed how the scan function operated on the Hytera devices and I therefore take this to be undisputed. Professor Viterbo's evidence was to the following effect: (a) The subscriber unit locates and synchronises with a TDMA channel (frequency and timeslot) from a list of channels in the subscriber unit's scan list. The subscriber unit does this in order to ascertain if there is any transmission of interest to the subscriber unit on that channel. (b) Once the subscriber unit is synchronised with the channel, it will look for and decode the CACH, which contains a "Short LC" message. The Short LC message includes the "Activity ID" and may also include a "Hashed Address ID" (which can be either a subscriber unit ID or a group ID). (c) If the Activity ID in the Short LC message indicates that there is activity on the channel, the subscriber unit will hash (i.e., compress) its own pre-programmed full Address ID and then compare the Hashed Address ID that is contained in the Short LC message with its own Hashed Address ID. (d) If the two Hashed Address IDs are different, the subscriber unit will switch to the next channel in its scan list. (e) If the two Hashed Address IDs are the same, the subscriber unit will stay on the channel and wait to receive the Full LC message. The Full LC message contains the full Address ID of the intended recipient(s) of the communication, which may be an individual subscriber unit or a talkgroup. (f) When the Full LC message is received, the subscriber unit will decode it and compare the full Address ID with its own pre-programmed full Address ID. If the full Address ID in the Full LC message is the same as the full individual ID of the subscriber unit, or the full ID of a talkgroup that the subscriber unit is part of, the subscriber unit will start receiving the data or voice in the transmission. If the full Address ID is not the full individual ID of the subscriber unit, or a talkgroup that the subscriber unit is part of, the subscriber unit will switch to the next channel in its scan list. 367 Once it is accepted, as I have, that under integer 5 of claim 1 a determination that activity is of interest does not have to be a final determination, then it follows that this method of the Hytera devices when used together infringes each of the integers of claim 1. The scanning method used by the subscriber units, as described above, embodies integers 1, 3, 4, 5 and 6, and the transmission of the short LC message by the base station embodies integer 2. 368 I therefore accept Motorola's submission that the base stations and subscriber units when used together infringe claim 1 of the 355 Patent. I did not understand it to be disputed by Hytera that if this were so, the devices also infringed claims 2 to 4. It did dispute that they infringed claim 5 but this turned on its interpretation of 'targeted' which I have rejected. I did not understand it to be in dispute, on this hypothesis, that claims 6 and 10 were also infringed. 369 I therefore accept, in principle, that Hytera's unreprogrammed base stations and subscriber units, when used together by an end user, infringe the method of the 355 Patent. By itself, this does not constitute a primary infringement by Hytera, for the person using the method is the end user and not Hytera. The question then becomes whether Hytera, by supplying end users with the devices, has a secondary liability to Motorola. The Nature of Hytera's Alleged Liability for the Infringements in Relation to the 355 Patent 370 The precise basis on which Motorola put Hytera's liability in relation to each device was set out in a document entitled Updated Annexure C. Motorola submitted that Hytera was liable on five bases: (a) s 117(2)(a); (b) s 117(2)(b); (c) s 117(2)(c); (d) authorisation; and (e) joint tortfeasorship. 371 It is convenient to consider the position of the subscriber units and base stations separately. Supply of Subscriber Units 372 Section 117 provides: Infringement by supply of products (1) If the use of a product by a person would infringe a patent, the supply of that product by one person to another is an infringement of the patent by the supplier unless the supplier is the patentee or licensee of the patent. (2) A reference in subsection (1) to the use of a product by a person is a reference to: (a) if the product is capable of only one reasonable use, having regard to its nature or design—that use; or (b) if the product is not a staple commercial product—any use of the product, if the supplier had reason to believe that the person would put it to that use; or (c) in any case—the use of the product in accordance with any instructions for the use of the product, or any inducement to use the product, given to the person by the supplier or contained in an advertisement published by or with the authority of the supplier. 373 Hytera submitted that 'the person' referred to in s 117(2)(b) (and I assume sub-s (c)) was the person to whom the product was supplied by the defendant. So construed, the provision could not apply where the supply involved an intermediary such as a distributor, dealer or wholesaler. I do not accept this submission. No doubt 'the person' referred to in ss 117(2)(b) and (c) is the same person who is referred to at the beginning of s 117(1) but that is quite a different proposition. Contrary to Hytera's submission, it is clear from the expression 'the supply of that product by one person to another' in s 117(1), that the person referred to in the opening words of s 117(1) need not be the same person as the 'another' referred to subsequently. If Hytera's construction were correct, 'another' would always mean the first mentioned person, i.e. it would mean 'that person' not 'another person'. This entails on Hytera's construction that the word 'another' is at least incongruous and more likely redundant: cf. the obiter remarks of Besanko, Foster, Nicholas and Yates JJ in AstraZeneca at [442]-[443]. Nor do I accept that Hytera's submission finds support in the Explanatory Memorandum for the Patents Bill 1990 (Cth) at [171] which merely parrots the Bill. Otiose constructions are to be avoided if possible. Here, the otiosity may be avoided by giving the word 'another' its ordinary meaning. 374 For completeness, an operation of s 117(1) which is inapplicable where supply chains are involved is not one which I would embrace unless I was advanced towards it at gunpoint. For the reasons I have given, it does not demand any such thing but, in fact, requires the opposite. Finally, Hytera submitted that the passage referred to above from AstraZeneca provided support for its construction because it 'may reflect a recognition of this issue'. It contains no such recognition. To the contrary, their Honours very much had in mind supply chains which can be seen by their explicit reference to supply chains at [443]. 375 Consequently, Hytera must confront the operation of the provision. Turning then to the evidence, the evidence of Ms Xu, a Product Manager at Hytera, established that the subscriber units were devices that fell within s 117(1). Ms Xu's evidence, at T153.28-154.18, confirmed the obvious i.e. that one would not use a base station without also using subscriber units, perhaps in the same way that one would not use a car wheel without a tyre: MR MOORE: And terminal devices and repeaters would normally be used together in a system. THE INTERPRETER: That can be yes. That can also be no. MR MOORE: Well, yes. Let's take them in turn. You wouldn't use a repeater without there also being terminal devices. THE INTERPRETER: Sorry, sir? Would that be - - - MR MOORE: You wouldn't use a repeater without there also being terminal devices in a system. THE INTERPRETER: Correct. MR MOORE: Yes. And it would be usual for a system to have a repeater in it, correct? THE INTERPRETER: Yes. MR MOORE: Yes. And a system that includes terminal devices and repeaters would usually be a system that is set up for a particular customer having regard to that customer's particular requirements. THE INTERPRETER: Yes. MR MOORE: Yes. And, just to clarify that, the systems that we're talking about here are standalone systems for particular customers. THE INTERPRETER: To set up for the customer? MR MOORE: I'm sorry, I didn't quite hear, Mr - - - THE INTERPRETER: To set up for the customer? MR MOORE: Yes, yes. THE INTERPRETER: Yes. (Ms Xu gave evidence with the assistance of an interpreter) 376 Extracts from Hytera's device manuals and product brochures confirm that Hytera suggested to its end users that they use the base stations with subscriber units. Further, Motorola led evidence, contained in vol 16 of the court book, about the contents of the manuals for the subscriber units. The instruction manuals included instructions about the use of the scan mode. If an end user uses a subscriber unit in accordance with those instructions, the unit will interact with a base station in a way which infringes the 355 Patent. 377 This conclusion engages s 117(2)(c). The use of the subscriber unit 'in accordance with any instructions for the use of the product' is a 'use' under s 117(2)(c). Consequently, being such a use, it is a 'use' by the end user of the kind referred to in s 117(1). Since the use of the subscriber unit in scan mode with a base station involves the method of the 355 Patent, it follows that Hytera is liable under s 117(1) through s 117(2)(c). Hytera did not in fact submit that it was not liable under s 117(2)(c), although in its submissions it did not highlight this position. This calculated obscurity can be seen from [41] of its closing submissions and from its Updated Annexure C. Both extensively refer to the many ways in which Hytera does not accept it is liable, for example, under ss 117(2)(a)-(b) or the principles of authorisation or joint tortfeasorship. However, they say nothing substantive about s 117(2)(c). 378 I also accept that Hytera had reason to believe that an end user would use a subscriber unit in scan mode with a base station in terms of s 117(2)(b). It provided advice on how to use the scan mode in the instruction manuals it provided for the subscriber units and, as I have mentioned, it suggested to end users that they should use base stations with subscriber units. 379 I do not think that doing so gave rise just to a risk that the end users would use the devices in an infringing way. It was not a risk; it was a near certainty since this was the predominant ordinary operation of the devices. End users who had base stations did not acquire subscriber units so that they could only use them in direct mode for to do so would be irrational. I conclude therefore that it was inevitable that end users would use the subscriber units with the base stations in a manner which infringed the 355 Patent. 380 It follows therefore that Hytera had reason to believe that its end users would use the subscriber units in scan mode with base stations. Put another way, Hytera had reason to believe that its subscriber units would be used in the manner which Hytera itself suggested that they should be used. That being so, the use by an end user of a subscriber unit in that fashion was a 'use' within the meaning of s 117(2)(b). Since that use by an end user would infringe the 355 Patent, it follows that the supply by Hytera to an end user of the subscriber unit constituted an infringement of the patent under s 117(1). 381 Hytera is not, however, liable under s 117(2)(a). The subscriber units could also be used in direct mode which would not result in infringement of the 355 Patent. For the reasons I give later in relation to the reprogrammed devices, I am also satisfied that Hytera is liable both as a joint tortfeasor and for authorisation. 382 Turning then to the position of particular kinds of subscriber units, Hytera made this submission in HCS(P) ch 4 at [41(c)]: (c) Various other instances in Motorola's Closing Attachment A where Motorola has: (i) Incorrectly asserted instructions have been given to use products in an infringing manner, when it is accepted by Motorola and/or there is unchallenged evidence that the products do not have (and have never had) the allegedly infringing feature; and (ii) Sought to draw inferences about the CPS that are not open to be drawn. 383 This perhaps unhelpful submission leaves the reader to work out what Hytera is talking about. Resort to the Updated Annexure C reveals that there are in fact only two such devices, the PDC760 and the PDC680. Hytera submitted that the unchallenged evidence was that these devices never used the short LC message and therefore their supply could not involve infringement. This was the evidence of Ms Xu in her fifth affidavit at §§5-9. I accept this evidence. 384 I therefore conclude that Hytera is liable for secondary infringement under s 117(1) by reason of ss 117(2)(b) and (c) for the supply of all of the subscriber units referred to in the document Updated Annexure C except the PDC760 and the PDC680. Supply of Base Stations 385 In my view, it is also clear that Hytera is liable in relation to the supply of base stations under s 117(2)(b). It had reason to believe that end users would use the base station in conjunction with subscriber units and that such subscriber units would utilise the scan function. This is the ordinary functioning of these devices. Whilst I accept that it is possible to use a base station with subscriber units which have had the scan function disabled, I do not think it likely that an end user who had acquired a base station would generally be intending to use its subscriber units in a way which did not involve that scan function. Were it otherwise, the purchase of the base station would be pointless. Although this may be possible in some circumstances (a mistaken purchase by an overzealous end user, for example), I do not think these circumstances would be common. The existence of such circumstances therefore provides no basis for concluding that Hytera did not have reason to believe that its end users might use the base stations with subscriber units with the scan function enabled. Consequently, Hytera is liable under s 117(1) through s 117(2)(b) for its supply of base stations as well. For the reasons I give later in relation to the reprogrammed devices, Hytera is also liable as a joint tortfeasor and for authorisation of infringement. Conclusions on Unreprogrammed Devices 386 Hytera is liable for infringement under s 117(1) for all of the subscriber units listed in the document Updated Annexure C apart from the PDC760 and PDC680. It is also liable for infringement under s 117(1) in relation to all of the base stations set out in that document. Reprogrammed Devices 387 After the commencement of these proceedings, Hytera reprogrammed its devices in an effort to ensure that they did not infringe any of the Patents, including the 355 Patent. The firmware giving effect to this aspiration became available from September 2018. Motorola is not, however, satisfied with this. It says that unreprogrammed subscriber units remain in circulation at the level of end users and that where a reprogrammed base station interacts with an unreprogrammed subscriber unit which is in scan mode, the method of the 355 Patent is utilised. 388 The basic problem is this: the reprogrammed base station still transmits the short LC message (i.e. the first information in integer 2 of claim 1) despite its reprogramming. Indeed, the reprogramming of the base station really has nothing to do with the 355 Patent and is directed at the other patents. Hytera's efforts to prevent infringement of the 355 Patent focussed instead on making sure that a reprogrammed subscriber unit would not use the balance of the method in claim 1 of the 355 Patent upon receipt of the short LC message (i.e. by ensuring that the subscriber unit did not perform all of integers 1, 3, 4, 5 and 6 of claim 1). In this regard, it has been successful for it is not in dispute that the reprogrammed subscriber units do not use the short LC message in a way infringes the 355 Patent. But the fact remains that when an unreprogrammed subscriber unit is used in scan mode with a reprogrammed base station, an infringement of the 355 Patent occurs. 389 Hytera's defences in relation to the reprogrammed devices are threefold. First, it denies that the supply of reprogrammed base stations can infringe the 355 Patent because the scan mode is performed on the unreprogrammed subscriber unit. Secondly, if the supply of the base stations otherwise would give rise to an infringement, it submits that it was obliged to make sure that the reprogrammed base stations transmitted the short LC message as it was required by ETSI standards. Thirdly, if that proposition is rejected, it says that it has taken reasonable steps to ensure that the reprogrammed base stations do not interact with unreprogrammed subscriber units. These steps consist of various measures designed to ensure that end users present their unreprogrammed subscriber units for reprogramming. 390 Motorola denies each of these propositions. In relation to the steps which Hytera says it has taken to ensure that unreprogrammed subscriber units in the possession of end users have their firmware updated so that they do not infringe the 355 Patent, Motorola says that the steps are insufficient. It propounds a somewhat sterner sets of steps which it says Hytera should now be ordered to take. 391 Four issues therefore require determination: (a) Does the use by an end user of an unreprogrammed subscriber unit with a reprogrammed base station infringe the 355 Patent? (b) If so, does the supply by Hytera of such a base station to an end user, who has in their possession unreprogrammed subscriber units, give rise to secondary liability in Hytera? (c) If so, is a defence nevertheless available to Hytera that it is entitled to supply reprogrammed base stations which transmit the short LC message because the transmission of that message is required by ETSI standards? (d) If not, what should the scope of injunctive relief be? 392 There is another issue in relation to all three Patents about additional damages which I deal with separately in Chapter XVIII. Does Use by an End User of an Unreprogrammed Subscriber Unit with a Reprogrammed Base Station Infringe the 355 Patent? 393 Because unreprogrammed base stations and reprogrammed base stations both transmit the short LC message, the interaction of either with an unreprogrammed subscriber unit inevitably leads to an infringement of the patent. Indeed, as Motorola correctly observed, there is no difference in terms of infringement by an end user between the unreprogrammed base stations and their reprogrammed successors. All that matters is that both transmit the short LC message. 394 Hytera submitted that its base stations did not infringe the 355 Patent because the scanning occurred on the subscriber units. I reject this submission which ignores both the fact that the claim is a method claim, and the fact that its particular method requires the use of two devices: a subscriber unit (integers 1, 3, 4, 5 and 6) and a base station (integer 2). Neither device infringes the patent because neither device is a method. What infringes the patent is an end user who uses the two devices together. Does Supply of the Reprogrammed Base Stations Give Rise to Secondary Liability in Hytera? 395 Motorola's asserted basis for liability is s 117(1), and the principles of authorisation and joint tortfeasorship. 396 Dealing first with s 117(1), I have rejected Hytera's submission above, that s 117(1) is not engaged where the end user acquires the device from an intermediary in the supply chain. Insofar as s 117(2)(b) is concerned, the question is whether Hytera, despite the steps it has taken, had reason to believe that the end user would use the reprogrammed base station with an unreprogrammed subscriber unit. In relation to s 117(2)(c), the question is whether the use of the reprogrammed base station, in accordance with any instructions on its use, would infringe the 355 Patent. 397 Assessment of both of those propositions requires one to consider the steps which Hytera has taken to require unreprogrammed subscriber units already in circulation to be presented for reprogramming. An assessment of the facts relating to this situation may be divided into those facts which Motorola says establish that Hytera has a secondary liability in relation to the supply of reprogrammed base stations, and those facts which Hytera says show that what it has done is sufficient to avoid that liability. Motorola's Factual Contentions about Secondary Liability 398 Mr Li was a Technical Director at Hytera Australia. He gave evidence about the chronology of events surrounding the release of the reprogrammed devices into the Australian market. His evidence showed that Hytera released the firmware for the reprogrammed devices in late 2018: Li-1 at §35. However, it was not until Monday, 25 March 2019 that it became the case that all the devices shipped from its Australian warehouse were the reprogrammed devices: Li-1 at §37. From 1 January 2019 to 25 March 2019, Hytera supplied 810 unreprogrammed subscriber units and 19 unreprogrammed base stations. Between 26 March 2019 and 30 November 2019, Hytera supplied 4,241 reprogrammed subscriber units and 107 reprogrammed base stations: Li-1 at §43. 399 Mr Li estimated that in 2019, 30-40% of the systems for which Hytera provided pre-sale support were intended to be sold to end users who had, and would retain, existing unreprogrammed devices: Li-1 at §55(b). 400 Commencing in November and December 2019, Hytera began taking steps to ensure that end users' existing devices were upgraded before reprogrammed devices were supplied: Li-1 at §72ff. I discuss these steps in the next section. 401 For the purposes of Motorola's secondary infringement case about the reprogrammed base stations, the critical element is that there continued to be end users of unreprogrammed subscriber units to whom these reprogrammed base stations were provided. Based on Mr Li's evidence, it is open to infer that 30-40% of the end users to whom reprogrammed base stations were supplied in 2019 had in their possession unreprogrammed subscriber units. It is also open to infer, and I do, that it is highly likely that in these cases, the use of the reprogrammed base station with the unreprogrammed subscriber units would have resulted in an infringement of the 355 Patent. Although it is possible that the subscriber units could have been used only other than in scan mode, this strikes me as distinctly unlikely. 402 However, this reasoning, at least in this form, only holds until November and December 2019, when on Mr Li's evidence, Hytera began taking steps to ensure that when reprogrammed devices were supplied to end users, their existing devices were also updated with the new firmware. To those steps it is now necessary to turn. Hytera's Factual Contentions 403 Hytera submits that it took seven steps to minimise the chance that a reprogrammed base station would be used in a manner which would infringe the 355 Patent: HCS(C) Mod I at [26]. These steps were that Hytera: (a) Undertook to Motorola not to exploit non-reprogrammed devices or supply non-reprogrammed firmware; (b) Entered into contractual agreements with 19 of its 29 dealers requiring them to upgrade the firmware on any non-reprogrammed devices in the possession of an end user before the dealer supplied that end user with any reprogrammed devices. Evidence was also given that Hytera intended to monitor compliance with these agreements; (c) Entered into a contractual agreement with its sole distributor, Logic Wireless, requiring it to use its best endeavours to ensure that it communicated with its dealers that any non-reprogrammed devices were to be upgraded before being supplied to an end user, and that end users' existing devices were to be upgraded to the latest firmware version before new devices were supplied. Under the same agreement, Logic Wireless also agreed to provide its dealers with access to the latest firmware, CPS, and other tools required to upgrade the devices; (d) Sent emails to its dealers and its sole distributor, Logic Wireless, regarding upgrading any non-reprogrammed devices in their possession to the reprogrammed firmware; (e) Completed an upgrade of firmware on non-reprogrammed devices held by Logic Wireless; (f) Implemented and maintained a system such that when it provided pre-sale support to its dealers or its sole distributor, it made enquiries as to whether the end user had existing non-reprogrammed devices and, if so, required an upgrade of the firmware on those devices; and (g) Updated the webpages and product manuals on its Australian website that refer to the use of existing Hytera devices to state that they 'should be upgraded to Hytera's iM or /S firmware before being used as part of a system'. 404 The evidence of Mr Li established these matters. I did not apprehend Motorola to dispute Mr Li's evidence. Rather its attack was focussed on whether the steps Mr Li described could be described as 'reasonable steps'. The principle mechanism by which it did this was to posit seven steps which it contended Hytera could have taken which would be more efficacious in preventing an infringement of the 355 Patent from happening: MCS(C) Mod I at [60]. These seven steps were as follows: (a) Hytera could contact the end user and the relevant supplier to ascertain whether the end user had any non-reprogrammed devices; (b) Hytera could provide a letter, approved by Motorola, to end users informing them that the use of a non-reprogrammed device with a reprogrammed device would result in an infringement of Motorola's patent; that the end user must upgrade the firmware in all non-reprogrammed devices in its possession before using them with a reprogrammed device; and provide instructions on how to upgrade the unreprogrammed devices; (c) Publish the same letter prominently on Hytera Australia's website and at trade shows; (d) Provide the letter to all suppliers with instructions that the letter is to be provided to end users prior to the sale of a reprogrammed device; (e) Include, in cases of direct sale to end users by Hytera, a contractual stipulation requiring non-reprogrammed devices to be upgraded; (f) Include, in cases of supply to suppliers, a similar contractual stipulation requiring the supplier to include the kind of contractual stipulation in (e) to the end user, and to provide the end user with the letter referred to in (b); (g) Use reasonable endeavours to monitor compliance with the contractual stipulations in (e) and (f). 405 Although Mr Li's evidence suggested that these steps were not practical, Motorola submitted that the cross-examination of Mr Li had shown this largely not to be the case. I accept that (a) would need to be modified to take account of the situation that a dealer is subject to confidentiality obligations not to provide information about an end user to Hytera. I see no difficulties with (b) subject only to the situation where Hytera is unable to obtain end user information from a dealer by reason of confidentiality concerns in which case this will prevent the sending of such a letter. I do not think that the purpose served by (b) is served by the fact that Hytera has updated its manuals to include instructions to upgrade any unreprogrammed firmware. This is because I accept Motorola's submission that there is no evidence that these updated manuals have been provided to the end users. 406 As to (c), I see no difficulties. 407 As to (d), I see no difficulties in Hytera obtaining information about the suppliers from its distributor, Logic Wireless, and hence no practical difficulty with this step. 408 As to (e), it appears to be the case that at the moment, Hytera does not have any contractual relationship with end users. This would appear to make (e) unnecessary. Motorola nevertheless pressed for it on the basis that Hytera might in the future have contractual relations with end users. In that regard, Motorola noted that Hytera has had contractual relationships with end users in the past. I accept Motorola's position. I see no reason why (e) could not be done. 409 As to (f), it appears to me to be difficult to insist that Hytera enter a particular kind of agreement with its dealers when its dealers are not bound to reach such an agreement. The evidence of Mr Li suggested, in relation to Hytera's efforts to get the dealers to agree to a contractual stipulation about the new firmware, that some of them had declined to do so. Mostly, this seems to be because the dealers did not want the fuss that would be involved in their updating of the firmware. Motorola thought that their position might change if more pressure were applied to them (as may have been the case with Logic Wireless which initially resisted the imposition of such a contractual provision). Even so, I do not accept that Hytera necessarily has the ability to make its suppliers behave in this fashion. 410 As to (g), I see no reason why this cannot be done. 411 I therefore accept that what Motorola proposes, except (f), could largely be done so long as the confidentiality obligations of its dealers were protected. Consideration of Hytera's Approach 412 So there are two competing versions of how the problem of reprogrammed devices interacting with unreprogrammed devices is to be handled. The fact that Motorola's proposal is largely workable does not prove that Hytera's approach is unreasonable. The question of whether Hytera's approach constitutes a reasonable attempt to prevent infringement from occurring turns on a consideration of its approach. Put another way, the question is not whether it can do more, it is whether it has done enough. 413 In substance, Motorola identifies three deficiencies only in Hytera's approach. First, it says that Hytera should have contacted end users directly. Secondly, it says that the terms of its letter to dealers, its distributor, its website, and to end users, needed to draw attention to the fact that the use of non-reprogrammed devices with reprogrammed devices would lead to patent infringement. Thirdly, it submits that more pressure should be brought to bear upon those dealers who did not agree to additional contractual stipulations. 414 While I accept that all of this could be done, I do not think that the steps Hytera has taken may be described as unreasonable. On the contrary, it appears to me that Hytera has made a genuine and reasonably far reaching attempt to ensure that when reprogrammed base stations are sold, any unreprogrammed subscriber units are brought in to be reprogrammed. It is likely, in my view, that what Hytera has done will remove any occurrences of infringement. I accept that isolated pockets of infringement may remain but I do not think that Motorola's scorched earth approach to the topic is proportionate to the extent of that problem. 415 Returning then first to s 117(1), I accept Motorola's submission that until Hytera began taking these steps in late 2019, it took no steps to avoid infringement. A significant proportion of end users who acquired a reprogrammed base station in the period between late 2018 and November 2019 would have had unreprogrammed base stations and in these cases, it is very likely that infringement would have followed. Hytera did nothing during this period to prevent that occurring. For the reasons I have given in relation to unreprogrammed base stations, I conclude that Hytera is liable under s 117(2)(b). I do not conclude, however, that it is liable under s 117(2)(c) as Hytera's manuals for the reprogrammed base stations include an instruction to upgrade the firmware for any existing devices. After 20 November 2019, I conclude that Hytera had no further liability under s 117. From that time, it had taken reasonable steps to prevent the infringement from occurring. 416 In relation to authorisation liability, I conclude that prior to taking the steps that it did in November 2019, Hytera countenanced the fact that end users would use unreprogrammed subscriber units with the reprogrammed base stations it was providing to the market. I conclude therefore that it is liable on the basis of authorisation. I reject Hytera's submission that Motorola was required to prove, and had not, that there was an act of primary infringement by an end user. Rather, it is sufficient that the Court may infer that infringements must have occurred: Cooper v Universal Music Australia Pty Ltd [2006] FCAFC 187; 156 FCR 380. Prior to November 2019, such infringements were inevitable. 417 However, after November 2019, Hytera took reasonable steps to prevent the infringements and I do not think that it can be said to have countenanced further infringing conduct. Consequently, after that time, it is not liable for authorisation. 418 In relation to liability as a joint tortfeasor, Motorola submitted that it was sufficient for it to show that Hytera supplied the reprogrammed base stations without taking reasonable steps to ensure that they were not used in the manner outlined by the patented method. On the other hand, Hytera submitted that Motorola was required to prove that it had acted with the end users in an enterprise pursuant to a common design as a result of which an act of primary infringement had occurred. In Ramset Fasteners (Aust) Pty Ltd v Advanced Building Systems Pty Ltd [1999] FCA 898; 44 IPR 48, the Full Court said at [41]: These authorities show that liability for infringement may be established, in some circumstances, against a defendant who has not supplied a whole combination (in the case of a combination patent) or performed the relevant operation (in the case of a method patent). The necessary circumstances have been variously described: the defendant may "have made himself a party to the act of infringement"; or participated in it; or procured it; or persuaded another to infringe; or joined in a common design to do acts which in truth infringe. All these go beyond mere facilitation. They involve the taking of some step designed to produce the infringement, although further action by another or others is also required. Where a vendor sets out to make a profit by the supply of that which is patented, but omitting some link the customer can easily furnish, particularly if the customer is actually told how to furnish it and how to use the product in accordance with the patent, the court may find the vendor has "made himself a party to the [ultimate] act of infringement". He has indeed procured it. So to hold is not in any way to trespass against the established line of authority which, as Dixon J made clear in Walker v Alemite, is based upon the need to confine a monopoly to the precise area in which it operates. That protects the mere vendor of an old product, though selling with knowledge of the purchaser's intention to infringe a combination patent; but it affords no excuse to the person who sets out to induce customers to do what falls fairly within the area of the monopoly. 419 By supplying reprogrammed base stations which transmitted the short LC message, Hytera did more than facilitate the infringement of the patent by the end users when reprogrammed base stations were used with unreprogrammed subscriber units. The end users were encouraged, until November 2019, to use the base stations with subscriber units in circumstances where a significant proportion of the end users would be deploying unreprogrammed subscriber units. In that sense, Hytera made itself a party to the act of infringement and is liable as a joint tortfeasor. However, it is not liable after November 2019 when it began to take reasonable steps to prevent this from occurring. The ETSI Defence 420 Hytera submitted that it could not supply the reprogrammed base stations without them transmitting the short LC message as this was required by ETSI standards (use of which was licensed by Motorola). This submission may be shortly despatched. The secondary infringement does not arise from the supply of the reprogrammed base stations. It arises from the supply into the market of such base stations where a substantial proportion of the end users have unreprogrammed subscriber units. The fact that I have found that Hytera has no secondary liability after November 2019 shows that it is not compelled to act in a way which leads to secondary infringement. It may continue to supply base stations which transmit the short LC message and not be secondarily liable. Motorola does not seek, and the Court would not grant, an injunction restraining the supply of the reprogrammed base stations completely. The infringement is not the supply of base stations which transmit the short LC message; it is the supply of such base stations to a cohort of end users with subscriber units which use the other integers in claim 1. I reject the defence. The Scope of Injunctive Relief 421 The appropriate injunctive relief is that Hytera should be ordered to take the steps which it has already taken together with a general injunction against infringing the patent (as is usual in patent cases). Hytera should not be ordered to take the additional steps which Motorola now desires to see taken. The reason it is appropriate that it be ordered to take the steps which it has already taken is because those steps are to an extent reversible, and I am not satisfied that, unless restrained, Hytera might not reverse them. V THE 764 PATENT INTRODUCTION 422 It will be recalled that the 355 Patent concerned the use of an activity indicator bit to indicate whether there was activity on a timeslot. The 2005 DMR Standard (which post-dated the 355 Patent) deployed such an activity indicator bit. The 2005 DMR Standard also provided for synchronisation patterns which were the means by which a subscriber unit would synchronise its clock to the base station's clock. The synchronisation patterns were located in a 5 msec interval midway through each 30 msec burst and each synchronisation pattern was a unique stream of bits of a fixed length of 48 bits. This is depicted in Figure 4.3 of the 2005 DMR Standard as follows: 423 A subscriber unit could monitor a frequency until it detected this unique 48 bit pattern. Once detected, it would know that it had found a synchronisation pattern because the chances of the same 48 bit pattern happening is extremely low. At that point, it would adjust its clock and therefore be in synchronisation with the repeater's clock. It was necessary for the subscriber unit to adjust its clock in this fashion because its internal crystal clock will move minutely out of synchronisation with the repeater's timing for a variety of reasons (such as age and temperature). At the divisions of time with which devices such as these are concerned, these minor drifts in timing are significant. 424 Once the subscriber unit was synchronised with the repeater, it became possible to know precisely when each of the 30 msec bursts would arrive. At that point, the subscriber unit could take advantage of the fact that in repeater based systems, the first 1.25 msec together with the last 1.25 msec of the next burst carried, under the 2005 DMR Standard, the CACH message. This is illustrated in Figure 4.5 as follows: 425 It will be recalled that the CACH message itself contained a bit which indicated which timeslot the 30 msec burst related to. By these means, the subscriber unit was able to know, following synchronisation, which timeslot was presently being transmitted by the base station. It could do this, however, only after it had received the whole of the CACH message and thereafter decoded it which was itself a time consuming exercise. This was because not all of the CACH message could be contained in the 2.5 msec devoted to it in each burst. Rather, it was transmitted over several bursts. Sufficient bursts to obtain the entire CACH message had to be received, and only once it was received in its entirety could be it be decoded. 426 The 2007 DMR Standard made some improvements to the 2005 DMR Standard in this regard. It will be recalled from the 355 Patent that the CACH message contained information about the kind of transmission which was taking place including whether the payload in the burst was a voice or data transmission. This was done by means of particular bits within the CACH message known as the activity update message. 427 The 2007 DMR Standard was able to communicate this information to the subscriber unit in a fashion which was faster. The means by which it achieved this involved the use of the synchronisation pattern. Whereas until now it has been useful to think of a synchronisation pattern as a unique 48 bit pattern whose significance is only that it is unique, the 2007 DMR Standard utilised the fact that the 48 bits which constituted the pattern were themselves a place in which useful information might be stored. The 2007 DMR Standard therefore provided for synchronisation patterns which could serve their primary function of acting as unique markers to assist in the process of time synchronisation with a base station whilst, at the same time, serving as a repository in which information could be stored. 428 The information which was stored in and conveyed by the synchronisation patterns in the 2007 DMR Standard was information about: (a) whether the transmission was a voice or data communication; and (b) whether the transmitting device was a base station or a subscriber unit. In other words: control information. 429 The 764 Patent built on the idea in the 2007 DMR Standard that control information might be embedded in the synchronisation patterns. Under the 2007 DMR Standard, the subscriber unit would know upon reception of the synchronisation pattern whether the payload was a voice or data transmission and whether it came from a base station or a subscriber unit. However, it remained necessary to decode the CACH message in its entirety. Until the subscriber unit received the whole CACH message and decoded it, and thereafter accessed the timeslot activity indicator bit in the CACH message, it could not know upon which timeslot the burst was being transmitted. The 764 Patent addresses this problem by providing for further synchronisation patterns which indicate the identity of the timeslot in which it is embedded. Once synchronisation has occurred, the subscriber unit knows immediately which timeslot it is receiving without having to wait to receive the whole of the CACH message over several bursts and then decoding it so as to ascertain the status of the activity indicator bit. Like the 2007 DMR Standard, the 764 Patent therefore uses synchronisation patterns to convey control information. What differs between the 2007 DMR Standard and the 764 Patent is the type of the control information that is conveyed. The 764 Patent augments the 2007 DMR Standard by adding timeslot identification data to the list of control information conveyed by a synchronisation pattern. One of the questions which arises is whether augmenting the list to add additional control information in the form of timeslot identification information is inventive. 430 However, the 764 Patent suggests using synchronisation patterns to identify timeslots in two quite different ways. The first is, as I have just indicated, as a mechanism in repeater based systems for faster timeslot identification. The second is not concerned with speed, but with a known limitation which existed in relation to subscriber units in direct mode. Under the 2007 DMR Standard, it was not possible for two subscriber units in direct mode to transmit on the same frequency at the same time. This was because in direct mode there was no transmission of the CACH message. Without the CACH message, there was no activity indicator bit and without that bit, it was not possible to know which timeslot was being received. The reason there was no CACH message was because under the 2007 DMR Standard, the CACH message was transmitted in the 1.25 msec intervals at the beginning and end of each 30 msec burst (for a total of 2.5 msec). In direct mode, in order to avoid timeslot interference, these two 1.25 msec intervals had to be reserved as guard time and were therefore unavailable to be used to transmit the CACH message. Thus a subscriber unit in direct mode could tell that it was receiving information from a timeslot, but it could not know which timeslot it was from. The consequence was that, unless some work around were formulated, subscriber units in direct mode could not share a frequency by using different timeslots simultaneously because they could not tell which timeslot they were on. 431 This limitation involved 'spectral efficiency', or rather, inefficiency. The inefficiency was that although the transmissions in such a TDMA system were divided into two timeslots, the fact that, in direct mode, only one subscriber unit could transmit on that frequency at one time meant that the other timeslot went unutilised. 432 The 764 Patent overcame this unavailability of the CACH message (and concomitant inability to identify the timeslot) by placing timeslot identification information in the synchronisation pattern. The construction question, which divides the parties, is whether the 764 Patent discloses two ways of doing this or just one. As to the one method which both parties agree is disclosed, the 764 Patent explicitly deals with the position of subscriber units in direct mode in claim 7. It is likewise clear, as I will explain shortly, that claim 7 is reflected in embodiment 6 of the specification. As will be seen in due course, claim 7 and embodiment 6 deal with a situation where each subscriber unit is confined to a single timeslot by an anterior act of allocation. Using the synchronisation patterns, the subscriber units are then able to: (a) tell whether their allocated timeslot is available; and (b) identify their non-allocated timeslot and adjust their timing by 30 msec to transmit on their allocated timeslot. Where subscriber units have different allocated timeslots, they are therefore able to use the same frequency together (but not if they have the same allocated timeslot). It is not suggested by Motorola that Hytera's devices infringe claim 7. 433 However, Motorola also says that claim 2 deals with the position of subscriber units in direct mode. It says that claim 2 discloses a second method in which, unlike the first solution, the subscriber units need not be assigned a timeslot in advance. In effect, it says that if one subscriber unit in direct mode is transmitting on, say, timeslot 1, then another subscriber unit in direct mode is able to work out that timeslot 1 is busy and that it should transmit on timeslot 2. Another way of saying this is that it provides for subscriber units in direct mode dynamically to change to the other timeslot in the face of activity on the first timeslot. Hytera denies that claim 2 describes such an invention. 434 The issues which arise between the parties are as follows: (a) The Construction Issue. Two issues arise in relation to the construction of the 764 Patent. First, Motorola submits that claim 2 (and therefore dependent claim 3) of the patent describes not only repeater-based systems, but also subscriber units operating in direct mode. Hytera denies this construction and submits that claim 2 only applies to repeater-based systems. Secondly, assuming claim 2 does apply to subscriber units in direct mode, Motorola contends, and Hytera denies, that it provides for a method of dynamic switching between timeslots; (b) The Fair Basis Issue. Hytera submits that if claim 2 does disclose such an invention, then nothing in the specification indicates that this is what the 764 Patent is concerned with. It therefore submits that the invention is not fairly based on the matter described in the specification to the patent. This is denied by Motorola who submits that it is adequately disclosed in one of the consistory clauses; (c) The Inventive Step Issue. Hytera submits that the 2007 DMR Standard had already uncovered the idea that a synchronisation pattern might be used to convey control information. All that the 764 Patent did was to use that insight in an analogous way now to convey different control information, viz, timeslot identification information. Hytera submitted that Mr Kuhrt's evidence showed that the invention lacked an inventive step. He had been asked to come up with an invention, as at the priority date, which permitted subscriber units in direct mode to communicate on a single frequency using both timeslots. He came up with two designs. The first assumed that the subscriber units were allocated to a particular timeslot. He formulated a method, not entirely unlike claim 7 and embodiment 6, which permitted them to use both timeslots. His solution turned on the use of synchronisation patterns to identify the timeslots. He also came up with a second design in which subscriber units were not allocated to a particular timeslot. Under Mr Kuhrt's second design, the subscriber units were able dynamically to switch between timeslots when the timeslots were busy. This second design of Mr Kuhrt's involved the use of talkgroups and synchronisation patterns, but not to identify timeslots. Hytera submitted that Mr Kuhrt's former design showed that it was obvious as at the priority date to use synchronisation patterns to identify timeslots. Motorola denied the soundness of Mr Kuhrt's evidence. It submitted that the latter solution was impractical and therefore not obvious; that unlike claim 2, it did not use synchronisation patterns to identify timeslots as part of a method of dynamically switching timeslots; and that it was more obvious to solve the problem using a 'supplemental control channel'. Motorola also submitted that the problem of timeslot identification in direct mode was a problem which the industry had long been striving unsuccessfully to solve which was said to be secondary evidence that the solution to it was not obvious. (d) The Infringement Issue. This issue only arises if Motorola's construction is correct and the patent is valid. 435 My conclusions are that Motorola's construction of the 764 Patent is wrong. If it had been the correct construction, however, I would have concluded that claims 2 and 3 were not fairly based and that the patent was invalid. If it had been necessary to consider the question of inventive step, I would have concluded that the idea of using synchronisation patterns to convey timeslot information as part of a method to allow dynamic switching between timeslots was inventive. It is not necessary to deal with infringement given these conclusions. CONSTRUCTION The Construction Debate 436 The dispute between the parties concerns the construction of claim 2 (and dependent claim 3). There are two questions. The first of these is whether claim 2, properly construed, concerns only repeater-based systems, or whether it also encompasses subscriber units communicating in direct mode. Related to this question was a further matter: whether the term 'desired timeslot' was synonymous with 'rest timeslot' or whether it could mean something else. As I understood the parties' submissions, this matter was relevant for two reasons. First, because rest timeslots are a feature only of repeater based systems, a conclusion that 'desired timeslot' meant 'rest timeslot' reinforced the conclusion that claim 2 was directed to repeater based systems only. Secondly, in any event, because the Hytera devices were not programmed to address 'rest timeslots', if 'desired timeslot' meant 'rest timeslot', the Hytera devices would not infringe claim 2. 437 The second question arises only if Hytera's position on the first is rejected. This question is whether claim 2, properly construed, disclosed an invention of 'timeslot switching'. The answer to this question involves a careful consideration of each of the 'knowing, preparing, determining, selecting and transmitting' steps of claim 2, and in particular, a consideration of whether those steps disclose a process by which a device determines whether a timeslot was available and switches to another where it is not. 438 What follows is not straightforward. The Claims 439 As I have outlined above, the dispute between the parties turns on claim 2 (and claim 3 which is dependent on claim 2). However, a correct understanding of the structure of the patent cannot be grasped without appreciating claims 1 to 7 which are as follows: 1. In a time division multiple access (TDMA) system having a plurality of timeslots, a method comprising the steps of: tuning to a frequency in the system; searching for a desired set of synchronization patterns on the frequency, each of at least two slots on the frequency out of n slots used on the frequency having a set of synchronization patterns that are mutually exclusive of each other and of other sets of synchronization patterns used in the system on the frequency, and each set comprising at least two different synchronization patterns as a function of a payload type; and if one of the synchronization patterns belonging to the desired set of synchronization patterns is detected on the frequency, synchronizing to a timeslot in which the synchronization pattern was detected and receiving information corresponding to the indicated payload type. 2. In a time division multiple access (TDMA) system having a plurality of timeslots, a method comprises the steps of: knowing a first set of synchronization patterns associated with a desired timeslot and a second set of synchronization patterns associated with each of the other timeslots in the TDMA system, wherein the first set of synchronization patterns is mutually exclusive from the second set of synchronization patterns, and each set comprising at least two different synchronization patterns as a function of at least one of a payload type and a source of the transmission; preparing to transmit a particular payload type in a timeslot; determining whether the timeslot is a current desired timeslot for the TDMA system; if the timeslot is the current desired timeslot, selecting a synchronization pattern selected from the first set of synchronization patterns based on the one of the particular payload type and a particular source of the transmission; otherwise selecting a synchronization pattern selected from the second set of synchronization patterns based on the one of the particular payload type and the particular source of the transmission; and transmitting a burst in the timeslot having embedded the synchronization pattern that was selected. 3. The method of claim 2 wherein the current desired timeslot at a first time is different than the current desired timeslot at a second time. 4. The method of claim 2 wherein the other timeslots each have a set of synchronization patterns associated therewith, and each set of synchronization patterns are mutually exclusive of each other. 5. In a time division multiple access (TDMA) system having a plurality of timeslots, a method comprising the steps of: selecting a channel having a desired frequency and a desired timeslot, wherein each timeslot has a set of synchronization patterns associated therewith, each set of synchronization patterns are mutually exclusive of each other, and each set of synchronization patterns comprises at least two different synchronization patterns as a function of at least one of a payload type and a source of the transmission; tuning to the desired frequency; searching for synchronization patterns associated with each of the plurality of timeslots on the desired frequency; if one of the synchronization patterns is detected on the desired frequency, synchronizing to a timeslot that is associated with the synchronization pattern that was detected; and if the desired timeslot does not match the timeslot that is associated with the synchronization pattern that was detected, adjusting timing to decode the desired timeslot. 6. The method of claim 5 further comprising the step of detecting a carrier presence on the desired frequency prior to the step of searching. 7. In a time division multiple access (TDMA) system having a plurality of timeslots, a method of attempting to initiate a transmission on a desired frequency and a desired timeslot, the method comprising the steps of: detecting a carrier presence on the desired frequency; searching for synchronization patterns associated with each of the plurality of timeslots on the desired frequency, wherein each of the plurality of timeslots on the desired frequency has a set of synchronization patterns associated therewith, and each set of synchronization patterns are mutually exclusive of each other; if one of the synchronization patterns associated with the desired timeslot is detected on the desired frequency, denying the transmission; if none of the synchronization patterns associated with any of the plurality of timeslots are detected on the desired frequency, denying the transmission; and if none of the synchronization patterns associated with the desired timeslot are detected on the desired frequency, but at least one of the synchronization patterns associated with any of the other timeslots is detected on the desired frequency, synchronizing to a timeslot associated with one of the synchronization patterns that was detected, and adjusting timing in order to transmit the transmission in the desired timeslot using one of the synchronization patterns associated with the desired timeslot. 440 Claims 1, 2, 5 and 7 are independent claims. There are also four consistory clauses [0005c], [0005d], [0005e] and [0005f] contained in the 'Summary of the Invention'. They are as follows: [0005c] According to one aspect of the present invention there is provided in a time division multiple access (TDMA) system having a plurality of timeslots, a method comprising the steps of: tuning to a frequency in the system; searching for a desired set of synchronization patterns on the frequency, each of at least two slots on the frequency out of n slots used on the frequency having a set of synchronization patterns that are mutually exclusive of each other and of other sets of synchronization patterns used in the system on the frequency, and each set comprising at least two different synchronization patterns as a function of a payload type; and if one of the synchronization patterns belonging to the desired set of synchronization patterns is detected on the frequency, synchronizing to a timeslot in which the synchronization pattern was detected and receiving information corresponding to the indicated payload type. [0005d] According to a further aspect of the present invention there is provided in a time division multiple access (TDMA) system having a plurality of timeslots, a method comprises the steps of: knowing a first set of synchronization patterns associated with a desired timeslot and a second set of synchronization patterns associated with each of the other timeslots in the TDMA system, wherein the first set of synchronization patterns is mutually exclusive from the second set of synchronization patterns, and each set comprising at least two different synchronization patterns as a function of at least one of a payload type and a source of the transmission; preparing to transmit a particular payload type in a timeslot; determining whether the timeslot is a current desired timeslot for the TDMA system; if the timeslot is the current desired timeslot, selecting a synchronization pattern selected from the first set of synchronization patterns based on the one of the particular payload type and a particular source of the transmission; otherwise selecting a synchronization pattern selected from the second set of synchronization patterns based on the one of the particular payload type and the particular source of the transmission; and transmitting a burst in the timeslot having embedded the synchronization pattern that was selected. [0005e] According to a still further aspect of the present invention there is provided in a time division multiple access (TDMA) system having a plurality of timeslots, a method comprising the steps of: selecting a channel having a desired frequency and a desired timeslot, wherein each timeslot has a set of synchronization patterns associated therewith, each set of synchronization patterns are mutually exclusive of each other, and each set of synchronization patterns comprises at least two different synchronization patterns as a function of at least one of a payload type and a source of the transmission; tuning to the desired frequency; searching for synchronization patterns associated with each of the plurality of timeslots on the desired frequency; if one of the synchronization patterns is detected on the desired frequency, synchronizing to a timeslot that is associated with the synchronization pattern that was detected; and if the desired timeslot does not match the timeslot that is associated with the synchronization pattern that was detected, adjusting timing to decode the desired timeslot. [0005f] According to a still further aspect of the present invention there is provided in a time division multiple access (TDMA) system having a plurality of timeslots, a method of attempting to initiate a transmission on a desired frequency and a desired timeslot, the method comprising the steps of: detecting a carrier presence on the desired frequency; searching for synchronization patterns associated with each of the plurality of timeslots on the desired frequency, wherein each of the plurality of timeslots on the desired frequency has a set of synchronization patterns associated therewith, and each set of synchronization patterns are mutually exclusive of each other; if one of the synchronization patterns associated with the desired timeslot is detected on the desired frequency, denying the transmission; if none of the synchronization patterns associated with any of the plurality of timeslots are detected on the desired frequency, denying the transmission; and if none of the synchronization patterns associated with the desired timeslot are detected on the desired frequency, but at least one of the synchronization patterns associated with any of the other timeslots is detected on the desired frequency, synchronizing to a timeslot associated with one of the synchronization patterns that was detected, and adjusting timing in order to transmit the transmission in the desired timeslot using one of the synchronization patterns associated with the desired timeslot. 441 Claim 1 corresponds with [0005c], claim 2 with [0005d], claim 5 with [0005e], and claim 7 with [0005f]. 442 The specification describes six embodiments. Embodiment 1 is at [0026]-[0030] and is a transmitting device. Embodiment 2 is at [0031]-[0034] and is a receiving device. Embodiment 3 is at [0035]-[0036] and is also a receiving device. Embodiment 4 is at [0037]-[0043] and is a transmitting device. Embodiment 5 is at [0044]-[0045] and is a receiving device. Embodiment 6 is at [0047]-[0068] and is a subscriber unit in direct mode which is transmitting device. Consideration 443 As above, the first question is whether claim 2 includes subscriber units operating in direct mode (as Motorola contends), or whether it is limited to repeater-based systems only (as Hytera contends). The language of each embodiment is expressed in such a way that the nature of the device is not directly identified, that is to say, at least as a matter of first impression, one cannot tell whether the transmitting device being discussed is a base station, a subscriber unit in a repeater based system, or (except in the case of embodiment 6) a subscriber unit in direct mode. Instead, each embodiment speaks in terms of 'transmitting' or 'receiving' without saying what type of device is doing this. Nevertheless, it is clear that embodiments 1-5 are descriptions of subscriber units and base stations operating together in a repeater based system, and that the transmitting devices in embodiments 1 and 4 are repeaters, not subscriber units. This is because of [0046] and [0047]: [0046] So far, the examples in FIGS. 2 and 5 illustrate a repeater being the transmitting device; the present disclosure, however, is also applicable when the subscriber unit is the transmitting device. In a repeater-based system, when the transmitting device is a subscriber unit that is transmitting to the repeater, the subscriber unit embeds the appropriate synchronization pattern for the appropriate timeslot (e.g., SyncPattern_TS1 or SyncPatternTS2), where appropriate, in the bursts transmitted to the repeater. This allows the repeater to verify that the incoming transmission is indeed on the correct timeslot. Additionally, this enables the transmission of a signal to the repeater without requiring the subscriber unit to first synchronize to the downlink (i.e., information flow from the repeater to the subscriber unit) and determine the correct timeslot when the downlink is inactive. The repeater downlink is often inactive to enable a shared usage of the frequency among numerous entities. [0047] Let us now discuss direct mode transmission in accordance with the present disclosure. During a direct mode transmission, when the transmitting subscriber unit is transmitting directly to a receiving subscriber unit, the transmitting subscriber unit selects an appropriate synchronization pattern associated with the timeslot that it will transmit in, in order to improve spectral efficiency. FIG. 7 illustrates a simple timing diagram of subscriber units communicating directly with one another. As shown, two transmissions are currently being transmitted by two transmitting subscriber units on a single frequency (e.g., 12.5 kHz channel bandwidth with 2:1 TDMA slotting structure for 6.25e spectral efficiency) in separate timeslots. Transmitting subscriber unit 1 is transmitting bursts in its transmission that have an embedded synchronization pattern associated with Timeslot 1, where appropriate; transmitting subscriber unit 3 is transmitting bursts in its transmission that have an embedded synchronization pattern associated with Timeslot 2, where appropriate. Once the synchronization patterns are detected by the receiving subscriber units 2 and 4, respectively, the receiving subscriber units 2 and 4 immediately know they have synchronized to their desired timeslots. 444 Figure 2 accompanies embodiment 1 and Figure 5 accompanies embodiment 4. Both embodiments 1 and 4 are said to be devices which are transmitting, and [0046] and [0047] make it abundantly clear that they must be repeaters. By the same token, the receiving devices described in embodiments 2, 3 and 5 are subscriber units operating in conjunction with a repeater since these embodiments appear in the specification before [0046] and because of each of the receiving devices synchronises to the transmitting device (which a repeater does not do). Paragraph 46 and the first sentence of [0047] make clear that the specification does discuss subscriber units in direct mode, but only from [0047] onwards. 445 There are two matters which can be seen to point in the opposite direction to this conclusion. One of these is that embodiment 1 contains this statement at [0026]: The transmitting device prepares to transmit in Timeslot 1 (e.g., if the transmitting device is a repeater, the repeater may, for example, set the TC bit in the CACH to "0" … 446 A similar passage appears at [0029]. Viewed in isolation, these sentences would appear to assume the possibility that the device is not a repeater. However, I do not think this can overcome the clarity of that which appears at [0046] and [0047]. Paragraph 46, in particular, singles out Figure 2 (which illustrates embodiment 1 schematically) as describing a repeater. 447 Consequently, embodiment 1 is concerned with a repeater, not a subscriber unit. The same is true of embodiment 4. As with embodiment 1, [0046] is explicit in saying that the figure which accompanies embodiment 4, Figure 5, is a repeater. 448 Thus is complete the first part of the puzzle. So far as the specification is concerned the transmitting devices it describes are receivers (apart from embodiment 6). This creates an interpretative challenge for Motorola because the most natural way to read claim 2 is as relating to the repeaters in embodiments 1 and 4. To overcome that problem Motorola advanced a construction of claim 2 that was said to be applicable to a subscriber unit operating in direct mode. This argument was complex and had a number of steps. Lest one becomes lost in the steps which Motorola's construction involves, it is useful to keep in mind the ultimate goal which is a reading of claim 2 which could describe the operation of a subscriber unit in direct mode. 449 During the course of the trial, Motorola's construction of claim 2 underwent some development. The best articulation of it came during Professor Wicker's evidence on whether the Hytera devices infringed claim 2 at T508.25-509.26. Motorola submits that there are five steps in claim 2. 450 The first step is the 'knowing' step. In this step, the device knows two sets of synchronisation patterns, one associated with timeslot 1 and the other is associated with timeslot 2. 451 The second step is the 'preparing' step. In the preparing step, the device determines which timeslots are available and having done so, chooses which timeslot the transmission will take place upon. 452 The third step is the 'determining' step. In the determining step, the device takes the information from the preparing step, where it has been determined which timeslot the transmission is to take place upon, and checks to see whether the timeslot it is currently transmitting on is that timeslot. 453 The fourth step is the 'selecting' step. In the selecting step, the device obtains the synchronisation pattern appropriate for the timeslot on which transmission is to take place. 454 The fifth step is the 'transmitting' step. In the transmitting step, the device embeds the synchronisation pattern obtained in the 'selecting' step into the burst and transmits it in the relevant timeslot. 455 If construed this way, claim 2 could describe a subscriber unit operating in direct mode. I do not however accept that this construction is plausible. There are three reasons for this. First, nothing in the specification resembles Motorola's interpretation of claim 2 once it is accepted that embodiments 1 and 4 are repeaters (Motorola does not submit that embodiment 6 is embodied in claim 2). Secondly, Motorola's construction leaves embodiments 1 and 4 unexpressed in the claims of the patent. Thirdly, apart from those problems, Motorola's 'preparing' step cannot be reconciled with embodiments 1 and 4 even assuming they describe subscriber units in direct mode (which they do not). 456 Motorola's account of the 'preparing' step is at odds with the specification. Leaving aside embodiment 6 (which relates to claim 7), the specification describes two transmitting devices. The first is embodiment 1 (Figure 2) and the second is embodiment 4 (Figure 5). Embodiment 1 (Figure 2) describes the preparing step in these terms at [0026]: The transmitting device prepares to transmit in Timeslot 1 (e.g., if the transmitting device is a repeater, the repeater may, for example, set the TC bit in the CACH to "0", which indicates that the next timeslot is Timeslot 1 in accordance with the ETSI-DMR standard; or the repeater may simply form the burst to be transmitted, or the like, by applying error detection parity bits to the payload, applying forward error correction parity bits to the payload, adding embedded control signalling, or performing interleaving) … 457 Embodiment 4 (Figure 5) refers to the preparing step but does not say what it is constituted by: [0039]. What is missing from embodiments 1 and 4 is any suggestion that what the transmitting device does, when it prepares to transmit in a timeslot, is determine whether the timeslot is available. A construction of the preparation step which involves determining which timeslot is available therefore has no foundation in any part of the specification. 458 For these reasons, I do not accept that Motorola's construction of claim 2 is plausible. 459 Lest I be wrong, it is nevertheless useful to assume, for the sake of argument, that claim 2 is ambiguous as to whether it applies to just repeater based systems or instead both to repeater based systems and a subscriber unit in direct mode. Once it is accepted that embodiments 1 and 4 must be repeaters, there is then no embodiment in the specification which corresponds with an interpretation of claim 2 which applies to subscriber units in direct mode. Indeed, the only embodiment which deals with subscriber units in direct mode is embodiment 6. It is not in dispute that embodiment 6 corresponds only with claim 7. 460 On the hypothesis that claim 2 is ambiguous, it becomes therefore necessary to choose between two competing constructions. These are Motorola's ornate construction of claim 2 and the straightforward idea that claim 2 gives effect to embodiments 1 and 4, that is to say, that it is talking about a repeater not a subscriber unit in direct mode. 461 Motorola's construction finds no foothold in the description of the invention given in the specification. This is because, making the assumption that Motorola is right and that the transmitting device referred to in claim 2 is in fact a subscriber unit in direct mode, there is absent from the specification any account of the process of dynamic timeslot switching which Motorola's interpretation of claim 2 necessarily entails. 462 In my view, this is a good reason to resolve the ambiguity against Motorola and to conclude that claim 2 gives effect to embodiments 1 and 4. So construed, it does not apply to a subscriber unit in direct mode. In any event, for the reasons I have given, I do not accept that claim 2 is ambiguous because Motorola's construction of it is outlandish. 463 There is also a more fundamental problem. If Motorola's construction of claim 2 were correct, then embodiments 1 and 4 would not be reflected in any of the claims. For example, at [0039], embodiment 4 'prepares to transmit in Timeslot 1'. Under Motorola's construction of what is involved in 'preparing' to transmit, this becomes incoherent for the device, being a repeater, is going to transmit on timeslot 1 come what may (it being recalled that repeaters transmit alternatively on each timeslot). 464 This problem could be averted only by saying that claim 2 meant one thing when it applied to a subscriber unit in direct mode and something quite different when it applied to a repeater. This too would be absurd. 465 I therefore reject Motorola's construction of claim 2. I should say for completeness that it is not necessary to determine Hytera's contention that the 'desired timeslot' in claim 2 was necessarily the rest timeslot referred to at [0038]. I would accept that it is certainly a timeslot which is given a system wide designation in the TDMA system. The only example proffered in the patent of a system wide timeslot designation is, indeed, the rest timeslot described in [0038]ff. However, the language of claim 2 is not limited to a rest timeslot and it would appear to leave open the possibility that there could be other system wide timeslot designations which would fall within claim 2. 466 Having rejected Motorola's construction of independent claim 2, it follows that its construction of dependent claim 3 must be rejected too. FAIR BASIS 467 If there were substance in Motorola's marginal construction of claim 2, it would inevitably mean that claim 2 lacked a fair basis and was invalid. This litigation is governed by the form of the Act prior to the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 (Cth). As such, s 40(3) requires that the claims of the patent must be fairly based on the matter described in the specification. The only embodiment in the specification which describes the use of the invention by subscriber units in direct mode is embodiment 6 at [0047]-[0068]. It does not in any way resemble the invention to which Motorola's construction of claim 2 would give rise. Nothing in the specification so much as hints at two subscriber units in direct mode sharing the same frequency by dynamically changing between timeslots. 468 The best that can be said is that if Motorola's construction of claim 2 were correct, then it would be necessary to construe consistory clause [0005d] in accordance with it. This would mean that claim 2 was disclosed in that consistory clause. However, Motorola's construction of claim 2 (and hence [0005d]) is so strained that, making the heroic assumption that it is correct, no person skilled in the art would possibly think that [0005d] was about subscriber units in direct mode. Hence, it remains the case that there is no reasonable disclosure of the invention for which Motorola contends in the specification. 469 Whilst I accept that it is possible that a properly drafted consistory clause may in some cases mean that a claim is fairly based on the specification, the question remains one of looking at the specification as a whole: Lockwood (No 1) at [99]. So viewed, I do not accept that claim 2 (construed as Motorola would construe it) is in any meaningful way disclosed in the specification. Consequently, even if claim 2 did describe two subscriber units in direct mode dynamically changing between timeslots (and it does not), it would be invalid since it would not be fairly based on the matter described in the specification. INVENTIVE STEP 470 The 2007 DMR Standard utilised the 48 bit synchronisation pattern to convey embedded control information. The control information which was conveyed under the standard was first, whether the payload was a voice or data transmission and, secondly, the identity of the transmitting device (that is, whether it was a subscriber unit or base station). In fact, the standard actually provided for six synchronisation patterns. I turn to these shortly, but it is useful in the first instance to examine closely one of them: the synchronisation pattern to be used where the transmitting device was a base station sending a packet containing a voice communication. This was represented by a 48 bit sequence. The 48 bit synchronisation pattern can be broken into 12 sets of 4 bits. Four binary bits may represent a number between 0 and 15. It is common in computer technology to represent sets of 4 bits by means of a single hexadecimal digit; i.e. 0-9 and A-F. The base 10 number 10 corresponds to hexadecimal A and the base 10 number 15 corresponds to hexadecimal F (more commonly, the contents of any byte (8 bits) can be represented by a two digit hexadecimal number). 471 The 2007 DMR Standard provided for a synchronisation pattern indicating that the payload was a voice communication transmitted from a base station by a 12 digit hexadecimal number 755FD7DF75F7. This corresponds with an underlying 48 bit binary code 011101010101111111010111110111110111010111110111. I mention the 48 bit pattern because it sets the context for a debate which arises below about the need for the bit sequences constituting the patterns to be as different as possible from each other. This involves achieving the maximal dispersion of 1's and 0's in the complete set of patterns. 472 Having laid that groundwork, the complete table of the six synchronisation patterns provided by the 2007 DMR Standard was as follows: 473 Four aspects of this should be noted. First, 'BS sourced' refers to a transmission from a base station whereas 'MS sourced' refers to a transmission from a subscriber unit (i.e. a mobile station). Secondly, it will be noted that the sixth pattern was entitled 'Reserved SYNC pattern'. The standard established this synchronisation pattern without giving it a purpose but instead reserving it for future use. In my view, this is of some significance. Whether it was the authors of the 2007 DMR Standard who conceived of using the 48 bits in the synchronisation patterns to convey control information or whether that insight preceded the standard does not matter for present purposes. The important thing is that by 2007, the idea of using synchronisation patterns to embed control information was known and formed part of an industry wide standard. Further, by reserving the sixth synchronisation pattern for future use, the 2007 DMR Standard contemplated that at some point in the future, the ability to store information in a synchronisation pattern would be utilised with information beyond that which was in the table. 474 Thirdly, the 'RC sync' should be mentioned. This referred to what is known as a 'reverse channel'. It is not necessary for present purposes to understand what a reverse channel is. Its only significance is that the fact that a reverse channel involved control information which could be signalled in a synchronisation pattern. 475 Fourthly, it will be observed that the probability that a sequence of 48 consecutive bits was the same as any given 48 bit synchronisation pattern was 1/248, which is extremely improbable (248 is slightly more than 281 trillion). Using six synchronisation patterns increases the chances of a false match six-fold but this is still an unlikely event. I mention this to lay the groundwork for some evidence given by Professor Wicker about the risk of false matches. I return to that evidence below. 476 Turning then to the question of inventiveness, there are two aspects of claim 2 (assuming that it is construed in the fashion for which Motorola contends) which need to be considered. The first is that the timeslot is identified by using a synchronisation pattern. The second is that, armed with that knowledge, the subscriber unit is able to switch to a timeslot which is available. 477 Hytera acknowledges that inventiveness did lie in the use of synchronisation patterns to embed control information however contended that this insight was well-known by the time of the 2007 DMR Standard. It therefore submitted that embedding timeslot identification information in a synchronisation pattern was merely an analogous use of that idea and involved no ingenuity in itself. 478 Hytera submitted that its position was supported by the evidence of Mr Kuhrt. Mr Kuhrt was asked by Hytera's solicitors what method he would have proposed as at 3 October 2008 (the priority date) if he had been requested to develop a DMR system that was able to facilitate two concurrent communications between subscriber units in direct mode. Mr Kuhrt formulated two designs (which I will return to shortly). One of these used synchronisation patterns to identify a timeslot, the other did not. 479 Motorola attacked Mr Kuhrt's evidence from several directions. First, Motorola submitted that Mr Kuhrt had, as a matter of historical fact, been aware when he prepared his evidence in 2018 of the 2012 DMR Standard which, as everyone knows, did actually use synchronisation patterns to identify timeslots. In Motorola's view, it was unrealistic to think that he was not influenced by what he already knew in formulating his design. His evidence was therefore to be discounted on the basis that it was infected by the perils of hindsight. 480 Secondly, Motorola deployed Professor Wicker to criticise Mr Kuhrt's two designs. The forensic end to which this foray was tailored was to demonstrate that Mr Kuhrt's allegedly obvious solution was not, in fact, obvious because it was not readily feasible. The two problems Professor Wicker identified were, first, that increasing the number of synchronisation patterns could lead to false synchronisations occurring; and secondly, that Mr Kuhrt's design solutions would have required complex computer programming for their implementation. Independently of Professor Wicker, Motorola also submitted that Mr Kuhrt's designs transgressed an accepted principle in radio communications engineering concerned with 'layers'. I explain this problem below. 481 Thirdly, Motorola advanced further evidence from Professor Wicker to the effect that if he had been asked the same question on 3 October 2008, he would not have gone down the path that Mr Kuhrt had chosen. In particular, he would not have sought to have achieved timeslot identification by using synchronisation patterns. Professor Wicker thought that a more obvious solution would have been to use a supplemental control channel (of which more later). 482 Fourthly, Motorola advanced an argument that the problem of timeslot identification in direct mode was a longstanding problem that the industry had struggled in vain to solve. The persons involved in the drafting of the 2007 DMR Standard were, according to Motorola, a virtual Who's Who of the DMR community. It submitted that the evidence showed that the industry had sought unsuccessfully to solve the problem. This was said to be secondary evidence of inventiveness. Hytera, on the other hand, submitted that the evidence did not show that anyone had unsuccessfully attempted to solve the problem. It further submitted that none of the people involved in the drafting of the standard had been called to give evidence about the existence of this problem or their unsuccessful struggles to solve it. This was significant, Hytera submitted, because many of them were actually employees of Motorola. Since they had neither been called nor any explanation proffered for their absence from the witness box, Hytera submitted that no inference should be drawn either that the supposed problem had been understood to exist or that the persons responsible for the drafting of the 2007 DMR Standard had struggled in vain to solve it. 483 I propose to approach these issues as follows: (a) First, to identify what the state of the CGK was as at the priority date of 3 October 2008; (b) Secondly, to explain Mr Kuhrt's hypothetical designs; (c) Thirdly, to explain Motorola's submission that Mr Kuhrt's designs do not give effect to claim 2 of the 764 Patent; (d) Fourthly, to explain Motorola's submissions that a person skilled in the art at the priority date would not have embraced Mr Kuhrt's designs. Motorola suggested that Mr Kuhrt's designs were not obvious. This invites consideration of whether: (i) Mr Kuhrt's designs are not feasible because they give rise to a risk of false synchronisation (the point being that a person skilled in the art would not have gone down the path suggested by Mr Kuhrt because they would have perceived the designs to be problematic); (ii) Mr Kuhrt's design infringes a radio communications engineering principle which counsels against mixing up layers (explained below). As I understood this point, Mr Kuhrt's methods involve the mixing of layers so that a person skilled in the art would not have considered such an approach appropriate. As part of this argument, Motorola submitted that the layer problem would have pushed any person considering the problem away from the use of synchronisation patterns to identify timeslots and, instead, towards the use of a 'supplemental control channel' (also explained below); (iii) Mr Kuhrt's design would have required extensive programming to implement; and (iv) Mr Kuhrt's design would have required more processing power. (e) Fifthly, to consider Motorola's submission that Mr Kuhrt's evidence was affected by hindsight; (f) Sixthly, to assess the correctness of Motorola's submissions that the use of synchronisation patterns to identify timeslots in direct mode addressed a long felt want in the field; and (g) Seventhly, to draw conclusions about whether claim 2, if construed as Motorola suggests, involved an inventive step. 484 My conclusion is that Hytera has not demonstrated that the invention is obvious and therefore lacks an inventive step. Whilst I accept Mr Kuhrt's evidence, I do not consider that it discharges the onus Hytera bears to prove that the invention was not inventive. Claim 2 (construed as Motorola would have it) discloses a process of dynamic switching between timeslots using a method which utilises the identification of the timeslots using synchronisation patterns. Mr Kuhrt's evidence shows that dynamic switching between timeslots was obvious. It also shows that using synchronisation patterns to identify timeslots was obvious. However, Mr Kuhrt's evidence does not purport to say that it was obvious to provide for dynamic timeslot switching based on the identification of each timeslot by means of a synchronisation pattern. The Common General Knowledge 485 Hytera made detailed submissions about the state of the CGK as at 3 October 2008. I did not apprehend Motorola to dispute Hytera's account of the CGK and I accept Hytera's submissions about it. I find that: (1) Before October 2008, the CGK relevant to the 764 Patent included information about: (a) How mobile stations communicated in direct mode in a TDMA system; (b) Synchronisation patterns and their use for the dual purpose of: (i) Enabling the receiving device to synchronise with the timing set by the transmitting device; and (ii) Embedded signalling that conveyed control information to the receiving device. (2) It was also CGK that a problem existed with the 2007 DMR Standard. This was that: (a) No control information existed that signified the timeslot number when mobile stations operated in direct mode; and (b) As a consequence, the 2007 DMR Standard did not permit both timeslots to be used simultaneously in direct mode. (3) It was CGK that the term 'direct mode' referred to transmissions which were made between two mobile stations without a repeater. They usually occurred on the same transmit and receive frequency. Direct mode was possible, so long as the mobile stations were not too far apart. (4) In direct mode operation under the 2007 DMR Standard, the transmitting mobile station established the time reference for the receiving mobile station. (5) The burst and frame structures for the mobile station's transmissions were specified under the 2007 DMR Standard. Each frame comprised 30 msec timeslots where: (a) Each burst was 27.5 msec long and contained: (i) 216 bits of payload; and (ii) A 48 bit synchronisation pattern or embedded signalling that was positioned in the middle 5 msec of the burst. The first burst in a voice transmission contained the synchronisation pattern and the five following bursts contained embedded signalling. (b) The remainder of the timeslot was 2.5 msec of guard time (1.25 msec at either end of the burst). (6) Synchronisation patterns were distinctive bit sequences that were used for the dual purposes of: (a) Enabling a receiving mobile station to synchronise with the reference timing set by the transmitting device; and (b) Embedding control signalling that conveyed information to the receiving device, such as information about the payload (i.e. voice or data) and the source of the transmission (i.e. a subscriber unit or base station). (7) A receiving mobile station could be programmed to recognise a received synchronisation pattern as conveying information. This information was conveyed by the synchronisation patterns as a whole and not by individual bits within it. 486 As I have already noted, the 2007 DMR Standard prescribed six different synchronisation patterns and these included one which was reserved for future use. The table of patterns is set out above. As at 3 October 2008, the five synchronisation patterns which were being used enabled the receiving device to synchronise with the reference timing set by the transmitting device and to receive embedded control signalling that conveyed information to the receiving device. The control information which was embedded concerned the nature of the payload (voice or data) and whether the transmitting device was a subscriber unit or a base station. 487 The patterns of 48 bits were chosen so that the individual bit sequences are 'far apart' from one another. This is a difficult concept to convey but may be usefully captured by saying that the patterns are as different from each other as they can be. The more synchronisation patterns one has, the less far away from each other, in this sense, they will be. As the number of synchronisation patterns in use increases, so too does the risk of a false synchronisation. Part of this is the increasing risk of a 48 bit sequence happening to be the same as one of the synchronisation patterns. However, another part of the risk consists of the fact that transmission errors in one synchronisation pattern might turn it into another synchronisation pattern. Professor Wicker explained the problem this way at T655.5-10: You can think of it as putting dots on the surface of a globe. Two dots can be maximally separated. If you've got four, they're going to be closer together. Every time you add a sequence, you're adding more dots. And so those sequences get closer together and the likelihood of a mistake increases. 488 As at 3 October 2008, a problem with the then current DMR standard was that when mobile stations were making transmissions in direct mode, there was no control information which could indicate a timeslot number. This problem arose because there was no CACH message in direct mode because the 2.5 msec it occupied (1.25 msec at the beginning of the burst and 1.25 msec at the end of the burst) was needed for guard time to prevent timeslot interference. Since there could be no CACH message, two subscriber units in direct mode could not simultaneously transmit using both timeslots on one frequency. 489 Hytera submitted that the 2007 DMR Standard was part of the CGK as at 3 October 2008. I accept this submission. Even if they were not part of the CGK they fell, in any event, within s 7(3). Mr Kuhrt's Hypothetical Designs 490 In his first affidavit, Mr Kuhrt explained that he had been asked by Hytera's instructing solicitors to explain what method, if any, he would have proposed as at 3 October 2008, if he had been requested to develop a DMR system that was able to facilitate two concurrent communications between subscriber units in direct mode: Kuhrt-1 at §253. The task he was set did not distinguish between subscriber units in direct mode which had been allocated a fixed timeslot, and subscriber units in direct mode which were not allocated to any particular timeslot but which could, in principle, use either slot. 491 He articulated two methods and said that in proposing these methods he had taken into account only information that he was aware of and regarded to be well-known and generally accepted in the field of two-way radio systems prior to 3 October 2008, together with the certain sections of the ETSI DMR standards. 492 Mr Kuhrt began by saying that he knew by 3 October 2008 of the problem that subscriber units in direct mode could not use both timeslots on the same frequency and that the problem was well-known and generally accepted in the field. Professor Wicker gave similar evidence. The Two Designs 493 Mr Kuhrt proposed two methods which dealt with two different situations. The first situation involved subscriber units communicating in direct mode on a physical channel. The second involved subscriber units communicating in direct mode on a logical channel. Although Mr Kuhrt's evidence about this could have benefited from an editor with a more generous attitude to the reader, what this meant was that his designs dealt with two different systems: (a) a system where subscriber units communicating in direct mode were assigned a frequency but not assigned a timeslot; and (b) a system where subscriber units communicating in direct mode were assigned a frequency and a timeslot. 494 In the situation in (a), the subscriber unit may communicate in either timeslot; that is, either timeslot 1 or 2. In the situation in (b), the subscriber unit is doomed forever only to communicate using the pre-ordained timeslot. Part of the problem with understanding Mr Kuhrt's impenetrable evidence springs from the fact that it was originally couched in terms of 'frequency pairs' and the associated concepts of logical and physical channels. Subsequent revision of Mr Kuhrt's affidavit then removed his references to frequency pairs without adjusting his references to physical and logical channels. This left parts of his evidence extremely difficult to follow. Nevertheless, having made the effort to understand what Mr Kuhrt was trying to say, I do not think that this infelicity of expression makes what he has to say less valid. 495 The design challenge Mr Kuhrt described was how to get subscriber units in direct mode to co-operate in such a way that both timeslots would be used. Although Mr Kuhrt omitted from his explanation much which was obvious to him, it is useful I think to include some observations about his decision to describe two different designs in relation to (a) and (b). The first of these is that between them, (a) and (b) describe the universe of ways in which subscriber units in direct mode may approach timeslots. They are either free to switch between timeslots in their quest to send and receive communications (situation (a)) or they are not (situation (b)). 496 Secondly, given that Mr Kuhrt's aim was to make use of both of the timeslots on the frequency, there is – to those unschooled in these matters – an immediate problem with (b). If a subscriber unit can only operate on a specific timeslot, it is difficult to see how any system designed by Mr Kuhrt could achieve utilisation of both timeslots. For example, if two separate subscriber units both wished to transmit at the same time and both were allocated to timeslot 1, it is not immediately obvious how Mr Kuhrt's design would enable them to do this. The answer to this conundrum, more fully explored in Mr Kuhrt's design concerning allocated timeslots, is that his solution is only workable where the two devices wishing to transmit have been assigned to different timeslots. Where they have been, Mr Kuhrt's allocated timeslot design allows both timeslots to be used. Where they have not been, Mr Kuhrt's design is not workable. 497 On the other hand, in situation (a), the subscriber units are not bound to a particular timeslot. Consequently, they are able to shift from one timeslot to another depending on availability. 498 It is useful then to deal with situation (b) first; that is to say, the situation where each subscriber unit has been allocated to a timeslot in advance. By way of entrée, it will be seen that Mr Kuhrt's method uses synchronisation patterns to identify the timeslots. Timeslot Allocated in Advance and Unable to be Changed 499 Although Mr Kuhrt's evidence was difficult to follow in that he never took the time to describe his method with much clarity and preferred to rely largely upon examples, distillation of his affidavit reveals that what he proposed involves a number of steps: (a) Each subscriber unit is assigned a timeslot in advance from which it is unable to move; (b) The first subscriber unit to initiate a communication on the frequency becomes the 'timing master'; (c) The timing master is responsible thereafter for setting the timing for the frequency which it does by transmitting a synchronisation pattern. In that sense, this first subscriber unit performs the timing function performed by a base station in repeater based systems; (d) Because the subscriber units are only permitted to transmit or receive on their allocated timeslot, it becomes necessary for each subscriber unit to be able to identify the timeslots; (e) This Mr Kuhrt would do by adding four new synchronisation patterns to the table in the 2007 DMR Standard. These would be synchronisation patterns which indicated that: (i) The burst was from a subscriber unit, was voice and was on timeslot 1; (ii) The burst was from a subscriber unit, was data and was on timeslot 1; (iii) The burst was from a subscriber unit, was voice and was on timeslot 2; and (iv) The burst was from a subscriber unit, was data and was on timeslot 2. (f) In addition, each transmitting device would also transmit information which identified the intended addressee of the message. Mr Kuhrt did not explain precisely how this would be done. It is possible Mr Kuhrt intended that this would be done in some way using the full LC message (to which he made a fleeting although ultimately cryptic reference) or perhaps by way of talkgroup information (to which he also made fleeting reference); (g) Where a subscriber unit wishes to transmit, it first waits to detect a synchronisation pattern (unless it is the timing master, in which case it will transmit a synchronisation pattern as above). That pattern will indicate whether: (i) there is an activity on the channel; and (ii) if there is activity on the channel, whether that activity is occurring on timeslot 1 or timeslot 2. Upon receiving that pattern: (i) If the timeslot on which activity is occurring is the timeslot which the device wishes to transmit on, it knows that the timeslot is busy. The subscriber unit therefore waits for the timeslot to become available. Although Mr Kuhrt did say in Kuhrt-1 at §281 that, in this circumstance, the subscriber unit could also switch to another frequency, I do not see how this can be correct. The entire assumption upon which this discussion takes place is that the subscriber unit is unable to switch away from the timeslot to which it has been assigned. I have therefore decided to ignore this element of Mr Kuhrt's design as it appears to be internally inconsistent. In any event, it is not material to any of the issues which call for resolution. (ii) If the timeslot on which activity is occurring is not the timeslot on which the device is permitted to transmit, the device adjusts its timing by 30 msec so that it is synchronised to its allocated timeslot (there being only two timeslots, to know one is not on one's allocated timeslot is to know that the other timeslot is one's allocated timeslot). (h) If the device detects activity on the other timeslot (i.e. as in (g)(ii)), after adjusting its timing to synchronise with its allocated timeslot, it then: (i) Checks to see whether there is any activity on its allocated timeslot; and (ii) If there is activity on that timeslot, it does not transmit but waits until the timeslot becomes available or switches to another frequency; or (iii) If there is no activity on the timeslot, it transmits the burst (complete with a synchronisation pattern which identifies the timeslot which it is transmitting on to the receiving device). (i) So far as a receiving subscriber unit is concerned, it waits to detect a synchronisation pattern; (j) The patterns tells it whether the timeslot is its allocated timeslot or not; and (k) If it is, the subscriber unit decodes the control information which identifies whether it is the intended recipient and, if it is, decodes the transmission. Otherwise, it waits on the timeslot. Timeslot Not Allocated in Advance 500 Under this scenario, subscriber units could transmit and receive on both timeslots. An important feature of Mr Kuhrt's design in relation to non-allocated timeslots is that it does not involve the use of synchronisation patterns to identify the timeslots. Distilling Mr Kuhrt's affidavit, the method which he suggested was as follows: (a) The first subscriber unit to initiate a communication on the frequency becomes the timing master; (b) The timing master is responsible thereafter for setting the timing for the frequency which it does by transmitting a synchronisation pattern. In that sense, this first subscriber unit performs the timing function performed by a base station in repeater based systems; (c) As I understood it, it was not a feature of this design that the subscriber units ever knew which timeslot they were transmitting or receiving upon. Rather, the 30 msec burst of the timing master by default becomes timeslot one, and the following 30 msec becomes the second timeslot. Each subscriber unit which was transmitting would embed in each burst a synchronisation pattern. This was the pattern described in the table to the 2007 DMR Standard which identified that the transmission was from a subscriber unit and was either a voice or a data transmission. The synchronisation pattern which was to be embedded would differ depending upon whether the transmission was a voice or data transmission; (d) A subscriber unit which wished to transmit waits to detect the synchronisation pattern; (e) If the pattern is detected it knows that the timeslot is not free (because the synchronisation pattern implies that an active transmission is underway). It then adjusts its timing by 30 msec and checks to see whether the other timeslot is free, after which: (i) If that timeslot is free, it transmits on that timeslot. This transmission includes control information identifying the addressee of the transmission; or (ii) If that timeslot is not free, the subscriber unit waits until a timeslot becomes available or switches to a different frequency. (f) Where the subscriber unit is a receiving device (that is, it is not wishing to make a transmission), it waits to detect a synchronisation pattern. Having done so, it then checks the identification information (e.g. talkgroup information) to see if it is the intended recipient. If it is, it decodes the transmission. Otherwise, it waits to detect the next synchronisation pattern. Some Preliminary Observations of Mr Kuhrt's Two Designs 501 The notable features of Mr Kuhrt's designs are as follows. 502 First, the allocated timeslot design involves adding four synchronisation patterns to the table in the 2007 DMR Standard. Secondly, the role of the timing master was not expanded upon but Motorola did not appear to mind this. In my mind, there is conceptual confusion in Mr Kuhrt's evidence. It is apt to suggest that the initiating device maintains the timing signal. However, it is unclear to me how that would work if the initiating device ceases to transmit. Mr Kuhrt does not explain how the role of timing master is passed from device to device. However, since neither party saw any significance in this issue, I will put it in the swelling basket of irrelevant loose ends. Thirdly, Mr Kuhrt's non-allocated timeslot design provides for timeslot switching but by subscriber units which do not know which timeslot they are on. It does not utilise synchronisation patterns to identify the timeslot. Fourthly, Mr Kuhrt's allocated timeslot design does utilise synchronisation patterns to identify the timeslots but does not provide for timeslot switching. Fifthly, by contrast, assuming Motorola's construction of claim 2 is correct, claim 2 involves timeslot switching by subscriber units which have ascertained the identity of a timeslot using a synchronisation pattern. Sixthly, in his evidence Mr Kuhrt referred to the identification information to be conveyed (by means of an LC word) usually as talkgroup identification information. It is unclear to me whether this is an inevitable feature of Mr Kuhrt's design. It would appear open on both designs for one subscriber unit to seek to communicate with another specific subscriber unit. I mention talkgroups because they relate, as will be seen, to one of Motorola's criticisms of Mr Kuhrt's designs. Do Mr Kuhrt's Designs Implement Claim 2? 503 I accept Motorola's submission that Mr Kuhrt's designs do not implement claim 2 (as construed by Motorola). Mr Kuhrt's allocated timeslot design involves using synchronisation patterns to identify timeslots but does not involve dynamic timeslot switching. It thus does not implement claim 2. Mr Kuhrt's non-allocated timeslot design involves dynamic timeslot switching but does not utilise synchronisation patterns to identify the timeslots. It too therefore does not implement claim 2. 504 I therefore accept Motorola's submission that Mr Kuhrt's two designs do not implement claim 2 as Motorola would construe it. Although it does not matter, it is worth noting that Mr Kuhrt's allocated timeslot design resembles claim 7 and embodiment 6 thereof. Both involve subscriber units in direct mode allocated to a particular timeslot, and both use synchronisation patterns to identify timeslots. However, Motorola does not rely on claim 7 because the Hytera devices' use of pseudo-trunking plainly does not infringe it. Consequently, whether Mr Kuhrt's allocated timeslot design implements claim 7 is neither here nor there. 505 The question then arises as to what the significance of this conclusion is. Hytera submitted that there was nothing inventive in providing for dynamic timeslot switching and any inventiveness in claim 2 lay, if at all, in the fact that it used synchronisation patterns to identify the timeslots. If this submission is correct it implies that Mr Kuhrt's evidence, if accepted, demonstrates that claim 2 is not inventive. 506 Motorola denies that the inventiveness of claim 2 lies only in the use of synchronisation patterns to identify the timeslots. It says that what is inventive about claim 2 is that it facilitates dynamic timeslot switching by the use of synchronisation patterns which identify the timeslots. Although I do not think it adds to the analysis, I should note for completeness Motorola's contention that the dynamic changing of timeslots utilised the idea of a 'desired timeslot' (this, Motorola contends, is a reference to the timeslot on which the device would like, if it can, to transmit). When I refer to claim 2's dynamic changing of timeslots I am to be understood as referring to that element in claim 2 as well. 507 Mr Kuhrt's evidence about his allocated timeslot design, if accepted, shows that the use of synchronisation patterns to identify a timeslot was obvious. 508 Mr Kuhrt's evidence about his non-allocated timeslot design, if accepted, shows that it was obvious to provide for dynamic switching between timeslots. In this regard, Mr Kuhrt's evidence is also supported by the evidence of Professor Wicker. Professor Wicker himself formulated a method which he said would permit two subscriber units in direct mode to communicate using both timeslots. The method he deployed did not utilise synchronisation patterns to identify timeslots. Rather, he favoured the use of what he termed a 'supplemental control channel' (to which I will return in a different context to explain). The point of this evidence was to rebut Mr Kuhrt's evidence that a person skilled in the art would have, as at 3 October 2008, thought it obvious to use synchronisation patterns to identity timeslots. Professor Wicker thought that this was not what a person skilled in the art would have done; rather, that person would have used a supplemental control channel. Professor Wicker was cross-examined about this solution at T641.34-642.12: MR BURGESS: And you identify there an alternative solution in your comment that involves the direct mode transmissions, including a single bit to identify the timeslot number; correct? PROF WICKER: That's right. MR BURGESS: And would the solution you have in mind there be workable to enable mobile stations to dynamically change between timeslots to communicate and free timeslot if the other timeslot was busy? PROF WICKER: Yes. If – it would be – basically be identifying the timeslot in the same way that the CACH identifies the timeslot. MR BURGESS: I see. So, for example, your solution would enable a mobile station wanting to make a transmission to receive a transmission in timeslot 1, infer that timeslot 1 is busy, and, therefore, decide to transmit in timeslot 2 by adjusting its own timing by 30 milliseconds and making the transmission; correct? PROF WICKER: Yes. MR BURGESS: And in October 2008 you have – sorry. I withdraw that. In October 2008 you would have recognised and been confident that your proposed solution could be used in the manner that we just discussed; correct? PROF WICKER: Yes. 509 The point for present purposes is that Professor Wicker's own solution as at 3 October 2008 included dynamic timeslot shifting of the kind under discussion. I accept Hytera's submission that this evidence shows that there was nothing inventive about dynamic timeslot switching. 510 What neither Mr Kuhrt nor Professor Wicker's evidence establishes, however, is that it was obvious to use synchronisation patterns to identify timeslots to facilitate dynamic switching between the timeslots. If Mr Kuhrt's two designs had been combined into one, his evidence would show this. However, the two designs are distinct. One has allocated timeslots (and hence no dynamic switching between them) but uses synchronisation patterns to identify the timeslots. The other does not have allocated timeslots (and hence does provide for dynamic switching) but does not utilise synchronisation patterns to identify the timeslots. 511 Yet claim 2, as construed by Motorola, describes an invention which utilises both. The synchronisation patterns are used to identify the timeslots and to permit thereby dynamic switching between them. Mr Kuhrt's evidence does not establish that claim 2 was obvious because it does not address itself to the combination of the two concepts. 512 Since it is Hytera which bears the onus of proof on this issue, it follows that it has not been demonstrated that claim 2 was obvious. 513 Lest I be wrong in that conclusion because the inventiveness of the two concepts should be considered separately, it is necessary to address the criticisms which were made of Mr Kuhrt's evidence. Does Mr Kuhrt's Allocated Timeslot Design Suffer from the Problem of Increasing the Risk of False Synchronisation? 514 It will be recalled that in Mr Kuhrt's allocated timeslot design, he used four additional synchronisation patterns. Motorola submitted that Professor Wicker's evidence showed that increasing the number of synchronisation patterns created two problems. The first was that if too much synchronisation information was included in a transmission this would reduce the amount of the burst which could be devoted to the payload. There is no substance in this point. As Professor Wicker accepted in his evidence, the amount of synchronisation information as compared to the amount of payload was an important consideration because additional synchronisation information would reduce the space available to transmit actual payload. Mr Kuhrt's synchronisation patterns, however, remained 48 bits in length so there was no change to the balance between payload and the synchronisation pattern. Professor Wicker accepted this at T656.1-4 and T656.28-46. 515 The second was that an increased number of synchronisation patterns increased the risk of mistakes or, as it was called, false synchronisations. For example, Professor Wicker said this at T653.1-3 and at T655.1-10: PROF WICKER: If we now are saying we're dealing with synchronisation patterns. If you have more than one pattern, if that's what you're asking, at some point you're going to affect the ability to synchronise. … MR BURGESS: Thank you. And so, Professor Wicker, to take a proposition that Mr Moore put to Mr Kuhrt at the starting – sorry – earlier this afternoon, it may well be that one could not add a very large number of patterns to table 9.2 without compromising the accuracy of the synchronisation process; correct? PROF WICKER: That's right. You can think of it as putting dots on the surface of a globe. Two dots can be maximally separated. If you've got four, they're going to be closer together. Every time you add a sequence, you're adding more dots. And so those sequences get closer and closer together and the likelihood of a mistake increases. 516 However, Professor Wicker accepted that the addition of four synchronisation patterns as suggested by Mr Kuhrt would not significantly increase this risk. This is consistent with my earlier observation that 248 is a truly astronomically large number. At T657.1-14 he said this: MR BURGESS: Well, it's important to be clear about this, Professor Wicker. My question was you would not have expected Mr Kuhrt's approach of adding four additional synchronisation patterns to table 9.2 in October 2008 to produce an adverse consequence for the synchronisation process; that's correct, isn't it? PROF WICKER: I would have had to analyse it first before making that determination. MR BURGESS: Well, you would not have expected that to be the outcome; correct? PROF WICKER: With 48 bits, adding four sync – adding, excuse me, two sequences – no, I would not have expected a significant change in the likelihood of false sync. 517 I therefore conclude that Mr Kuhrt's allocated timeslot method did not materially increase the risk of false synchronisation or gobble up payload within the burst. I do not accept therefore that either problem would have made the use of synchronisation patterns to identify timeslots any less obvious. Does Mr Kuhrt's Design Involve the Mixing of Layers and Does This Make His Method Less Obvious than it would Otherwise Be? 518 Motorola submitted that there was a general principle in the field that counselled in favour of keeping application layers separate. This principle did not emerge from any of its affidavit evidence but instead during the concurrent evidence session. There was no clear statement by either party about what layers were and although Motorola's submissions suggested that the layers involved were all application layers, I do not think that that is what the evidence showed. Professor Wicker gave this evidence at T649.18-22 and T659.45-660.11: PROF WICKER: Well, it is applying a similar idea, but it's a different concept in the sense that, instead of talking about voice or data, which is an application layer issue, it's actually using the synchronisation sequences to convey something structural about the system, which is slot 1 and which is slot 2. … PROF WICKER: Certainly. What I was trying to explain was that the kind of information, voice or data, that was being obtained from identifying synchronisation patterns in the earlier standard was different information than what slot we're in. Voice or data – these are application layer concerns. It's something that operates at the topmost layer of the device you're working with. So, for example, in a communications system that had a screen like this – right now I'm looking at PowerPoint – or, excuse me, looking at Acrobat PDF Reader. That's the application. All the details below that Acrobat doesn't need to know. So the voice or data is a kind of information that's associated with an application and what's being suggested in Mr Kuhrt – by Mr Kuhrt – is that someone would have thought to use information at a completely different layer that's providing functional information about the operation of the system, and so I meant to suggest those are two different things. 519 I take from this that the data or voice signal contained in a burst is part of what is known as the application layer. Beneath that layer there would appear one or more layers. Professor Wicker referred to a layer providing functional information about the operation of the system. As will shortly be seen it is likely that the layer to which Professor Wicker referred was in all likelihood several layers. So much emerged from the evidence of Mr Kuhrt at T635.11-46. This established that the use of the synchronisation patterns as a timing mechanism occurred in one layer, whilst the transport of control information occurred in another. Neither Mr Kuhrt nor Professor Wicker were asked to christen these two layers but in of the interests of clarity I will refer to them as the timing layer and the control layer. 520 The point for present purposes is that Mr Kuhrt accepted at T635.39-46 that one ought generally to keep layers separate: MR MOORE: And the TC bits were processed in a different layer by the device from synchronisation patterns. MR KUHRT: Yes. MR MOORE: And one would generally keep application layers separate; correct? MR KUHRT: That would be, generally, the way to go. 521 The sin of Mr Kuhrt's non-allocated timeslot design is therefore revealed. It involved using the synchronisation patterns from the timing layer to convey information as part of the control layer. This was the point made by Professor Wicker in the passage from his evidence set out above (in the first four lines). However, Mr Kuhrt was alive to this during the concurrent evidence session. At T637.13-21, there was the following exchange: MR MOORE: And, given that the TC bits were previously in the CACH and now going into sync patterns, that will also potentially affect the order in which the device will receive timeslot information and at what time it's processing it and how it deals with that information. MR KUHRT: Yes. It wouldn't affect the order in which it's receiving the information. I would propose that there would be what's called a global flag, which is available to all the routines across all layers of programming, that just indicates that – which – that it was slot 1 or slot 2 that was being received. 522 Motorola did not submit that I should not accept this evidence. It would appear therefore that a global flag would permit the information in the synchronisation pattern to be available to different layers. This tends to suggest that the problem of mixing layers was not a large one. I do not think it made the use of synchronisation patterns to convey timeslot identification information any less obvious given that they were already being used to convey other control information. 523 Even so, Professor Wicker formulated an alternate method to Mr Kuhrt's design which he thought would have been more attractive to an engineer because it did not involve layer mixing. This alternate method (which I have already averted to above) only emerged during the concurrent evidence session but it was alluded to in a comment made by Professor Wicker in answer to a question posed in the JER at Q32(a). Here Professor Wicker commented that it would have been more likely for an engineer at the priority date 'to have solved the problem through the development of a supplemental control channel'. In his evidence he then outlined a method which he thought would solve the problem of allowing subscriber units in direct mode to use both timeslots. What Professor Wicker had in mind was overcoming directly the problem that there was no CACH message in direct mode and hence no transmission of relevant control information. His solution was to introduce a separate control channel which would contain information which indicated which timeslot was involved. He proposed a 4 bit or 8 bit word which contained a bit which indicated which timeslot was involved. 524 Where would this word be located? At this point it is necessary to note a further aspect of the 2007 DMR Standard. It has been convenient until now to say that the 5 msec interval in the middle of each burst was used for the transmission of the synchronisation patterns. However, this is an incomplete statement. In fact, under the 2007 DMR Standard, the synchronisation pattern was transmitted in this interval only every six bursts. For the other five bursts, the 5 msec was in fact otherwise used or reserved for the transmission of the full LC message. Professor Wicker's design would therefore require a departure from the 2007 DMR Standard. Accepting that the solution would result in the timeslot identification being conveyed in the same layer as the other control information, I do not think that a person skilled in the art would have regarded a design which was not standards compliant as one which ought to be pursued. 525 Thus I do not accept that the layer problem would have made Mr Kuhrt's designs less feasible. I do not accept that an engineer would have been more likely to pursue instead the use of a supplemental control channel because this solution would not have been standards compliant. 526 If it matters, and I do not think that it does, Professor Wicker's solution is also slower than Mr Kuhrt's. This is because his control message can only be decoded after six bursts have been received whereas Mr Kuhrt's works on receipt of the synchronisation pattern. I do not think, however, that this is material to any issue. It shows that Professor Wicker's design is less obvious than suggested but it says nothing about how obvious Mr Kuhrt's design was. 527 Finally, it is useful at this juncture to note that Professor Wicker's evidence about his supplemental control channel, if accepted, would tend to suggest that the problem which the 764 Patent was directed at solving was not much of a problem at all. If Professor Wicker is correct, he would have been able to solve the problem of allowing two subscriber units in direct mode to use both timeslots at the priority date by using his supplemental control channel. The impact of this observation is muted by the fact that I do not think that Professor Wicker's proposal is standards compliant or therefore plausible. However, his confidence that the problem could easily be solved by an engineer at the priority date does rather tend to suggest that the problem did not have quite the significant character that Motorola seeks now to ascribe to it. I return to this later. Do Mr Kuhrt's Designs Require Excessive Computer Programming? 528 Although Professor Wicker suggested in his affidavit evidence that the software modifications which would be necessary to define the four additional synchronisation patterns would not be trivial, he ultimately accepted, at T659.1-5 that a person of ordinary skill could have done the necessary programming. I do not think that this matter is any kind of obstacle to Mr Kuhrt's unallocated timeslot design. Do Mr Kuhrt's Designs Require Increased Processing Power? 529 Motorola submitted that the experts had agreed that adding more synchronisation patterns would at least require more processing power. Mr Kuhrt agreed at T637.8 that more processing power would be required but at T636.29 he had said that the increase involved would be a 'small increase'. Professor Wicker thought that adding the additional synchronisation patterns 'increases the complexity quite a bit': T636.39-40. But neither gave evidence that this fact meant that a person of ordinary skill would have been deterred from using extra synchronisation patterns to identify timeslots. In that circumstance, whilst I accept that more processing resources would have been needed to consider an extra four synchronisation patterns, I am not persuaded that this impacts on the obviousness of Mr Kuhrt's designs. Was Mr Kuhrt's Evidence Affected by Hindsight? 530 Mr Kuhrt affirmed his affidavit on 14 December 2018. The evidence he gave about his two designs concerned what he would have done on the priority date, 3 October 2008, if presented with the hypothetical task of allowing subscriber units in direct mode to communicate using both timeslots. It has not been necessary until now to mention the 2012 DMR Standard. However, it is not in dispute that the 2012 DMR Standard provided for the use of synchronisation patterns for designating timeslots. Motorola's argument was that it was possible that Mr Kuhrt had seen the 2012 DMR Standard and hence that his idea of using synchronisation patterns to designate timeslots was the result of his exposure to the idea in or around 2012. Mr Kuhrt denied that he had consciously taken the idea from the 2012 DMR Standard and Motorola did not submit that his denial should not be accepted. Instead, its point was that the Court should conclude that he had, in effect, been affected by the 2012 DMR Standard in an unconscious way. 531 The first issue which arises is whether as a matter of fact Mr Kuhrt did see the 2012 DMR Standard. Between 2010 and 2014, Mr Kuhrt worked for the Simoco Group before moving to Pacific Wireless Communications in 2015. He had previously worked for TMC Radio which was acquired by the Simoco Group in 2010. At this time, Mr Kuhrt had the role of Engineering Manager. In that role, there is no doubt that he would have kept himself abreast of developments such as DMR standards. One of the matters which he said he completed between 2010 and 2012 was starting 'the implementation of the DMR Standards Tier 2 and Tier 3 for the SDM600 mobile and SDP600 portable radio terminals'. In his affidavit evidence, he gave evidence that he had been promoted in December 2012 to the Systems-Group Manager for the Simoco Group. In that role, he managed the installation of three significant two-way radio projects. Mr Kuhrt gave evidence under cross-examination that once he moved into this management role he did not keep abreast of DMR developments: T625.27-33. 532 Under cross-examination, Mr Kuhrt gave further evidence about these matters. He said that he would not have been working with 'DMR stuff' in his last year or so with the Simoco Group. This would appear to match his evidence that he had moved into a management role in December 2012 and would also tend to suggest that he would have continued to have been aware of fresh DMR standards prior to December 2012. 533 However, Mr Kuhrt also gave evidence under cross-examination that the restructuring which had occurred in 2010 when the Simoco Group acquired TMC Radio had resulted in 'a lot restructuring going on, and there was a lot of politics going on'. He then gave this evidence at T623.23-45: MR KUHRT: … A lot of people left during those stages. And in 2011, 2012 – late 2011, 2012 there was a restructure of the – I would say engineering group. They actually changed the name, or they were in the process of changing the name and making it a R&D centre. An R&D group. And they actually brought in a R&D manager at that point. And my task was to hand over developments to the R&D manager, which I did. And the first tasks that he was focused on was the DMR development that was going on at Simoco Group during that stage. MR MOORE: When, precisely, do you say this occurred? MR KUHRT: Probably late 2011, early 2012. MR MOORE: Do you continue to work for this group - - - MR KUHRT: Yes. MR MOORE: - - - after that time? MR KUHRT: Yes. And I still retain the title of engineering manager during that time. But I was less focused – or I was not focused at all on the – after I handed over the development of the DMR project I was not involved in the DMR project other than an advisory role if there was something in terms of planning and stuff like that that needed to be addressed. 534 Mr Kuhrt also said that he continued in his role of Engineering Manager until September 2012: T624.27-29. But the picture Mr Kuhrt paints is that prior to his move to the management position in December 2012, whilst he retained the title of Engineering Manager, he handed over the development of the DMR project to the R&D Manager and this had occurred in late 2011 or early 2012. If one accepts this evidence then his statement that he stopped working on 'DMR stuff' for his last year or so at Simoco Group really ought to have been a statement that he had stopped working on 'DMR stuff' for the last three years he was at Simoco Group. 535 There are two matters to assess here about Mr Kuhrt's evidence. The first is the significance of the fact that he did not mention that he handed over responsibility for DMR work to the R&D Manager in late 2011 or early 2012 in his affidavit but only under cross-examination. The second is the timing inconsistency alluded to in the preceding paragraph. 536 As to both, I saw Mr Kuhrt give evidence on more than one occasion during this trial and I am quite satisfied that he is a witness of truth. I therefore do not think that his failure to mention the handover to the R&D Manager in late 2011 or early 2012 is to be explained on the basis that it did not happen. Indeed, Motorola did not submit that I should. The most likely explanation is that when Mr Kuhrt gave the history of his involvement in DMR he simply did not descend into this level of granular detail. As to the inconsistency between the year or so and three years, I do not think several years after the event that anomalies like this signify anything especially useful. 537 I therefore accept that Mr Kuhrt had stopped working with DMR projects in late 2011 or early 2012 and from that point, his role with DMR was advisory to the R&D Manager. I accept that after 2012 he was involved in the management of projects and was not working at the technical level. 538 The 2012 DMR Standard came out in April 2012. Mr Kuhrt accepted it was possible that at some stage he had seen it. He gave this evidence at T625.35-626.17: MR MOORE: You can't rule out, can you, that you might have seen the 2012 standards? MR KUHRT: No. I may have seen the standard. MR MOORE: Yes. MR KUHRT: But I don't believe that – I know that I did not see anything related to those timeslots. MR MOORE: Well, you can't know that now, can you, Mr Kuhrt? MR KUHRT: Well, if I had seen it, I would have remembered it. Okay? That is the thing. MR MOORE: You will accept that human subconscious is a funny thing, won't you? You will accept, won't you, that it's somewhat of a coincidence that the very four synchronisation patterns that you come up with - - - MR KUHRT: Yes. MR MOORE: - - - in your solution happens to be - - - MR KUHRT: And the timing master and everything is exactly the same. MR MOORE: - - - in the 2012 standard. MR KUHRT: Yes. Well, in – put it this way. I've said that I thought that the solution was obvious. And in one way I believe this just proves that it is obvious. 539 Did Mr Kuhrt see the 2012 DMR Standard sometime between April 2012 and December 2012? This was during the period when he was handing over his work to the R&D Manager in preparation for his move the management position in December 2012. I accept Mr Kuhrt's evidence that he had no conscious recollection of having done so. This led Hytera to submit that the Court should find on the balance of probabilities that he had not seen it. Motorola on the other hand pointed to the above chronology and Mr Kuhrt's concession that he could not exclude the possibility that he had seen it to submit that the Court should find that he had. 540 Also relevant is the fact that Mr Kuhrt's allocated timeslot design had two features which were both present in the 2012 DMR Standard. These were the use of a timing master and the four additional synchronisation patterns: T626.12. There are two possible explanations for this. One is the one proffered by Mr Kuhrt that their use was obvious: T626.17. The other is that he had seen these in the 2012 DMR Standard and that the idea had lingered in Mr Kuhrt's subconscious before resurfacing in his evidence in 2018 about the obviousness of the use of synchronisation patterns to identify timeslots. 541 I have not found this is an easy matter to decide. Hytera bears the onus of proving the use of the synchronisation patterns was obvious. To do so it led evidence from Mr Kuhrt that, in summary, he thought such a use of them was obvious. Motorola sought to demonstrate that Mr Kuhrt had seen the 2012 DMR Standard in the period between April 2012 and December 2012. Whilst Hytera bore the legal onus on obviousness, I consider that Motorola bore the forensic onus of proof on this question. It was seeking to undo the effect of Mr Kuhrt's evidence. The state of the evidence leaves me such that I am not affirmatively satisfied that Mr Kuhrt did see the 2012 DMR Standard between April 2012 and December 2012. Whilst I consider, as did Mr Kuhrt, that it was possible that he saw it, I am not satisfied on the balance of probabilities that he did see it. 542 As such, the question of whether he was subtly influenced by it does not arise. It is not shown that he had seen it. I therefore reject this criticism of his evidence. Was There a Long Felt Want? 543 The Draft DMR Protocol of 2004 had used synchronisation patterns but only as a timing mechanism. That persisted into the 2005 DMR Standard. It was in the 2007 DMR Standard that synchronisation patterns were first used to convey control information but this information was limited to identifying whether the payload was voice or data and the identity of the device (subscriber unit or base station) from which the transmission had originated. As far back as the Draft DMR Protocol, it was a known limitation that subscriber units in direct mode could not utilise both timeslots. This continued to be a known problem with the 2005 DMR Standard and, indeed, with the 2007 DMR Standard. Mr Kuhrt himself became aware of the problem but did not attempt to solve it since it was not his role. 544 I accept Motorola's submission that the persons involved in the drafting of the standards were people with considerable knowledge of the topic but it would be surprising, indeed, implausible were it otherwise. I also accept Motorola's submission that the drafting of the standards involved considerable input from across the entire industry. Again, it would be surprising if it were otherwise. 545 The problem was certainly solved by the time of the 2012 DMR Standard because it did use synchronisation patterns to identify timeslots. 546 On this factual basis Motorola submitted that it had been shown that there had been a failure of others to find a solution to the problem. It submitted that this was secondary evidence of the non-obviousness of the method in the patent. No doubt, it may be accepted that secondary evidence of that kind can be important. As the High Court said in Lockwood (No 2) at [116]: An Australian court should be slow to ignore secondary evidence or to rely on its own assumed technical expertise to reach conclusions contrary to such evidence. Australian courts have long recognised that the importance of such evidence and its weight will vary from case to case; it will not necessarily be determinative. 547 However, I am not persuaded that the 2012 DMR Standard satisfied a long felt want or need. Whilst it was certainly known in DMR circles from 2004 to 3 October 2008 that subscriber units in direct mode could not utilise both timeslots, an assessment of whether this was a problem that the industry had been trying to solve across that time is non-existent. What the evidence shows is only that between 2004 and the priority date, the problem had remained unsolved. In particular, there is no evidence that anyone was working on this problem or that anyone thought that it was a problem which was worth working on. Whilst Motorola pointed out that those drafting the DMR standards had not solved the problem by the priority date, it does not follow that those persons had been working on the problem but without success. It is just as consistent with them not having turned their attention to it. In that regard, it is worth bearing in mind that the DMR standards addressed a very large range of technical issues. Not all of the issues were of equal concern and there were inevitably resource allocation questions involved in determining where improvements were to be made. It will be recalled from the 355 Patent that the scan problem was not of such significance that it warranted devoting substantial system resources to solve. What is missing in the case of the 764 Patent is evidence about how much of a problem the subscriber unit in direct mode timeslot utilisation problem actually was and how much enthusiasm the industry had for solving it in the context of all of the problems which existed. 548 Thus whilst I accept that the problem was known, I am not satisfied that it has been shown that it was something the industry was striving to solve. Since I am not satisfied of the existence of such efforts, I am inevitably also unpersuaded that I should infer that those drafting the DMR standards had failed to solve it. The evidence is equally consistent with the proposition that prior to the priority date, the problem was not thought to warrant attention. Hytera submitted that since Motorola was itself engaged in the drafting of the standards, it could easily have led actual evidence about the existence of the problem, the efforts to solve it, and the failure of those efforts. I accept this submission. 549 It is not necessary however to rely upon Jones v Dunkel (1959) 101 CLR 298. The primary evidence does not satisfy me that there had been unsuccessful efforts to solve the problem before the priority date. Consequently, I do not accept that the invention satisfied a long felt want in the sense discussed in Lockwood (No 2). Conclusions on Inventive Step 550 I therefore do not think that Mr Kuhrt's evidence demonstrates that claim 2 was obvious. It does not do so because it does not involve using synchronisation patterns to identify timeslots as part of a process of dynamic timeslot switching. Since Hytera bears the burden of proof on this topic, it has not demonstrated that claim 2 was obvious. MANNER OF MANUFACTURE 551 For the reasons I have given in relation to the 355 Patent, I would have been satisfied, if the question arose, that the patent disclosed a manner of manufacture. INFRINGEMENT 552 Since I do not accept Motorola's construction of claim 2, the question of infringement does not arise. VI THE 960 PATENT INTRODUCTION 553 The issues in relation to the 960 Patent are construction, validity (inventive step and manner of manufacture) and infringement. The priority date of the patent is 28 July 2005. The Problem of the De-keyed Base Station 554 As at July 2005, a known problem concerned the situation which could arise when a base station de-keyed. The concept of de-keying requires some explanation. It will be recalled that a base station transmits to subscriber units which are using it on a channel known as the downlink. Apart from any substantive communications from the base station (i.e. the payload), the transmissions on the downlink also include synchronisation patterns. A synchronisation pattern consists of a 48 bit sequence which is transmitted in a 5 msec interval contained in the middle of the burst in between payload transmissions. The subscriber units detect the synchronisation patterns and then use them to adjust the timing of their clocks to match that of the base station. By these means, the subscriber units and the base station are able to maintain the timeslot structure inherent in a TDMA system. 555 Because spectrum resources are limited, it is desirable that a frequency not be used if it is not necessary to do so. Accordingly, where a base station determines that there are in fact no subscriber units transmitting to it on the uplink, it turns the downlink off. That is, the base station de-keys. The uplink, by which the base station receives communications from subscriber units, remains on and is able to receive transmissions. However, whilst the base station is de-keyed, it will not repeat any communications received from subscriber units. 556 The base station does not inform the subscriber units that it is about to de-key or even that it has de-keyed. Any subscriber unit which is synchronised to the base station will, in fact, only detect this fact after it notices that it has not received any transmission from the base station for some pre-determined period of time. Some finite period of time is necessary because an instantaneous cessation in transmission from a base station does not inevitably entail that the base station has de-keyed for its transmissions may be momentarily disrupted by a variety of other phenomena. For that reason, a subscriber unit waits some short but pre-defined period of time after it stops receiving transmissions from the base station before concluding that the base station has de-keyed. 557 Once a base station has de-keyed, a subscriber unit is no longer in receipt of the timing signal constituted by the synchronisation patterns. Therefore its clock can no longer confidently be regarded as being in synchronisation with the base station's clock. This is a consequence of the phenomenon of clock drift. Further, because the base station has been de-keyed, it will no longer repeat any transmissions. A subscriber unit which wishes to initiate a transmission once the base station has de-keyed must bring this state of affairs to an end. It must both cause the base station to start sending synchronisation patterns again on the downlink (so it can synchronise with the base station's clock) and it must cause the base station to start repeating any transmissions it receives on its uplink. To do this, the subscriber unit sends the base station a 'wake-up message'. The wake-up message is what is known as an asynchronous message by which it is meant that it can be received by the base station even if the subscriber unit is not in synchronisation with it (which will of course be the case in the circumstance that the base station has de-keyed). 558 Once the base station receives the wake-up message, it changes its behaviour on both its downlink and its uplink. The downlink is switched back on and the base station begins to transmit bursts containing the synchronisation pattern but initially with no payload (known as 'hangtime messages' or 'idle messages'). So far as the uplink is concerned, it changes its operating state from being one in which it repeats no transmissions received from a subscriber unit, to a new operating state in which it will repeat any transmissions received from a subscriber unit so long as they are in synchronisation with the base station. These combined steps are together known as re-keying the base station. 559 Once the subscriber unit begins to receive the synchronisation patterns again in the form of the hangtime messages, it is able to use those patterns to synchronise its clock to that of the base station. Once it has done so, it is then able to transmit a communication on the relevant timeslot which will in turn be received by the base station on its uplink and be repeated to other subscriber units on its downlink. 560 A known problem with this intricate arrangement is the possibility that a transmission by a subscriber unit may be lost. The circumstances in which this can occur in a TDMA system are limited. By definition, a base station will only de-key when it forms the view that there is no activity by subscriber units taking place on the relevant frequency. Once it de-keys and stops transmitting synchronisation patterns on the downlink, there is a finite period of time during which it is possible that a subscriber unit may initiate a transmission while it is unaware that the base station is no longer repeating any transmissions it receives on the uplink. This finite period of time is the time set in the subscriber unit after which a failure to receive any synchronisation patterns from the base station is taken to mean that the base station has de-keyed. 561 Once that time has passed the problem disappears because the subscriber unit now knows that the base station is not repeating its transmissions and sends a wake-up message to the base station to bring this state of affairs to an end. 562 Because TDMA systems involve breaking communications into payloads which are transmitted within 30 msec bursts, and because the devices alternatively transmit via the uplink and receive via the downlink, this problem does not, as I have said, persist for very long. In particular, whilst the user may speak into the subscriber unit and hence, in that sense, be said to be transmitting, at the granular level the digital reality is that the subscriber unit is both receiving and transmitting in 30 msec bursts. The failure of the synchronisation patterns to arrive from the base station's downlink will be detected when the first expected one fails to arrive. The failure of subsequent patterns to arrive will enable the subscriber unit to know quickly that the base station has de-keyed. The Solution to the Problem Disclosed by the 960 Patent 563 The 960 Patent presents a solution to this problem in TDMA systems. It has three features. 564 First, as normal, when the base station de-keys, it turns off its downlink, and its uplink continues to receive any transmissions which might arrive from a subscriber unit. 565 Secondly, in doing this it confronts a problem. Because the subscriber unit will, by definition, no longer be receiving the synchronisation patterns from the base station, its clock will have begun to drift out of synchronisation. In the prior art, a transmission from a subscriber unit received on the uplink which was not in synchronisation was ignored. The 960 Patent moves away from this. Instead of ignoring transmissions which are received out of synchronisation, the patent introduces an element of flexibility in the base station's approach to such transmissions. It will receive and repeat transmissions from a subscriber unit on its uplink even after it has de-keyed and even if the transmissions are not precisely in synchronisation with the base station's clock. It does so by permitting the transmissions to be repeated even if they arrive a little earlier or a little later than the time the base station's clock would ordinarily expect them to arrive. The latitude implied by the concept of arriving a little early or a little later than the time dictated by the base station's clock is referred to as a 'timing window'. 566 Thirdly, the base station does not remain in this state of munificence for long. Instead, it runs a timer for a period of time. When the timer runs out, the base station fully de-keys. Since the downlink has already been turned off, this is simply a matter of ceasing to repeat any transmissions received on its uplink and waiting instead only for the wake-up message. 567 The effect of these three features is to create what the patent refers to as the 'temporary de-keyed' state. Whilst it is in that state, any transmissions from a subscriber unit which arrive are repeated even if they are out of synchronisation so long as they arrive within the timing window. At the same time, when this occurs the base station re-keys. In this way, transmissions from a subscriber unit which are commenced after a base station is de-keyed are not lost. 568 I now set out a brief summary of the arguments of the parties on the various issues and my conclusions on them. Following this brief introduction, I then turn to the issues in detail. The Construction Issue: Summary and Conclusions 569 The construction issue concerns the requirement of the patent that the transmission be received 'in proper synchronisation'. Hytera contends that even though the patent provides for some wiggle room in the timing of the receipt of the bursts from a subscriber unit in the form of the timing window, that window cannot be larger than 7.5 msec. As I will shortly explain, this construction is untenable and the patent requires the window for which it provides to be greater than 7.5 msec. 570 Underpinning Hytera's construction argument is the idea that if the timing window is larger than 7.5 msec, then the bursts transmitted by the subscriber units in adjacent timeslots will potentially overlap by trespassing beyond the 2.5 msec of guard time (1.25 msec at the beginning and end of each burst) provided for in the 2005 DMR Standard. In fact, this 2.5 msec is built into the concept of synchronisation itself. Under the 2005 DMR Standard, a burst containing a transmission will be treated as being in synchronisation if it is received up to 2.5 msec earlier or later than the time it expects the synchronisation pattern, and therefore burst, to arrive. The additional window for which the patent provides is necessarily in addition to this window and inherently must be larger than it. In any event, Hytera's objection that to proceed otherwise would result in timeslot overlapping is misconceived. The actions of a base station have no effect on that phenomenon which is dictated by the behaviour of the subscriber units. Even if the window was required to operate as Hytera suggests, the problem would persist. Inventive Step: Summary and Conclusions 571 The debate about an inventive step is as follows. Motorola submits that what was inventive about the patent was the combination of two elements. The first was the idea of permitting the base station on its uplink to receive slightly out-of-synchronisation messages after it had de-keyed. The second was the idea of using a timer to put a limit on the period of time during which it would do so as a criterion for determining that the transmissions were from a subscriber unit with which it had been previously communicating. 572 Hytera made a number of points. The first was that the problem of lost transmissions made by a subscriber unit after a base station had de-keyed was a known problem in the prior art. However, it was a minor problem and the mere stating of it also provided its solution. The problem was that the transmissions from the subscriber unit would not be arriving in the precise synchronisation demanded by the base station. The only conceivable solution was for the base station not to insist on precise synchronisation. The second point was that it was obvious that this process should not be carried on for more than a finite period of time. In particular, it was obvious that it should not be carried on for more than the period of time after which the subscriber unit would determine that the base station had de-keyed for, at that point, it would send the wake-up message. 573 Hytera submitted that the evidence of Mr Kuhrt established that these two ideas were obvious at the priority date. Mr Kuhrt had been asked to develop a repeater that reduced the risk of losing a transmission from a subscriber unit when the repeater had de-keyed. He came up with a method which involved permitting the base station to receive slightly out-of-synchronisation transmissions after it had de-keyed and which delimited the time this process could continue with a timer. It also used identification information to determine whether the transmission was from a subscriber unit with which it had previously been communicating (which is not a feature of the 960 Patent). Motorola criticised Mr Kuhrt's evidence in a number of respects. 574 As to Mr Kuhrt's idea of allowing some latitude in the receipt of out-of-synchronisation transmissions, Motorola said that the question he had been asked had pointed him in the direction of the solution he had proposed. Instead of asking Mr Kuhrt to develop a repeater for a digital conventional two-way radio system that reduced the risk of a transmission from a mobile station being lost when a repeater de-keyed, he should have been asked what method he would propose to solve the problem that transmissions could be lost if a subscriber unit sent a transmission after a base station had de-keyed. The difference between these two questions is that the former directs the person answering the question to a solution involving the base station whereas the latter is agnostic as to whether the solution should involve a base station or a subscriber unit. 575 Mr Moore cross-examined Mr Kuhrt and won from him evidence that the problem he had been asked to solve by Hytera's solicitors was not a problem he would ever have attempted to solve in the real world. Further, he agreed that had he been asked the device-agnostic question Motorola proposed, he would have solved the problem in different way. This second solution would have involved the subscriber unit emitting an error tone when it became apparent that the base station had de-keyed. This would alert the user that their transmissions were no longer being repeated by the base station. This in turn would prompt the user to press the push-to-talk button which would then cause the subscriber unit to send the wake-up message to re-key the base station. 576 As for Mr Kuhrt's proposed use of a timer, Motorola submitted that Mr Kuhrt's initial design had not included a timer and that he had only added the timer after being prompted by Hytera's solicitors to do so. Further, it pointed out that Mr Kuhrt's method did not use the timer as a criterion for determining whether the subscriber unit was one with which the base station had previously been communicating. In Mr Kuhrt's design, this function was performed by the use of identification information. 577 Into this melee there then came the evidence of Professor Wicker. He said that he would not have thought Mr Kuhrt's idea a good one and would not have proposed it. Had he been asked to solve the problem he would have caused the base station to communicate to the subscriber units that it was de-keying. Hytera criticised this approach on the basis that Professor Wicker's proposal would not have been compliant with the 2005 DMR Standard. 578 As I will explain in more detail, I accept Hytera's submission that the combination of: (a) allowing a de-keyed base station some latitude in its receipt of out-of-synchronisation transmissions; with (b) a timer to delimit how long this process went on, was not inventive. Although I accept that Mr Kuhrt was pushed in the direction of considering the problem from the perspective of a base station, I do not think that this detracts from his evidence that it was obvious to give the base station some latitude in receiving out-of-synchronisation transmissions. To state the problem was, in this case, to solve it. So too, it was inevitable that a timer had to be applied to the process if only because there was no point running the process beyond the time after which the subscriber unit would have determined that the base station had de-keyed. I do not accept that Mr Kuhrt's evidence that he would have used a timer was tarnished by the intercession of Hytera's solicitors. What his evidence in fact established was that he had left it out because it was so obvious it went without saying and did not appear to be material to any of the issues of design. Motorola made a virtue of this evidence by submitting that it showed that Mr Kuhrt's timer served an entirely different purpose to the timer in the patent. In any event, as I explain in more detail later, I accept that Mr Kuhrt always had a timer in mind and that his evidence in that regard was not prompted by Hytera's solicitors. I do not accept that Professor Wicker's evidence affects this outcome. 579 That of course leaves Motorola's point that the inventive step included the idea of using the timer as a criterion for determining whether the subscriber unit was one with which the base station was previously communicating. Whilst I accept that Mr Kuhrt's timer does not perform this function because his method uses identification information for that purpose, Motorola's submission itself rests on the false premise that the timer in the patent is used for identification purposes. Whilst one of the claims refers to a timer, the purpose of that timer is not stated in the claims and the specification does not support Motorola's submission that that was the purpose that the timer had. I therefore do not accept the submission. 580 Based on the evidence of Mr Kuhrt, I conclude that the idea of allowing a de-keyed base station to receive out-of-synchronisation transmissions was obvious as at the priority date and that a method for doing so would inevitably have to be delimited by a timer. I therefore conclude that the invention disclosed by the 960 Patent was obvious and that the relevant claims are invalid. Manner of Manufacture: Summary and Conclusions 581 For the reasons I have given in relation to the 355 Patent, there is no doubt that the method of the 960 Patent involves an advance in computer technology and is therefore a manner of manufacture. Infringement: Summary and Conclusions 582 Because the patent is invalid, the question of infringement does not arise. However, if it had arisen, the issues between the parties went as follows. Motorola alleges infringement of the patent where the method disclosed by it is used in a system comprising a non-reprogrammed base station and a non-reprogrammed subscriber unit. Hytera accepts that if Motorola's construction is correct then its non-reprogrammed base stations infringe but it does not accept that its non-reprogrammed subscriber units do. The question in relation to the non-reprogrammed subscriber units is whether Hytera's supply of them for use with non-reprogrammed base stations gives rise to liability under s 117 or joint tortfeasorship or authorisation principles. I reach largely the same conclusions in relation to these topics as I reached in relation to the 355 Patent, that is to say, that Hytera would have been liable. 583 In relation to the reprogrammed devices, Motorola alleges that the supply by Hytera of reprogrammed subscriber units for use with unreprogrammed base stations constitutes an indirect infringement of the 960 Patent. Hytera denies infringement. It submits that removing the technical functions of the subscriber units that allegedly infringe the patent would make the device non-compliant with the ETSI DMR standards. It also submits that any injunctive relief should be refused because it would be disproportionate to the threat of ongoing infringement. Largely for the reasons I have given in relation to the 355 Patent, I accept that if that patent had been valid that Motorola would be entitled to succeed on these issues. CONSTRUCTION 584 The issue which divides the parties is the meaning of the expression 'if the transmission is received with proper synchronization' in independent claims 1 and 13. Hytera submits that a transmission will only be received by a base station from a subscriber unit 'with proper synchronization' if its synchronisation pattern arrives in a window no longer than 7.5 msec in duration. Another way of putting this is that a transmission will be received with proper synchronisation if its synchronisation pattern (which is 5 msec in duration) is permitted to arrive up to 2.5 msec early or late. 585 Motorola denies the existence of any such limitation. 586 Claim 1, with its integers set out with numerical parentheses, is as follows: 1. In a conventional TDMA communications system, wherein the conventional TDMA communications system includes at least one base station and at least one mobile station, a method of accessing a de-keyed base station including: [1] de-keying a base station in the conventional TDMA communications system; [2] starting a timer in the base station when the base station de-keys; [3] receiving a transmission from a mobile station; and [4] re-keying and repeating the transmission, if the transmission is received with proper synchronization before expiration of the timer. 587 Claim 13, with its integers set out with numerical parentheses also, is as follows: 13. In a conventional TDMA communications system, wherein the conventional TDMA communications system includes at least one base station and at least one mobile station, a method of accessing a de-keyed base station including: at a base station in the conventional TDMA communications system: [1] entering a temporary de-keyed state; [2] remaining in the temporary de-keyed state for a period of time; [3] receiving a transmission from a mobile station while in the temporary de- keyed state; and [4] entering a repeat state, if the transmission is received with proper synchronization while in the temporary de-keyed state. The 960 Patent 588 The field of the invention is described at p 1 lines 4 to 6 as relating generally to wireless communications systems and more specifically to accessing a base station in a conventional TDMA communication system. The specification then explains the background to the invention to which I will shortly turn. 589 As will be appreciated from the 355 Patent and 764 Patent, base stations provide synchronisation patterns so that subscriber units can adjust their timing to that of the base station. The timing provided by the base station permits the subscriber units to process the digital communications sent by the base station to the subscriber units. It also permits them to send their transmissions in synchronisation so that the base station can receive them in a similar (although not identical) fashion. Precise timing permits the establishment of exact timeslots on a single frequency regardless of which kind of device is sending or receiving the transmission. Each timeslot is 30 msec in duration. It will be noted that in mobile stations, 2.5 msec of this 30 msec is dedicated to what is called 'guard time' meaning it is not used for the transmission of payload or control information. At this point, it is helpful to recall that a 'burst' has a total length of 30 msec and is inclusive of guard time: 2005 DMR Standard at pp 10, 17. However, there is some ambiguity in the standard about the meaning of 'timeslot'. One available view is that like the burst it is 30 msec in duration, but that it is in a fixed position that dictates the timing of the channels: 2005 DMR Standard at p 12. Another view is that the timeslot is 27.5 msec in duration contained within burst surrounded by and excluding the 1.25 msec of guard time at the beginning and end of each burst. Support for this view may be found at Figure 4.4 at p 18 of the standard which appears to label the substantive transmission of payload and overhead in each burst 'Timeslot 1' and 'Timeslot 2'. The submissions of the parties and the evidence of the experts flirted with both of these views. Other than to note the existence of this ambiguity, I do not think that the difference in these two views is material to the issues which arise. In these reasons I have adopted the former view. 590 Base stations both transmit and receive. When they transmit they are said to do so on the 'downlink' but when they receive they are said to do so on the 'uplink'. Because the spectrum available is a limited and shared resource, it is desirable to avoid unnecessary transmissions by base stations. For that reason, in a variety of circumstances, base stations turn off their downlink and stop transmitting. One situation where a base station turns off its downlink is when it comes to the view that there are no subscriber units presently transmitting to it on the uplink. Doing so permits the frequency on which the downlink was transmitting to be used by other devices. Whilst the downlink is turned off, the uplink remains turned on so that the base station is still able to receive communications. However, it does not repeat any of the transmissions it receives on the uplink whilst the downlink is off. 591 The process of turning off the downlink when the base station comes to the view that there is no subscriber unit activity to receive is known as 'de-keying', and where a base station has 'de-keyed' it is said to be in a 'de-keyed' state. Once a base station has de-keyed, before it can transmit again, it must be turned back on. The turning back on of a de-keyed base station is known as 're-keying'. Re-keying occurs when a subscriber unit, realising that the base station is de-keyed, sends the base station a 'wake-up message' on the uplink. A subscriber unit which finds it necessary to send a wake-up message necessarily will not have been receiving any transmissions from the base station. This means that it is likely that it will not be in synchronisation with the base station due to the phenomenon of clock drift (which I have discussed previously). The nature of the wake-up message, which is sent to the base station by the subscriber unit, is such that the subscriber unit does not need to be in synchronisation with the base station in order for it to be successfully received by the base station on the uplink. As I have previously said, this kind of message is known as an asynchronous message. Synchronisation patterns are another example of asynchronous messages since they too can be detected by devices even if precise timing is not present. 592 Once the base station has received the wake-up message from a subscriber unit it then re-keys and begins to transmit on the downlink. That transmission will include, of course, synchronisation patterns and the subscriber units which receive these transmissions from the base station on the downlink will then be able to synchronise with the base station. Once that is done, communication between the subscriber unit and the base station may take place on the uplink and downlink. At the same time, once the base station has re-keyed, it will repeat transmissions received on the uplink if they are in synchronisation (but ignore them if they are not in synchronisation). The base station judges whether the transmission is in synchronisation by checking to see whether the synchronisation pattern embedded in the burst from a subscriber unit arrives at the time which, according to the base station's clock, it should arrive. Thus both base stations and subscriber units send and receive synchronisation patterns to each other. However, the reasons they do so are different. The synchronisation pattern sent by a base station tells the subscriber unit what time to adjust its clock to and the subscriber unit obeys. The synchronisation pattern sent by a subscriber unit to a base station allows the base station to check to see whether the subscriber unit is in synchronisation with it. If it is not, then the base station simply ignores the transmission. 593 This understanding of de-keying and re-keying was reflected in the 2005 DMR Standard which was published in April 2005. There may be some doubt as to whether the standard constituted part of the CGK by the priority date of 28 July 2005 but it is clear that the standard is a document to which s 7(3) applies. 594 The specification explains most of the above and the nature of a particular problem which existed with such an arrangement at p 1 line 20 to p 2 line 28: In a conventional TDMA communications system, each base station (BS) provides synchronization for the MSs, so that the MSs can utilize the spectrum for communication. Once synchronization between the BS and MSs is obtained, each MS can properly receive control signaling that identifies the temporal position of each time slot within the spectrum and the time slot of the spectrum each MS can utilize for communications. Because the spectrum is often shared, the BS normally de-keys when the spectrum is not in use. As is known in the art, de-key (and conjugations of "de-key") means that the BS's transmitter is turned off. Further known in the art, de-keyed means that the BS's downlink is inactive while the BS's uplink remains active and available to detect MS transmissions. When the BS is de-keyed, even though the BS is able to detect transmissions from the MS, the BS may not be able to process the transmissions because the MS may not be in synchronization with the BS. Thus, when the BS is de-keyed, a MS can not utilize the BS for communications until a) the MS sends a wakeup message to the BS which causes the BS to re-key and b) the MS synchronizes to the BS to receive timing information about the BS. After the wakeup and synchronization processes are completed, then a MS may finally utilize the BS for communications. If the MS believes that the BS is de-keyed (e.g. due to not timely receiving synchronization), then the MS transmits the wakeup message and attempts to synchronize, which takes extra time and thus is undesirable if the MS has to send a wakeup message prior to every transmission. If the MS believes that the BS is keyed (e.g. due to timely receiving synchronization), then the MS does not transmit the wakeup message. In a conventional TDMA communications system, the MS is not explicitly notified that the BS has de-keyed. That is, there is no message that is sent from the BS to the MS that notifies the MS that the BS is about to de-key, de-keying or is de-keyed. In a conventional TDMA communications system, the MS indirectly determines that the BS has de-keyed, such as by not detecting synchronization from the BS. However, there is a finite amount of time that passes before the MS realizes that the BS has de-keyed and during this finite amount of time, if the MS sends communications to the BS, then the communications sent to the BS are ignored by the conventional TDMA communications system since (as mentioned above) the BS requires that the wakeup and synchronization processes be completed before the MS may utilize the de-keyed BS for communications. Ignoring communications is a problem because the user of the MS does not have knowledge that the communications have not been received by the intended recipient of the communications. For example, if an emergency communication is placed by emergency personnel, as a user of a MS, and the BS is de-keyed, then the emergency personnel is not aware that the emergency communication has not reached its intended recipient, e.g. emergency personnel at a police station. In any case, ignoring communications is a problem. Accordingly, there is a need for an improved method of accessing a de-keyed base station in a conventional TDMA communications system. 595 So the problem is that the subscriber unit receives no direct notification that the base station has de-keyed and only works this out when, after a while, it has stopped receiving transmissions from the base station. During the period before the subscriber unit realises the base station has de-keyed, the subscriber unit may initiate communications to the base station without realising that the base station is no longer repeating its transmissions. It is worth emphasising that the transmissions which are affected by this problem are only those which are initiated during this period. That they must be initiated follows from the fact that the base station has de-keyed precisely because there was no subscriber unit activity on the uplink. 596 The sending of communications by a subscriber unit which unbeknownst to it are not repeated is undesirable. The problem identified by the patent is the problem of accessing a de-keyed base station in a conventional TDMA communications system: p 2 lines 27 to 28. In essence, it is the problem of capturing transmissions which a subscriber unit makes after a base station has de-keyed but before the subscriber unit has realised that it has de-keyed. 597 A summary of the invention is then given by means of some consistory clauses at p 2a line 7 to 2b line 8. This is followed by a detailed description of the invention at p 3 line 17 to p 11 line 5. 598 At the heart of the dispute between the parties about the meaning of 'proper synchronisation' in claims 1 and 13 is a passage in the 'detailed description' of the patent at p 8 lines 11 to 31 and the figure with which it is accompanied, Figure 3. These are as follows: As used herein, proper synchronization means that the transmission is received within timing boundaries, also known as a window. Referring to FIG. 3, shown is a timeline 300 for the uplink of a BS. The timeline 300 shows two timeslots 314, 316 and windows of time (namely TEXPECTED) 302 that the BS expects to receive transmissions from the MS. In one embodiment, TEXPECTED is approximately 5 milliseconds. To compensate for delays in transmission, signal propagation delays between the MS and BS, and reference oscillator variability between the BS and the MS, the BS allows for transmissions to arrive earlier and later than the window 302 of TEXPECTED. In one embodiment, TEXPECTED is approximately 7.083 milliseconds. Also, in one embodiment, proper synchronization means that the transmission is received within the window 308 of time termed TWINDOW. In any event, if transmissions are received outside the window 308 TWINDOW, then the transmission is not received with proper synchronization and will not be processed (RxSyncOutOfWindow, Transition 214). For example, a transmission 310 that is received too early is not processed and a transmission 312 that is received too late is not processed where early and late means that the transmission is received outside the window 308 TWINDOW. The assumption is that the MS was not in synchronization with the BS before the BS de-keyed, so the BS does not need to process the transmission because the MS was not properly associated with the MS so the MS [sic: BS so the BS] does not need to re-key to process a transmission from an MS that is not properly associated with the BS. 599 Hytera's contention is that 'proper synchronisation' requires TWINDOW to be less than 7.5 msec. Some Matters Which Are Not In Dispute 600 Neither TWINDOW nor TEXPECTED are, in terms, required by the terms of the claims or the specification to have any particular duration. The passage above suggests different embodiments where TEXPECTED is in one case approximately 5 msec (p 8 lines 15 to 16) and in another, 7.083 msec: p 8 line 19. In no embodiment in the specification is there a suggestion for any particular value for TWINDOW. However, it is evident from page 8 lines 16 to 22 that TWINDOW is always longer in duration than TEXPECTED. Indeed, it is the point of TWINDOW to be longer in duration than TEXPECTED. This understanding of the relationship between TWINDOW and TEXPECTED is confirmed by Figure 3. 601 Page 8 lines 22 to 28 and Figure 3 also show that a base station in which the invention is implemented will cause a transmission containing a synchronisation pattern which is received inside TWINDOW to be repeated, but will not do so if the synchronisation pattern is received outside TWINDOW. Some Matters Which Are Clear 602 Although the patent does not refer to the 2005 DMR Standard, a person skilled in the art implementing the invention would not do so in a way which did not comply with that standard. 603 Under the 2005 DMR Standard, the structure of a standard TDMA burst was set out at p 18: 604 It is not in dispute that under the 2005 DMR Standard, the synchronisation pattern (or the embedded signalling) was contained in a 5 msec interval in the middle of each timeslot. It will be observed that each 30 msec burst consists of a transmission comprising payload and overhead (in the form of the synchronisation pattern) which is 27.5 msec in duration and that after the end and before the beginning of each transmission there is an additional 1.25 msec within the timeslot. When the 1.25 msec at the end of one timeslot is combined with the 1.25 msec at the beginning of the next, a period of 2.5 msec is created. However, the basic frame structure remains the 30 msec burst. Whilst it is true to say that 2.5 msec of each burst is not devoted to the transmission of payload or overhead, it is important to keep in mind that this is a 2.5 msec period split in half with 1.25 msec at the beginning and end of each burst. The practical effect is, however, to leave 2.5 msec between each transmission. 605 It will also be seen that where the transmitting device is a base station, the 2.5 msec is used for the transmission of the CACH message (of the kind discussed in the 355 Patent): see Figure 4.5. Figure 4.4 above does not explain what the 2.5 msec is used for in the case of a transmission from a subscriber unit. It was not in dispute however that where a transmission was made from a subscriber unit to a base station this 2.5 msec was used as 'guard time'. According to p 16 of the 2005 DMR Standard, the purpose of guard time was to allow for 'power amplifier ramping' and 'propagation delay'. These concepts are explained at pp 88-89 of the 2005 DMR Standard. The former relates to the fact that as the transmitter on the subscriber unit is rapidly turned off and on, it takes a very short of amount of time for the signal strength to reach an appropriate level. One purpose of the guard time is to allow an interval during which this may occur. The latter relates to the fact that the further away a subscriber unit is from a base station, the longer the radio signal takes to arrive. The timeslots which arrive from a subscriber unit 10 m from a base station will arrive sooner than the timeslots which arrive from a subscriber unit which is 150 km away. Another use of the guard time is to take account of this kind of delay. 606 At [53(d)] of its closing submissions, Hytera submitted that the under the 2005 DMR Standard: … a small amount of delay, drift or jitter of a transmission within a timeslot was allowed for as at July 2005, by the inclusion of the guard time between each burst. A transmission would remain within the timeslot boundaries if the delay, drift or jitter was less than amount of the guard time. (emphasis in original) 607 The reference to guard time between a burst is not correct. The guard time is at the end and beginning of each burst and forms part of it. Professor Wicker gave this evidence at T261.40-262.7: MR DIMITRIADIS: I will – I will ask another – I will approach it in a different way. Professor Wicker, you were familiar with the concept of guard time as at July 2005 in relation to TDMA systems? PROF WICKER: That's correct. MR DIMITRIADIS: And guard time, as at July 2005, was a short period of time towards – well, at the end of a time slot where there was a gap in the information or transmission sent by a mobile station to a repeater, correct? PROF WICKER: Well, actually, the guard time would have been before and after the placement of the burst within the slot, the idea being we're guarding against movement of that burst, leaving room for a distilled beam within the slot. 608 The italicised portion of Hytera's submission suggests that any drift occurred within the timeslot. The existence of the guard time as part of the burst structure soaks up any drift or jitter in the transmission. This is consistent with the frame structure set out above and with Professor Wicker's evidence. The point of the guard time is to accommodate the early or late arrival of a transmission by an amount up to the guard time. 609 Hytera submitted, and I accept, that the point of the guard time is to avoid the problem of the transmissions which are meant for different timeslots overlapping with each other. The guard time ensures that transmissions which arrive early or late by no more than 2.5 msec do not overlap. Although literally correct, however, Hytera's submission requires clarification. The guard time is inserted into the burst by the subscriber units, not by the base station. The point of the guard time is to ensure, as Hytera submitted, that transmissions from two different subscriber units do not overlap. Although the base station needs to adjust its reality to the fact that the subscriber units are sending transmissions with guard time (so as to permit some drift or jitter, as Hytera put it), it is not the base station's recognition of the existence of the guard time that is the cause of that phenomenon. Because it will be important later, it is therefore to be emphasised that the guard time is set by the subscriber units and not by the base station. 610 Returning then to Hytera's submission that proper synchronisation means that a transmission is received within TWINDOW where TWINDOW is always less than 7.5 msec, it may next be observed that the patent contains no such express stipulation. 611 It follows that if there is a requirement that TWINDOW should be less than 7.5 msec, it must either arise as a matter of implication from the terms of the patent or as a requirement flowing from the 2005 DMR Standard. Hytera did not submit that the implication arises from the former. Instead, its argument is that it is a necessary incident of the 2005 DMR Standard. Hytera's Contention That TWINDOW Must Be Less Than 7.5 msec In Duration 612 Under the 2005 DMR Standard there is 2.5 msec between each transmission (of payload and the synchronisation pattern or other control information) by a base station or a subscriber unit. Each transmission is 27.5 msec in length and forms part of the 30 msec burst. At the beginning and end of each 30 msec burst, there is an interval of 1.25 msec which in the case of a transmission by a subscriber unit is designated as guard time. Looked at from the perspective of the frame burst, there is a total of 2.5 msec of guard time in each burst which is divided into two halves of 1.25 msec at the beginning and end of the burst. Looked at from the perspective of the 27.5 msec transmissions, each is separated by 2.5 msec of guard time. That 2.5 msec of guard time is, however, made up of two 1.25 msec intervals of guard time occurring in separate bursts. 613 I have accepted above Hytera's submission that the purpose of the guard time is to prevent transmissions overlapping each other. Professor Wicker's evidence (and Hytera's corresponding submission) shows that the timeslots can be subject to slight drift or jitter. The purpose of the guard time is to ensure that this drift or jitter does not result in a transmission on timeslot 1 from one subscriber unit overlapping with a transmission on timeslot 2 from another. I have also noted above that the overlapping is prevented by the subscriber units transmitting their bursts such that guard time is included. As I will shortly explain, the fact that the bursts transmitted by the subscriber units may arrive up to 2.5 msec early or late is therefore something which the base station must adapt to in deciding whether a transmission has been received in synchronisation. However, whatever criterion is imposed by the base station in that regard has no impact on whether overlapping occurs. In relation to the topic of overlapping transmissions by two subscriber units, the base station is a passive observer. 614 Hytera's next step is the critical one. Since under the 2005 DMR Standard the synchronisation pattern is 5 msec in duration, TWINDOW could not be permitted to have a value which would allow the transmissions in adjacent timeslots to overlap. Overlapping would occur if the size of TWINDOW exceeded the size of the guard time. Since the synchronisation pattern was 5 msec in duration and the guard time was 2.5 msec in duration, it followed that TWINDOW could never be more than the sum of these two timing intervals, that is to say, 7.5 msec. 615 Since proper synchronisation in claims 1 and 13 meant that a transmission had to be received inside TWINDOW and since TWINDOW had to be less than 7.5 msec by reason of the 2005 DMR Standard, it followed that a transmission would not be received with proper synchronisation within the meaning of claims 1 and 13 unless it was received in a window no larger than 7.5 msec. Assessment of Hytera's Contention 616 I do not accept this argument. It is true that under the 2005 DMR Standard the burst for a transmitting subscriber unit includes 2.5 msec of guard time. As the evidence of Professor Wicker shows, and as Hytera's submission confirms, a transmission which arrives within the 27.5 msec allotted to it plus or minus the guard time of 2.5 msec is treated by the base station as being received 'within the timeslot boundaries': HCS(P) ch 1 at [53(d)]. The implication of this is that such a transmission is treated as having been received in synchronisation. 617 The concept of being in synchronisation under the 2005 DMR Standard therefore includes an allowance for drift (or jitter) by up to the amount of the guard time (at least according to Professor Wicker and Hytera). If this were not so, then neither Professor Wicker's evidence nor Hytera's submission makes any sense. The guard time would serve no purpose if transmissions which have drifted or jittered by less than the guard time are not repeated. I did not apprehend that Professor Wicker intended to suggest otherwise and Hytera's submissions did not do so. 618 Motorola did not take me to any part of the 2005 DMR Standard to rebut Professor Wicker's evidence about the significance of guard time from the base station's perspective. In that circumstance, I propose to accept it. Had it been relevant, my own cursory reading of pp 88-89 of the 2005 DMR Standard appears to confirm what Professor Wicker says. 619 This conclusion that under the 2005 DMR Standard a base station will treat as being in synchronisation a transmission which is up to 2.5 msec early or late is important for two reasons. First, as I have noted at the outset, the patent does not specify how large TEXPECTED must be. However, in light what has just been said, TEXPECTED must be 7.5 msec if the invention is to be implemented in accordance with the 2005 DMR Standard (the only possible way it would be implemented). Only if TEXPECTED is 7.5 msec can Professor Wicker's observations (and Hytera's corresponding submission) about drift and jitter and the 2.5 msec of guard time be made to cohere with the fact that a synchronisation pattern is 5 msec in duration. 620 Secondly, this spells the end of Hytera's contention that the TWINDOW must be less than 7.5 msec. The one thing which is clear from the patent is that TWINDOW is always larger than TEXPECTED. If TEXPECTED must be 7.5 msec it must inevitably follow that TWINDOW must be greater than 7.5 msec. In fact, Hytera's contention that there must be a 7.5 msec window of some kind is correct. What is erroneous about the contention is its identification of that window as being TWINDOW. In fact, it is TEXPECTED which is required by the DMR Standard to be 7.5 msec. 621 This leaves Hytera's submission that if this be so, then transmissions from different subscriber units will overlap. Subject to a minor correction, I accept this submission but do not believe that it is material in the context of the invention disclosed in the patent. 622 The minor correction is that it is not inevitable that the transmissions will overlap if TWINDOW is greater than 7.5 msec. Context is all. The context is two subscriber units which have both decided to initiate a transmission after the base station has entered the temporary de-keyed state but before either has worked out that this has occurred. Necessarily, because the base station has entered the temporary de-keyed state it has stopped transmitting synchronisation patterns. In this scenario, the timing of the base station is irrelevant because, by definition, it does not exist. 623 Any overlapping which occurs will, rather, be a consequence of the degree to which the clocks of the two subscriber units have drifted out of synchronisation with each other. The occurrence of the phenomenon of overlapping transmissions following the de-keying of a base station therefore involves a domain of discourse in which the clock of the base station is extraneous. The central timing signal has been turned off. The subscriber units are marching to their own tune. Whether they will end up treading on each other's toes will depend on the beat of the tunes they are individually playing and not on the beat of the tune which the base station is no longer playing. 624 This will be a function of whether the timing of the two clocks in the two subscriber units drift apart by more than the guard time. This is by no means inevitable. They may drift in opposite directions by an insufficient amount to exceed the guard time cumulatively. They may just as well drift in the same direction. 625 Secondly, and more importantly, in the context of a de-keyed base station, these transmissions are the very transmissions which the invention disclosed in the patent is designed to catch. This point may be made in two steps. The first step concerns the position under the 2005 DMR Standard. Under the standard, the fact that the transmissions which occur after the base station has de-keyed may overlap with a transmission in an adjacent timeslot is irrelevant. The base station has de-keyed and is ignoring all transmissions (that are not the wake-up message) received on the uplink. For all the base station cares, the subscriber units which have initiated a transmission after it has de-keyed may be playing the theme from the Pink Panther. If the transmissions overlap, it is stolidly indifferent. This underscores that any overlapping which occurs is driven by the behaviour of the subscriber units and is unrelated to the attitude of the base station. 626 The second step concerns the invention disclosed by the patent. Where two subscriber units initiate transmissions after the base station has entered the temporary de-keyed state their relative clock drift may, or may not, exceed 2.5 msec. Assuming that the drift does exceed 2.5 msec and therefore that overlapping occurs, it is difficult to see what the base station can do about this. In particular, a decision by a base station to assign a different value to the guard time from that which the subscriber units are using has no impact on the guard time they are using. More bluntly, if the base station was set so that it assumed the transmissions from the subscriber units included 5 msec of guard time this would have no impact on the subscriber units which would continue to transmit with 2.5 msec of guard time. All that would be present in that scenario would be an incorrect assumption. 627 Consequently, I do not accept the unstated assumption in Hytera's submission that how the base station approaches the guard time has any impact on whether timeslots will overlap with each other. 628 For completeness, I reject as frivolous Hytera's submission that a delayed transmission from a subscriber unit will result in the base station repeating that transmission in a delayed fashion. Any transmission received by a base station which it decides to repeat is retransmitted in accordance with its own timing and is by definition always in synchronisation. 629 Consequently, whilst I accept that the fact that TWINDOW must be longer than 7.5 msec in duration may lead to situations where transmissions overlap, I do not think that this amounts to any more than a wrinkle. The word wrinkle is appropriate because the circumstances in which an overlap can occur are confined by the necessity for several things to happen. These are that: (a) the two subscriber units using the frequency have not transmitted on either timeslot for a sufficiently long period of time for the base station to conclude that there is no activity on the uplink; (b) the base station enters the temporary de-keyed state; (c) whilst in that state, both subscriber units initiate communications and send a transmission on each timeslot; and (d) the time drift between their two clocks caused by the non-receipt of synchronisation patterns from the base station has developed: (i) sufficiently far in the time before the subscriber units realise that the base station has de-keyed; and (ii) in the correct direction by a sufficient amount of time, to cause their transmissions to overlap. 630 In this regard, I was not taken to any evidence about how prevalent this problem would be. I would infer that it is a function of at least the size of TWINDOW. But TWINDOW itself is delimited in a practical sense by the time it takes for the subscriber units to work out that the base station has de-keyed (there being no point pursuing these transmissions once the wake-up message has been sent). An assessment of the magnitude of the problem would therefore require an assessment of how far two clocks can drift apart in that time. I did not apprehend either party to make any factual submissions about this. Consequently, whilst I accept that having a value for TWINDOW which is greater than 7.5 msec may lead to an overlapping of transmissions from subscriber units, I am unable to conclude that this is anything other than a possible downside of the invention or, as I have termed it, a wrinkle. 631 I therefore reject Hytera's contention that for a transmission to be received with proper synchronisation in claims 1 and 13 it must be received within a 7.5 msec window. Residual Matters Figure 3 632 A number of submissions were made about Figure 3. In my view, Figure 3 establishes two propositions only: (a) TWINDOW is always longer than TEXPECTED; and (b) transmissions which are received where the synchronisation pattern falls within TWINDOW will be repeated but those which do not will not be repeated. 633 Any further use of Figure 3 is inappropriate because it contains serious errors. These are: (a) the timeslot 314 is a different size to the timeslot 316 which is impossible in any TDMA system; (b) the bursts which are illustrated are different sizes, also an impossibility in any TDMA system; and (c) it suggests that TEXPECTED is the same size as the synchronisation pattern which, whilst possible in a vacuum, is not possible under the 2005 DMR Standard. A person implementing the invention in the patent would know that TEXPECTED had to be 7.5 msec wide to comply with the 2005 DMR Standard and that the invention could not be implemented as Figure 3 suggests. 634 Problems (a) and (b) make any attempt to draw conclusions about timeslot boundaries from Figure 3 a forlorn escapade. Hytera relied on the evidence of Professor Viterbo to suggest a rococo redrawing of Figure 3 which Motorola then annotated with its own suggested brushstrokes. Although colourful, both seem to be hopeless enterprises. The better course is the one which I have taken, which is to extract from Figure 3 only matters which can be found in the text of the specification. Claims 2 and 8 635 Motorola placed some reliance on claims 2 and 8. 636 I do not think that claims 2 and 8 impact on the interpretation issues. It is plain that claim 1 includes the concept of a timing boundary. The reference to timing boundaries in claim 2 is therefore otiose but this is not a problem. Likewise, I regard Motorola's reliance on claim 8 as marginal at best. The concept of 'without proper synchronisation' is the obverse of 'with proper synchronisation'. I do not think it adds to the picture. The Reference to TEXPECTED Being 7.083 msec 637 Finally, filled with excessive zeal from its attempted redrawing of Figure 3 by Professor Viterbo, Hytera submitted that the reference at p 8 line 19 to TEXPECTED being 7.083 msec was erroneous and should be taken to be a reference to TWINDOW. Professor Wicker denied this at T263.43-46. As he explained, if it were a reference to TWINDOW then what is at p 8 line 21 is out of sequence for it is only at that point that TWINDOW is defined. In fact, the problem Hytera confronts with p 8 line 19 referring to TEXPECTED being 7.083 msec is that it draws attention to the fact that TEXPECTED need not be the same size as the synchronisation pattern and therefore invites attention to the question of whether, in the context of the 2005 DMR Standard, the guard time is to be accounted for in TEXPECTED or in TWINDOW. As I have said, Hytera is right that the guard time must be brought to account but wrong about where it is to be brought to account. 638 Finally, as I have said, an implementation of the invention which complied with the 2005 DMR Standard would require TEXPECTED to be 7.5 msec. The reference to TEXPECTED being 7.083 msec in one embodiment would be an implementation of the invention which was non-compliant with the standard. The same may be said of the fact that Figure 3 suggests that TEXPECTED is the same size as the synchronisation pattern. The fact that the specification refers to embodiments which are not standards compliant does not impact on these conclusions. VALIDITY The Common General Knowledge 639 Before July 2005, the CGK was as follows: Synchronisation and Synchronisation Patterns 640 It was known how subscriber units synchronised to keyed repeaters and that without a timing signal (i.e. the synchronisation pattern) from a base station on the downlink, subscriber units would drift out of synchronisation. It was known that base stations have a clock and that this clock is used to set the timing boundaries of each repeating frame on the downlink. Each TDMA frame is 60 msec in duration and is made up of two continuous 30 msec timeslots. Within the first timeslot was a 30 msec burst, 27.5 msec of which was a transmission made up of payload and overhead. The second transmission, also of 27.5 msec duration was contained in the second burst within the second 30 msec timeslot. At the beginning and end of each burst was 1.25 msec of guard time. In practical terms, therefore, the frame contained two transmissions separated by 2.5 msec of guard time. At the front and back end of the frame were two 1.25 msec intervals of guard time. When two consecutive frames are considered next to each other these 1.25 msec periods also meant that a transmission in one frame was separated from a transmission in the next frame by 2.5 msec. 641 In the middle of each 27.5 msec transmission there was a period of 5 msec which was used either for the synchronisation pattern or for embedded signalling information. 642 The subscriber unit synchronises to the base station's timing by recognising the synchronisation pattern that is embedded in the base station's transmission on the downlink. The timing of the system was always dictated by the base station and never by the subscriber units. In this sense, the base station was the 'timing master'. Subscriber units would synchronise with a base station but not vice versa. The effect of the base station being the timing master is that the subscriber units using the base station were operating with the same timing. 643 Nevertheless, where a subscriber unit in repeater mode transmitted a burst, it too would embed in each transmission a synchronisation pattern. The purpose of this pattern was not, however, to permit the base station to synchronise with the subscriber unit. Rather, it was used by the repeater to determine whether the subscriber unit's transmission on the uplink was synchronised to that of the base station. The base station would do so by checking to see whether the synchronisation pattern was received within the period of time during which the base station's clock dictated that it should arrive. 644 Hytera submitted that it was part of the CGK that the reason the base station checked the synchronisation pattern in this way was to ensure that subscriber units did not interfere with one another on the uplink when they simultaneously transmitted on it. I do not accept this submission. The evidence for it was said to consist of three elements. The first was some evidence of Professor Wicker and Professor Viterbo at T223.46-224.27: MR DIMITRIADIS: Yes. I'm happy to deal with it, your Honour. Professor Wicker, could you please consider this scenario: as at July 2005, consider in a conventional TDMA system a mobile station sending a transmission to a base station, and the base station has not de-keyed. In that scenario, if the transmission sent by the mobile station to the base station is received by the base station and the transmission encroaches into the next timeslot on the base station's uplink, that is not a properly – I'm sorry, that is not a synchronised transmission. Do you agree with that? PROF WICKER: I would agree that whatever synchronisation the mobile station had has either drifted. There's some sort of error in the mobile station that's causing it to transmit outside of what the base station is trying to establish as the timeslot. MR DIMITRIADIS: You would agree, would you not, that a transmission received in that scenario that I put to you that encroaches into the next timeslot on the base station's uplink would not be regarded as a synchronised transmission. That's right, isn't it? PROF WICKER: I would agree that the transmission that has moved over into an adjacent – or slightly infringed on an adjacent timeslot is not synchronised to the base station's establishment of those timeslots. MR DIMITRIADIS: Thank you. I might invite Professor Viterbo to indicate his view on the evidence that Professor Wicker just gave, whether he agrees or disagrees. MR MOORE: Well, I - - - PROF VITERBO: I agree. 645 I do not accept that this establishes that the reason the base station checks the synchronisation pattern is to ensure that the subscriber units do not interfere with each other on the uplink. 646 The second was evidence given by Mr Kuhrt in Kuhrt-1 at §§128-130. Nothing at §§128-129 is material. At §130, Mr Kuhrt says that the repeater sets the timing and by these means ensures that the subscriber units are operating on the same timing reference 'without conflicting with one another'. However, this is a statement about the purpose of the base station's transmission of its synchronisation pattern on the downlink, not a statement about why the base station checks the synchronisation pattern on the uplink. I do not accept therefore that this evidence makes good Hytera's submission. 647 The third item of evidence was said to be in Kuhrt-2 at §420. This paragraph does not contain any evidence to support Hytera's submission. 648 There is no evidence therefore to support the proposition that it was CGK that the reason the base station checked the synchronisation pattern embedded in the subscriber unit's transmission was to ensure that subscriber units did not interfere with each other by intruding on each other's timeslots. In fact, a little reflection shows this cannot be correct. As I have explained above when dealing with the construction question, the receipt by the base station of transmissions on its uplink has no impact on the behaviour of the subscriber units which will continue to transmit until they become aware that the base station has de-keyed. During that period the subscriber units will transmit according to their own clock. If the clocks of two subscriber units have drifted sufficiently such that their timeslots are overlapping then that will occur. Nothing the base station does by receiving transmissions on its uplink during this period can have any impact on this because the base station is not transmitting a timing signal on the uplink (by definition because it is the uplink) and because, in this scenario, the downlink is turned off. It is therefore impossible for Hytera's contention to be correct. 649 On the other hand, I do accept that it was CGK that if the subscriber unit's transmission received on the uplink was synchronised with the base station's clock, it would be repeated, otherwise it would be ignored. The purpose of the base station checking whether a transmission received on its uplink was in synchronisation was therefore to act as a criterion by which the base station would decide whether to repeat the transmission. In-synchronisation transmissions would be repeated; out of synchronisation transmissions would not. Nor is it the case that the decision by the base station not to repeat transmissions can be seen as a mechanism which prevents the out-of-synchronisation message being repeated by the base station as a further transmission which is not in synchronisation. Where a base station repeats a transmission it does so in accordance with its own timing. The timing of that transmission has nothing to do with the timing with which it is received by the base station. 650 Consequently, the decision by a base station either to repeat or not repeat a transmission on the basis of its synchronisation status, has nothing to do with ensuring that subscriber units do not transmit communications in such a way that transmissions in adjacent timeslots overlap with each other. Drift 651 For various reasons, once a subscriber unit stops receiving transmissions from the base station on the downlink, its clock begins to drift out of synchronisation with the clock of the base station. How long it takes a subscriber unit to drift out of synchronisation depends on a range of factors. These include the quality of the hardware but other factors can affect it as well. The period involved may be less than a second but can be up to a few seconds. The De-keying of a Base Station and the Sending of Wake-Up Messages To Re-Key It 652 Base stations may de-key for a number of reasons. One of those reasons is because no subscriber unit is presently transmitting on the uplink. When this occurs, the base station begins a fixed timer referred to as a 'hangtimer'. If no transmissions are received by the expiry of the hangtimer then the base station de-keys. The consequences of the base station being de-keyed are that: (a) the transmitting downlink is turned off; (b) the base station's clock continues to operate; and (c) the base station's uplink remains on and able to receive transmissions. However, whilst it remains able to receive transmissions, the base station does not repeat them. The only transmission which it will act upon is the asynchronous wake-up message prompting it to re-key. When the base station is re-keyed, the downlink is reactivated by turning it on and it begins to send transmissions (which contain synchronisation patterns). At the same time, the uplink will receive transmissions and repeat those which are in synchronisation. 653 A de-keyed base station is re-keyed when it receives a wake-up message from a subscriber unit. As previously mentioned, this is a message which can be received by the base station from a subscriber unit even though they are not in synchronisation (i.e. an asynchronous message). The wake-up message is sent by the subscriber unit when it has determined that the base station has de-keyed. It sends the message when it wishes to send a transmission. It cannot send that transmission until it has synchronised to the base station. Once the base station receives the wake-up message it turns its transmitter back on and starts sending transmissions which contain synchronisation patterns. Once the subscriber unit detects these synchronisation patterns it is then able to adjust its clock and having done that it may transmit to the base station in synchronisation. 654 This method of re-keying a de-keyed base station formed part of the 2005 DMR Standard. Timers 655 As already mentioned, the base station used a timer (the hangtimer) to determine when it should de-key. 656 The temporary de-keyed state disclosed in the patent involves the use of a timer as well. This timer determines how long the base station remains in the temporary de-keyed state before entering the fully de-keyed state. The use of a timer in this particular fashion was not part of the CGK as at July 2005 and did not form part of the 2005 DMR Standard. 657 However, the use of timers in two-way digital radio mobile communications was well-known at this time. Timers were used, inter alia, to transition between states. The use of timers was a well-known building block for communications systems. One use of a timer is to bring to an end an algorithm. It is good engineering practice only to operate algorithms as long as they are needed. There were at least two reasons for this. First, an algorithm requires system resources to operate, as Mr Kuhrt explained in his evidence. The operation of an unneeded algorithm involves a waste of system resources. Secondly, the longer an algorithm runs, the more prone to error it is. Timers were a well-known way of terminating the operation of an algorithm and avoiding these problems. The Risk of Ignored Communications 658 It was also CGK, as I have already mentioned, that there was a risk of a transmission made by a subscriber unit being ignored by a base station if it had de-keyed and the subscriber unit had not yet become aware of this fact. 659 In a TDMA system (as opposed to an FDMA system) the risk was known to exist only for a finite period of time. This period of time began when the base station de-keyed and ended when the subscriber unit detected that the base station had de-keyed. It would detect that the base station had de-keyed when it had not received a transmission from the base station for some period of time. Because in a TDMA system, the subscriber unit rapidly alternates between sending and receiving 30 msec bursts, a subscriber unit could detect that a base station had de-keyed even if the user was in the middle of speaking. 660 In practice, therefore, the problem manifested itself in a minimal fashion. The time it took for the subscriber unit to detect that the base station was de-keyed was typically small (<1 sec). If the subscriber unit sent the wake-up message immediately, the loss of transmission was of a similar order. 661 It is then necessary to mention the position in relation to FDMA systems. It will be recalled that FDMA systems had existed since the 1990s when the P25 Standard was introduced (by contrast, the 2005 DMR Standard for TDMA systems had only been issued in 2005). As explained above in Chapter II, FDMA split a 12.5 kHz channel into two smaller 6.25 kHz channels which could both be used for communications. In FDMA systems, a base station would also de-key after a period of no activity by subscriber units. However, because the transmission by the subscriber units was continuous on the frequency, and the subscriber unit could not receive at the same time that it transmitted, there was no way in which the subscriber unit could determine that the base station had ceased transmitting until after the user had completed their full transmission. As a result, for example, if the user continued to talk for 30 seconds after the base station had de-keyed, the subscriber unit would not know it had done so until the user stopped talking. The whole of the 30 second transmission would be lost. 662 The de-keyed base station problem was therefore a significant issue with FDMA systems but was a 'minor' problem with TDMA systems. Mr Kuhrt acknowledged this in Kuhrt-3 at §34. On the other hand, he and Professor Wicker both thought that it was nevertheless a real problem in the context of first responders in TDMA systems. Mr Kuhrt did not consider that as at July 2005 there was any technical motivation to solve the problem. In Mr Burgess' closing oral submissions in the patent phase of the trial, he described the problem as a 'glitch'. I think this perhaps goes too far, but it was not a large problem and its resolution was not a burning objective of those working in the DMR field. The 2005 DMR Standard 663 Hytera submitted that the 2005 DMR Standard formed part of the CGK as at the priority date. This may be doubted since the standard was only three months old at that time. In any event, the standard was a document to which s 7(3) applied. Hytera's Case on Obviousness 664 Hytera submitted that any method falling within the asserted claims would have been obvious in July 2005 to the hypothetical skilled person in light of the CGK (including the 2005 DMR Standard). It said that both the problem and its solution were obvious. 665 As to the problem being obvious, Hytera submitted that both Mr Kuhrt and Professor Wicker agreed that they would have recognised the existence of the problem in the 2005 DMR Standard. The problem was also minor. I accept that it was minor in the sense that it was in the nature of an occasional annoyance for users. Hytera submitted that it was also minor from a technical perspective but I do not think the evidence bears out that submission (which is not to accept that the evidence shows that it was not minor). On the other hand, I do accept its submission that a solution to the problem was not something that could be described as a 'long felt want'. Given that the ink on the April 2005 DMR Standard was barely dry at the priority date of July 2005, this is hardly surprising. Indeed, Motorola did not submit that the invention disclosed in the patent satisfied a long felt want. 666 I do not accept, as Motorola submitted, that the question of obviousness can be buttressed by consideration of the position in relation to FDMA. There the problem of accessing a de-keyed base station was known to exist and to be a greater inconvenience to users. No doubt the problem in FDMA had not been solved by 2005 but I would decline to infer without a little more that this shows that persons had worked on the problem and failed to solve it. Further, even assuming that persons had been trying to solve the problem in FDMA, it would not follow that this made its solution in TDMA less obvious. The technical underpinnings of TDMA and FDMA are different. What might be very difficult to solve in one technology can be trivial to solve in another. For example, consider the problem of sending a text message from one phone to another. There would be considerable, although not insuperable, difficulties in sending a text message from a traditional analogue phone connected to a copper pair network to another analogue phone. However, sending a text message on a digital phone which is connected to a digital network is a much less challenging task. The fact that people in the industry had tried and failed to provide for text messaging on analogue phones would not tell one much about how obvious a solution for sending text messages was for digital phones on digital networks. Attention must therefore remain focussed on the technology in which the obviousness inquiry is undertaken. Here, so it seems to me, there is a critical difference from the perspective of obviousness between FDMA and TDMA. This is that TDMA permits transmission and receipt of bursts nearly simultaneously. No such facility exists in FDMA (which is the reason why the problem is worse). Thus, whilst the problem for both may be loosely described as how to access a de-keyed base station, that description is apt to disguise the differences between them when it comes to consider whether a solution to the problem is obvious. What might be challenging in FDMA might well be trivial in TDMA (at least as a matter of logic). 667 Hytera then submitted that the substance of the invention was a software algorithm that was programmed into the repeater. This algorithm was programmed to operate for a finite period of time, using a timer. It caused the repeater to re-key and repeat the transmission if it was received with proper synchronisation before the expiry of the timer. This involved a combination of two elements: (a) receipt with proper synchronisation (i.e. the receipt of a transmission slightly out of synchronisation, but not so far out of synchronisation that it was not 'properly synchronised'); and (b) receipt in that fashion before the expiry of the timer. The method in claim 1 does not have a timer but the method in claim 8 does: 8. The method of any one of the preceding claims further comprising ignoring the transmission, if the transmission is received without proper synchronization before expiration of the timer. 668 Hytera submitted that this could readily be expressed in an algorithm or algorithms which I accept. 669 Dealing first with the concept of repeating a transmission even if it is received slightly out of synchronisation, Hytera submitted that the nature of the problem suggested the solution. The problem was that a transmission from a previously synchronised subscriber unit was ignored by the base station. The solution to that problem was, so Hytera submitted, to program the base station in such a way that the transmission that would otherwise be ignored was repeated. This does appear to be obvious and indeed Professor Wicker accepted that the solution 'to having a transmission lost would be to not lose it': T381.1-2. 670 Next Hytera submitted that the skilled person would have known from the CGK that the transmission at risk of being lost was a transmission that was still synchronised with the base station 'within some error margin'. This proposition seems to me to be more controversial. The concept of a subscriber unit which was still in synchronisation 'within some error margin' was not part of the CGK. As I have explained in the construction section, the concept of a transmission from a subscriber unit being in synchronisation under the 2005 DMR Standard itself included 2.5 msec of leeway around the precise time at which the 5 msec synchronisation pattern was expected. However, there is nothing in the 2005 DMR Standard to suggest that a further, or second, window might be used to capture those transmissions which were received outside the 2.5 msec of leeway. 671 One problem which arises in assessing the question posed by Hytera's submission derives from the tactical positions of the parties. On its construction argument, Hytera sought to argue that TWINDOW had to be less than 7.5 msec, a proposition which I have rejected. It also treated TEXPECTED as if it were the precise 5 msec interval during which the synchronisation pattern was expected to arrive, a proposition I have also rejected. It argued that TWINDOW had to be no more than the size of the synchronisation pattern plus the guard time. I concluded that in fact an allowance for the guard time was included in the 2005 DMR Standard so that transmissions would be treated as in synchronisation if they were received up to 2.5 msec early or late. I did so in light of the evidence of Professor Wicker and the explicit submission Hytera made about the need for allowance to be made for 'drift' or 'jitter'. I accepted that drift or jitter was a necessary input into the 2005 DMR Standard but that the place where it was inputted was at the level of synchronisation itself. 672 In the course of meeting those submissions, Motorola did not submit (as it could have) that TEXPECTED was itself a timing window of 7.5 msec duration which accommodated the arrival of bursts from subscriber units which were up to 2.5 msec outside of their expected arrival times. Had it done so, however, it would have demonstrated that the invention lacked an inventive step since the timing window was already in the 2005 DMR Standard. 673 Consequently, both parties arrived at the question of whether the additional timing window, TWINDOW, provided for by the patent was inventive unencumbered by either party having made an explicit submission as to whether the 2005 DMR Standard provided for a timing window in its ordinary approach to synchronisation. Motorola was silent on the issue and Hytera went no further than to put forward the indulgence for drift or jitter as part of its argument as to why TWINDOW had to be no longer than 7.5 msec in duration. 674 Whilst it may appear obvious to use a timing window when that is exactly what the 2005 DMR Standard requires in relation to synchronisation, this is not what Hytera submitted. Consequently, Motorola has not been afforded an opportunity to meet the proposition that the idea of the timing window was at the heart of the concept of synchronisation under the 2005 DMR Standard. 675 In that circumstance, I do not think that it is appropriate to draw upon the 2005 DMR Standard's use of a timing window within the concept of synchronisation to assess whether the use of a second timing window in the patent was obvious. 676 In the curious procedural vacuum thus created, it is difficult to assess whether the idea of receiving a message which was in synchronisation 'within some error margin' was obvious. However, as I will explain shortly, Mr Kuhrt thought it obvious as at July 2005 to use such a concept and, indeed, used it in the development of his hypothetical design. 677 I accept Hytera's submission that it was obvious not to repeat transmissions which were not in synchronisation (indeed, this was what the 2005 DMR Standard provided for). I also accept its submission that, if it was obvious to use an error margin, it was straightforward to create an algorithm giving effect to that insight. 678 Turning then to the issue of the use of a timer, Hytera submitted that the skilled person would have known from the CGK that the problem of lost transmissions from a subscriber unit was inherently a problem which could persist only for a finite period of time. This was the period of time which it would take the subscriber unit to determine that the base station was no longer transmitting on the downlink. Typically, this period of time was quite short. There was no point checking for slightly out-of-synchronisation transmissions after this period of time had expired because, by then, the subscriber unit would have worked out what was going on and sent the wake-up message. Further, an additional reason for the same conclusion was the fact that even allowing for a margin of error, it was obvious that within a small amount of time that margin would be exceeded. Put another way, if the base station was happy to receive transmissions were which were, say, up to 5 msec late, it was obvious that in a finite period of time, the transmissions would all be arriving outside of that leeway. At that point, there was no reason to consume system resources to check to see whether the transmissions were within the leeway because they never would be. 679 This reasoning suggests two, potentially different, time limits which would have been obvious to a person skilled in the art. One was the time it would take the subscriber unit to work out that the base station had de-keyed. The other was the period of time it would take before the inevitable effects of timing drift exceeded even what the margin of error would permit. 680 Hytera then took these two time limits (perhaps not distinguishing them) and submitted that it was also obvious to a person skilled in the art that algorithms only operated for the period of time for which they were required. I accept this principle was CGK. Combining the two time limits mentioned in the preceding paragraph with the principle mentioned in this one, it followed, according to Hytera, that it was obvious to use a timer to ensure that the checking for slightly out-of-synchronisation transmissions only persisted for a period of time. I will return to assess this proposition in due course. However, for the purposes of that discussion, it is useful now to note that Hytera's proposition that it was obvious to use a timer rests on an idea of what the timer was to be used for, namely, to prevent the base station from engaging in pointless activity. As will be seen, Motorola submits that the purpose of the timer in the patent is quite different, namely, to determine whether the subscriber units whose transmissions are received within the margin of error are from subscriber units which were previously in synchronisation. 681 In what I have just discussed, I do accept Hytera's submission that, at a level of generality, timers were everywhere in two-way digital radio communications. I am not sure, however, that this necessarily advances the debate if the lens through which the question is to be examined revolves around the purpose for which the timer was used. 682 The above discussion therefore leaves three loose ends. These are: (a) whether the idea of receiving and repeating a transmission from a subscriber unit which is outside the time at which it would be regarded as being in synchronisation but nevertheless within a window (i.e. within TWINDOW) was obvious; (b) whether the use of a timer to delimit how long the base station kept looking for such transmissions was obvious; and (c) whether the purpose for which the timer was being used bears on the obviousness question (i.e. whether the purpose of the timer was preventing the unnecessary use of system resources or instead was a criterion of identification for subscriber units which were previously in synchronisation). 683 With these loose ends in mind, it is useful then to turn to Mr Kuhrt's evidence about his hypothetical design. Hytera submits that this evidence establishes that something like TWINDOW was obvious, as was the idea of using a timer to delimit the temporary de-keyed state. Mr Kuhrt's Hypothetical Design 684 MinterEllison asked Mr Kuhrt what method (if any) he would propose if, at 28 July 2005, he was asked to develop a repeater for a digital conventional two-way radio system that reduced the risk of a transmission from a mobile station being lost when a repeater de-keys. 685 He came up with a method which he says he formulated only taking into account information that he was aware of and regarded to be well-known and generally accepted in the field of two-way radio communications in Australia prior to 28 July 2005. 686 As outlined above, prior to 28 July 2005, there were two multiple access methods that were implemented in digital two-way radio systems: TDMA and FDMA. It was an issue for both methods that communications could be lost when a repeater de-keyed. The design that Mr Kuhrt proposed was suitable for use in both TDMA and FDMA systems. 687 For the purposes of his method, Mr Kuhrt assumed that a repeater would de-key upon the expiration of a hangtimer (which would be activated when there was a break between active transmissions) and that it would re-key upon the receipt of a wake-up message. 688 He proposed two algorithms to be implemented in the software in the base station. (He also thought that another way the problem could be addressed was by the subscriber unit emitting an error tone when the base station de-keyed and sending the wake-up message when the user pressed the PTT button, but it is not necessary to address this solution here). The first would re-key a de-keyed base station when it received the wake-up message. The second would re-key a de-keyed base station when it received a 'valid transmission'. 689 The first algorithm was very simple and no controversy attends it. After the base station de-keyed, if it received a wake-up message from a subscriber unit, it would re-key. The wake-up message would be asynchronous. This meant that it could be received by the base station even if the subscriber unit was not in synchronisation with the base station. Mr Kuhrt gave evidence which I accept that this method was already present in the 2005 DMR Standard. 690 The second algorithm took advantage of the fact that the base station was still receiving transmissions on the uplink after it had de-keyed even if it was no longer transmitting on the downlink. The algorithm would repeat a transmission it received after the expiration of the hangtimer if the transmission was a 'valid transmission'. A transmission would be a valid transmission if it was: (a) received in synchronisation with the base station; (b) free from errors; and (c) from a subscriber unit which had previously been transmitting to the base station. 691 Although there was slight flurry about (b), during the course of the trial it went nowhere and can be disregarded for present purposes. The third condition (c) involves an implicit identification of a subscriber unit. This should be noted as it is relevant to Motorola's submission that Mr Kuhrt's solution involves steps which are not included in the patent (where, no doubt, it will be recalled that the method does not use the kind of identification information implied by (c)). 692 The algorithm included a small margin of error for the expected timing of a received transmission. If a comparison between the actual timing and the expected timing of a received synchronisation pattern was very close but did not exactly match, the transmission would meet the requirements of being a valid transmission and would be repeated. It may be noted that this concept corresponds with TWINDOW in the 960 Patent. 693 According to his first affidavit, Mr Kuhrt would have put a time limit on how long the second algorithm could receive transmissions. This was because it was expected that after a certain amount of time, it would not be expected that the subscriber unit would still be in synchronisation with the base station. He did not specify the amount of time that would be appropriate but he instanced an example of a few seconds. He thought that this time limit was appropriate because the cessation of the second algorithm would relieve the base station of the need to expend a small amount of processing power on running it. The inclusion of a timer in this way in Mr Kuhrt's second algorithm should also be noted at this point. In its submissions, Motorola suggested that the cross-examination of Mr Kuhrt had revealed that Mr Kuhrt had been nudged in the direction of a timer by MinterEllison (I return to this below). 694 Mr Kuhrt would have implemented both algorithms in parallel. This meant that once the base station de-keyed it would be re-keyed by the receipt of a wake-up message or, within an arbitrary period of time delimited by the timer, by the receipt of a transmission from a subscriber unit which was in synchronisation with the base station subject to the small margin of error for which Mr Kuhrt would have allowed. He thought that the software to bring about this result would be straightforward from a programming perspective. Motorola's Submissions about Mr Kuhrt's Hypothetical Design 695 Motorola made three overarching points: (a) the question which Mr Kuhrt had been asked pointed him towards the solution and his design was therefore not evidence of obviousness; (b) Mr Kuhrt had not come up with the idea of using a timer for his second algorithm but had in fact been nudged in that direction by MinterEllison; and (c) Mr Kuhrt's design did not use synchronisation and a timer to determine whether the transmission was from a previously associated subscriber unit, but rather used identification information to achieve that outcome. The Appropriateness of the Question Mr Kuhrt was Asked 696 Motorola put forward a number of propositions in respect of the task which Mr Kuhrt had been set. First, the problem had been known in the FDMA context since the 1990s when the P25 Standard was implemented. 697 Secondly, it was a significant problem in FDMA because the subscriber unit would not be aware that the base station had de-keyed until it had completed its entire transmission. In FDMA it was only when the entire transmission was completed that the subscriber unit could begin to receive transmissions again and it was only at this point that it would be able to determine that the base station was no longer transmitting. This was a significant problem in the context of FDMA. 698 Thirdly, as at July 2005, the 2005 DMR Standard was very new. Mr Kuhrt was not himself aware of it at the priority date (since he was not working in TDMA at that time). Consequently, he was not aware as at July 2005 of the manner in which de-keying and re-keying occurred under the 2005 DMR Standard. 699 Fourthly, although Mr Kuhrt had treated the problem as being the same in FDMA and TDMA systems, it was not. In TDMA the problem was, as I have already accepted, minor where, as I have found, minor connotes the significance of the problem from the perspective of the user rather than the scale of the problem from a technical perspective. 700 Fifthly, Mr Kuhrt accepted that there would have been no technical motivation to address the problem in a TDMA context as at July 2005. This is because it would have been simple for the subscriber unit to inform the user that the base station was no longer transmitting. This could be done by emitting a tone which would then prompt the user to re-press the PTT button which would cause the subscriber unit to send the wake-up message. Motorola therefore contended that there was no commonly known problem of lost transmissions upon a base station de-keying in a TDMA context as at July 2005. There was with FDMA, but in the case of TDMA the problem was minor. To the extent that there was such a risk it would have been considered low and readily soluble by programming the subscriber unit to emit a tone to prompt the user to press the PTT button and thereby send the wake-up message. 701 Upon this contention, Motorola then submitted that Mr Kuhrt's hypothetical design task did not actually reflect what Mr Kuhrt would have done as at the priority date. As I understood it, the implication is that Mr Kuhrt would not have come up with his first and second algorithms but would instead have programmed the subscriber unit to emit a tone when it was no longer receiving transmissions from the base station on the downlink. This was not said to be a deficiency on Mr Kuhrt's part, but was instead evidence that the question that he had been asked by MinterEllison had been skewed to point Mr Kuhrt in the direction of looking at the problem through the lens of a base station. Motorola emphasised that the task that Mr Kuhrt had been set was 'to develop a repeater for a digital conventional two-way radio system that reduced the risk of a transmission from a mobile station being lost when a repeater de-keys'. Consistently with that submission, Mr Kuhrt agreed that the problem that MinterEllison had set for him to solve was not a problem the solution for which he would ever have embarked upon. 702 Motorola therefore submitted that MinterEllison's question pointed Mr Kuhrt in a non-obvious direction. 703 Hytera's response to this was that the question that Mr Kuhrt had been asked did not prompt him to come up with any methodology. He had been asked 'what method (if any) would [he] propose … '. I accept this submission but it passes wide of Motorola's submission. Motorola's point was that the question which he had been asked, asked him to consider what method, if any, he would propose if he had been asked to develop 'a repeater for a digital conventional two-way radio system that reduced the risk of a transmission from a mobile station being lost when a repeater de-keys' (emphasis added). 704 In that circumstance, I see no reason not to accept Motorola's submission that the question Mr Kuhrt had been asked had pointed him in the direction of a solution which was concentrated upon the base station. As the cross-examination of Mr Kuhrt showed, however, if he had been asked to solve the problem of lost transmissions resulting from the de-keying of a base station, he would not have adopted this approach and would have opted for a solution which was based in the subscriber unit. The question MinterEllison asked him therefore unquestionably led him to approach the question in a way which he would not have but for that question. Whether that means that all of his evidence is to be discounted is a different question. I return to this at [720] below. Was Mr Kuhrt Prompted To the Use of a Timer for His Second Algorithm by MinterEllison? 705 I have mentioned above that in his first affidavit Mr Kuhrt said that he would have used a timer so that the second algorithm would only run for a period of time after the expiry of which it could be assumed that the transmission being received would no longer be a 'valid transmission' as it would not meet the conditions stipulated by Mr Kuhrt. 706 The cross-examination of Mr Kuhrt revealed that his initial version of his second algorithm had included no reference to such a timer. 707 He was then subsequently referred by MinterEllison to what he had said at §§133-134 of what was then presumably a draft of his first affidavit. Those paragraphs (in the final version of the affidavit) are as follows: 133. In digital two-way radio systems, terminals communicating in repeater mode may temporarily maintain data synchronisation (or reference timing) during short periods of interference. This is typically a short period of time, as the reference timing being maintained by the terminal will begin to drift apart from the timing which was being provided by repeater before the interference occurred. The period of time that a terminal is able to maintain frame synchronisation when it is no longer receiving data from the repeater's downlink is dependent on a range of factors (including the quality of the terminal's hardware, such as the crystal). For example, the period of time that a terminal is able to maintain adequate frame synchronisation may be less than one second. When the period of interference ends and the terminal again receives data (and thus receives the repeating synchronisation pattern) from the repeater's downlink, it will adjust its timing, if required, to ensure that synchronisation with the repeater remains in place. 134. The eventual drift between a terminal's reference timing and the repeater's timing means that after a period of time without receiving transmissions from a repeater, the terminal may then need to resynchronise with the repeater to once again receive and transmit data. 708 These do not refer to a timer but they do refer to the fact that after a certain period of time synchronisation is no longer present. 709 Mr Kuhrt had said that MinterEllison had referred him to what he had said about reference timing in Kurht-1 at §§133-134. He set out that this had occurred in Kuhrt-1 at §246 and then at §247 explained the timer that he would have used: 246. MinterEllison referred me to my description of the ability of mobile stations to maintain reference timing at paragraphs 133 and 134 and asked if this would impact upon the design. 247. As I described at paragraphs 133 and 134, the drift that can occur between a mobile station's reference timing and a repeater's timing may result in a transmission being out of synchronisation after a period of time. After this period of time, there is no purpose running the Second Algorithm because it is expected that the conditional requirements will not be satisfied. As a result, after an arbitrary length of time (one that exceeds the time it will take for the mobile station's reference timing to be out of synchronisation with the repeater's timing) I would stop the Second Algorithm. This arbitrary length of time may be relatively short (for example, a few seconds). At the end of the timer, the Firsts Algorithm will continue to run (so a wake-up message would still be able to re-key the repeater). This may save a small amount of processing power (energy) for the repeater, because the repeater will not be required to use the processing power associated with running the Second Algorithm once the timer expires. 710 However, the cross-examination of Mr Kuhrt revealed that MinterEllison had not referred him to his description of the ability of mobile stations to maintain reference timing but rather had asked him 'about reference timing': T402.35-36. 711 On the face of it, this leads to a situation where in Mr Kuhrt's first iteration of his second algorithm he had not mentioned using a timer and only included the reference to the timer after MinterEllison had asked him 'about reference timing'. Mr Kuhrt nevertheless claimed that in his initial conception of the second algorithm he had considered the use of a timer but did not think it was going to be a big issue and so did not include it. He did accept that prior to MinterEllison's intervention he 'probably had not considered all of the things that might bring [the] timer to an end' and that MinterEllison had enabled him to make 'a more fast decision about what the timer was going to be': T407.45-46 and T408.9. 712 I accept Mr Kuhrt's evidence that he would have had in his mind the fact that the second algorithm would not run forever and that at some point it would need to be brought to an end. From an engineering perspective, perpetually running algorithms is not optimal. 713 In light of that conclusion, it is immaterial that I do not accept Hytera's submission that in a passage in his affidavit which antedated the addition of §§246-247 it could be seen that Mr Kuhrt had already conceived that a timer would be involved. The relevant passage is in Kuhrt-1 at §238: If the transmission is valid, the design will enable a repeater to will re-key and repeat the transmission. This is possible because the repeater, having only just de-keyed, is expecting the frame synchronisation pattern at a certain time, being a time that is consistent with the frame synchronisation that was in place before the repeater de-keyed. (emphasis added) 714 Hytera submitted that the underlined words showed that Mr Kuhrt had already conceived of a timer. I do not agree. Whilst I accept that it is most likely that Mr Kuhrt did in fact have such a timer in his mind in some inchoate way when he produced the earlier version of his first affidavit, this conclusion does not matter. 715 Having accepted that Mr Kuhrt did in fact have in his mind the fact that a timer would be used, I do not think that it was part of Mr Kuhrt's solution that the timer would be used as part of the process of determining whether the transmission was from a subscriber unit which was previously in synchronisation with the base station. Rather, the purpose of the timer was to ensure that system resources were not wasted on checking transmissions which could not possibly fall within the small margin of error allowed in Mr Kuhrt's method. 716 It is now useful to mention how Mr Kuhrt's method did determine that the transmission was from a subscriber unit which had been previously in synchronisation with the base station. Does Mr Kuhrt's Methodology Use Synchronisation and a Timer To Identify Previously Associated Subscriber Units or Does It Use Identification Information? 717 Mr Kuhrt's second algorithm is not satisfied merely because the subscriber unit is in synchronisation (within a small margin of error). As he accepted under cross-examination, two further requirements must be met: (a) the transmission must be error free; and (b) it must be from a subscriber unit which was previously transmitting to the base station. In this regard, it differs from the patent. In the patent, upon confirming 'proper synchronisation', the transmission is repeated. Claim 8 of the patent proceeds on the basis that if proper synchronisation is present then the transmission is from a subscriber unit which was previously transmitting. It does not perform the further task of doing an identification check on the subscriber unit. Mr Kuhrt accepted that this was a difference between the method in the patent and his method. Professor Wicker's Evidence 718 In the JER, Professor Wicker referred to alternative approaches that he would have considered in addressing the problem of lost transmissions. He would have included in his solution the sending by the base station of a control message to the subscriber units indicating that it was de-keying. Upon receipt of this control message, if the subscriber unit wished to transmit, it would send the wake-up message. This solution would not have been compliant with the 2005 DMR Standard and I think it is unlikely that it would have been used by a person working in the field. I think it notable however, that Professor Wicker thought it obvious to use a solution which centred on the operation of a base station. It is notable because it detracts from Motorola's submission that Mr Kuhrt had been nudged in the direction of using a base station to achieve the solution. It detracts from that submission not because it shows that Mr Kuhrt was not nudged in that direction. Rather, it shows that the nudging is irrelevant because using a base station to solve the problem was obvious. This is consistent with the fact that Motorola does not submit that any inventiveness in the patent lies in its selection of a base station. Assessment 719 Both Professor Wicker and Mr Kuhrt would have adopted a solution that involved a base station. 720 Motorola says Mr Kuhrt's design is to be discounted because he was pushed in the direction of a solution which used a base station. However, it is not said that the inventive aspect of the invention includes the fact that it involved the use of a base station to solve the problem. The fact that Professor Wicker's solution also used a base station shows that that contention could not have been correct if it had been advanced. 721 It is true that Mr Kuhrt accepted that had he been asked to solve the problem of lost transmissions in a TDMA system caused when a base station de-keys, he would have used a tone to alert the user to the fact that the base station had de-keyed. But I do not think this degrades Mr Kuhrt's evidence that it was obvious to use an algorithm in the base station to capture transmissions which were not received precisely in synchronisation. Although he was pointed in the direction of a base station solution, the question at hand is whether the patent which concerns a method in a base station is inventive. As I have said, it was not submitted that the idea of using a solution in a base station was itself part of what was inventive about the patent. Consequently, I do not accept that the fact that Mr Kuhrt was asked to formulate a method for a base station which solved the problem detracts from the conclusions which can be drawn about the inventive step from his evidence about that solution. 722 I therefore accept that the idea of using a margin of error (which is equivalent to TWINDOW in the patent) was obvious to Mr Kuhrt. That it was obvious is also borne out by the evidence of Professor Wicker who accepted that to the state the problem of lost transmissions was to state the solution: not to lose them. There is only one way that transmissions which are not in synchronisation with a base station may not be lost. That is for the base station to receive and process transmissions which are not in synchronisation. This inevitably leads to the timing window or, as Mr Kuhrt referred to it, a 'margin of error'. No other possibility exists. Mr Kuhrt thought that the idea of using the margin of error was obvious. I accept that evidence. 723 I also accept, for the reasons I have given, Mr Kuhrt's evidence that it was obvious to use a timer to delimit how long the process of receiving out-of-synchronisation transmissions was to persist. Indeed, Mr Kuhrt's evidence went somewhat further. The use of the timer was not just obvious. It was inevitable. 724 Motorola's response to this was to submit that Mr Kuhrt's method differed from the method of the patent because the use of the window and the timer in the patent was the method by which the base station determined that the transmission was from a subscriber unit with which it had previously been communicating. By contrast, Mr Kuhrt's solution determined this matter by means of identification information. 725 As I have said, I accept that Mr Kuhrt's identification step is not within the claims of the patent but I do not think that this matters. This is because, contrary to Motorola's submission, the patent does not use the timing window with the timer to identify that the transmission is from a subscriber unit with which it was formerly communicating. Rather, the patent assumes that a transmission which is received within the window before the timer has expired is from a subscriber unit with which it was previously communicating. That it is but an assumption is borne out by the fact that if a value for TWINDOW is selected which is sufficiently large, it is possible that transmissions from subscriber units which were not previously in communication with the base station will be treated as if they were. 726 Motorola relied on this passage of the patent at p 8 lines 24-31: For example, a transmission 310 that is received too early is not processed and a transmission 312 that is received too late is not processed where early and late means that the transmission is received outside the window 308 TWINDOW. The assumption is that the MS was not in synchronization with the BS before the BS de-keyed, so the BS does not need to process the transmission because the MS was not properly associated with the MS so the MS [sic: BS so the BS] does not need to re-key to process a transmission from an MS that is not properly associated with the BS. 727 In terms, this does not say that the timer is being used for identification purposes. Rather, it is an assumption which is made. The assumption is that transmissions received outside the window are not from subscriber units with which the base station was previously communicating. But the patent does not say that the assumption is correct. And, indeed, since it is left up to the person implementing the patent to choose the size of TWINDOW the correctness or otherwise of the assumption will be a function of the choices made by that person. Unlike Mr Kuhrt's method, the patent does not result in a determination that the subscriber unit was one which was previously communicating with the base station; the method merely assumes it. 728 Thus I do not accept that this passage assists Motorola. In any event, there are several passages in the patent which are quite inconsistent with Motorola's submission. For example, at p 9 lines 12-20 a discussion occurs where the timer is set to the length of time that it takes the subscriber unit to determine that the base station has de-keyed: In one embodiment, the temporary de-keyed state timer is set to be 720 msec because 720 msec is the length of time that it takes a MS to determine that the BS has de-keyed. As is known in the art, not receiving synchronization for a period of time but continuing to process received signals as if the synchronization had been received throughout that period of time (also known as the "flywheeling time") is termed "flywheeling" and the time that either the MS or the BS can "flywheel" is set to a predefined length of time. In one embodiment (and as mentioned above) the "flywheeling" time is 720 msec and the temporary de-keyed state timer reflects the longest "flywheeling" time of any MS in the system 100. 729 The concept of flywheeling is entirely inconsistent with the timer being used for identification purposes. Indeed, it is much more consistent with Mr Kuhrt's idea of the timer being used to limit the wastage of system resources. 730 More importantly, whilst the timer is mentioned in claim 8, there is nothing in the claims which lends succour to the idea that the timer is being used for identification purposes. 731 Having reached that conclusion, it therefore follows from Mr Kuhrt's evidence, for the reasons I have given, that the use of the timing window and the timer was obvious. I therefore conclude that the invention disclosed in the 960 Patent is invalid since it is obvious. INFRINGEMENT 732 The question of infringement does not arise since the patent is invalid. If I be wrong in that conclusion I have, however, accepted the correctness of Motorola's construction. In relation to the 960 Patent, Updated Annexure C classified Hytera's allegedly infringing repeater devices as Category 4, and the allegedly infringing mobile station devices as Category 5. The former includes devices RD622, RD962, RD982, and RD982S. The latter includes devices MD652/652G, MD782/782G, PD372, PD412, PD462, PD502, PD562, PD602/602G, PD662/662G, PD682/682G, PD702/702G (UL913), PD702/702G, PD712 EX, PD782/782G (UL913), PD782/782G, PD792 EX, PD982/982G, X1e, X1p, X1p (UL913), MD612, MD622, PD482/482G, PD502(UL913), PD562(UL913), PD602(UL913), PD662(UL913), PD682(UL913), PD712IS, PD792IS, PDC760, and PDC680. 733 Hytera accepted that if Motorola's construction were correct, then the supply of the unreprogrammed base stations infringed claims 1-5, 8-15 and 17-18 of the patent. On the other hand, Motorola accepted that the supply of the reprogrammed base stations did not infringe the claims of the patent. The dispute between the parties therefore concerned whether the subscriber units infringed the relevant claims. There is no distinction between the unreprogrammed and reprogrammed subscriber units in this regard. Subscriber units do not use the method of the patent whether they have been reprogrammed or not. 734 Since the subscriber units do not use the method of the patent in any way, the liability which Motorola seeks to establish is indirect. It says that by supplying subscriber units for use with unreprogrammed base stations, Hytera is indirectly liable for the infringement which then occurs when the base stations use the method of the patent. 735 For the reasons I have given in relation to the 355 Patent, I accept that: (a) Hytera had reason to believe that the supply of subscriber units to end users who were in possession of an unreprogrammed base station would result in those end users using the subscriber units with that base station within the meaning of s 117(2)(b) until 20 November 2019; (b) Liability is established under s 117(1) up until that date; (c) Liability is also established under the authorisation and joint tortfeasorship principles; and (d) Hytera's ETSI defence does not succeed. 736 As with the 355 Patent, the appropriate injunctive relief is that Hytera should be ordered to take the steps which it has already taken and Motorola, in addition, should have the benefit of a general injunction against infringement. VII INTRODUCTION TO THE COPYRIGHT TRIAL 737 In the first half of 2008, several former employees of Motorola began to work for Hytera to assist it in developing its DMR products. Motorola alleges that by the end of 2007, Hytera's efforts to produce a range of competitive DMR products were in a poor state due to technical deficiencies in the development process. Many of these difficulties are alleged to relate to problems which existed with the computer codes which were intended to operate the devices, although some were of a hardware nature too. Motorola says that its former employees (the 'ex-Motorolans') assisted Hytera by developing parts of Hytera's code by copying the code used by Motorola to operate its DMR devices. On this basis, Motorola now sues Hytera for copyright infringement. 738 The copyright allegations were heard separately from the patent allegations although they formed a single trial. The issues thrown up by the copyright allegations are complex and there is some overlap with the patent trial. For example, Motorola's case on additional damages for patent infringement is related to its case on additional damages for copyright infringement. Further, there are some parts of the evidence relating to the copyright infringements which require an understanding of the technology underpinning the patents and, in particular, TDMA. Thus whilst it is convenient to treat the copyright and patent allegations separately, the division between them is not hermetic. Correspondingly, many witnesses who were called in the patent phase of the trial were called in the copyright phase of the trial a second time. The reason the copyright allegations were tried separately from the patent allegations was because they were raised by way of an amendment to Motorola's pleadings at a time which meant they could not be accommodated within the time which had been allocated for the patent trial. The copyright phase of the trial was conducted virtually during one of the COVID-19 lockdowns. 739 The copyright allegations are not straightforward. It is useful to provide therefore a roadmap of this section of the judgment. 740 In the next chapter, Chapter VIII, I consider Motorola's allegations that Hytera's DMR project was in disarray by the end of 2007. By then Hytera had developed a protean DMR prototype (according to it) which had successfully communicated with another DMR device known to be compliant with the 2005 DMR Standard (a Motorola device). Motorola identified a series of difficulties confronting this prototype from an electronic engineering perspective and indeed disputed that it was even a prototype, a matter which will need to be resolved. Although technical, the purpose of these submissions was to demonstrate that Hytera needed to change its course radically if it was to enter the DMR market with a competitive product range. Largely, I conclude that Motorola is correct and that Hytera's DMR project was in disarray at the end of 2007. 741 In Chapter IX, I then consider the actual events which took place once the ex-Motorolans came across to Hytera. In particular, I trace how they came to be employed by Hytera and what their roles were. I examine the distribution within the Hytera DMR team of Motorola's codes and the extent to which, within that team, it was known that Motorola's codes were being utilised to develop Hytera's own codes. This is relevant to Hytera's knowledge of the infringements. Whilst knowledge is not an element in copyright infringement, Motorola's case turns on secondary infringement – principally by way of importation of Hytera's DMR products into Australia. This kind of secondary infringement does have a knowledge requirement. It is also relevant to Motorola's contention that it is entitled to additional damages on the basis that Hytera's conduct was flagrant. 742 One important decision which was made by the middle of 2007 was a decision to remove from Hytera's DMRs a processor known as the FPGA. It had been part of Hytera's DMR project at the end of 2007 and considerable work had been done by then in preparing the code for it. Hytera alleges that it was ignorant that the ex-Motorolans were copying Motorola's code. It puts forward the thesis that the ex-Motorolans had no expertise with the FPGA processor. It was this lack of experience with the FPGA which had led the ex-Motorolans to decide to remove it and it was this ignorance on their part that they decided to conceal from Hytera. Having decided to remove the FPGA processor for this illicit reason, they then had a need to come up with a replacement for it. The replacement was the use of Motorola's code running on a processor known as the C55. This copying of Motorola's code, Hytera alleges, was also concealed from Hytera for the same reason, that is to say, to hide their own deficiencies. Viewed this way, Hytera was as much a victim of the ex-Motorolans as Motorola itself. This mattered because it showed that the ex-Motorolans had acted in fraud of Hytera. As such, Hytera denied that the ex-Motorolans' knowledge could be attributed to it. 743 My conclusions on this, broadly speaking, are that Hytera's DMR project was indeed in disarray at the end of 2007 and that its allegation that the FPGA processor was removed by the ex-Motorolans to cover their own shortfalls is inconsistent with the evidence. It was removed for reasons relating to cost, size and battery efficiency. 744 In Chapter X, I then outline the relevant principles and attempt to chart the structure of Motorola's infringement allegations. This includes a description of the legal mechanics of Motorola's allegations and the issues which arise in relation to whether a substantial part has been taken. I also give an overview of Motorola's case which relates to 11 separate computer programs and explain the difficulties with its particulars and the problems which exist in identifying how its evidence relates to its case. In this section, for reasons relating to the structure of the expert evidence, it is also necessary to examine the four tranches of discovery which were given by Hytera. Without an understanding of these four tranches, it is not possible to understand the expert evidence. 745 In Chapter XI, I consider whether the copyright in the 11 works was infringed. Although I reject most of Motorola's submissions, it has nevertheless succeeded, perhaps only just, in demonstrating that Hytera infringed the copyright in the six works (this is a very simplified statement – the copying took place in China and the case principally concerns secondary liability for importation of the Hytera devices into Australia). 746 In Chapter XII, I consider whether Hytera is to be held liable for the importation of the copied code which occurred. Principally this devolves to whether the knowledge of the ex-Motorolans is to be attributed to it. Simplifying for present purposes, I conclude that it is. In Chapter XIII, I consider Hytera's liability for making firmware updates available in Australia and in Chapter XIV, I consider the liability of Hytera Australia. In Chapter XV, I consider whether Motorola should be granted injunctive relief for copyright infringement and in Chapter XVI I touch briefly on Motorola's entitlement to damages or an account of profits. 747 In Chapter XVII, I assess Motorola's claim for additional damages on the basis that Hytera's infringement of copyright was flagrant. I conclude that additional damages are appropriate. In Chapter XVIII, I examine Motorola's claim for additional damages for patent infringement. I conclude that additional damages are not warranted for the infringement of the 355 Patent since Hytera was ignorant of the patent at the relevant time. I also do not find that the code used to implement the scan function was copied from Motorola's code. 748 The remaining chapters then deal with adjectival matters. Chapter XIX deals with the parties' submissions about appropriate confidentiality orders, and Chapter XX deals with various housekeeping matters. VIII THE STATE OF HYTERA'S TECHNOLOGY INTRODUCTION 749 In this Chapter, I discuss the state of Hytera's DMR development as at the end of 2007. At around the end of 2007 and the beginning of 2008, a series of events occurred within Hytera in relation to the development of its DMR program. These events are intertwined. The first was that in September 2007, Hytera's development of a DMR device had proceeded as far the creation of a prototype. This prototype, which consisted of a number of boards with processors and other components on them was connected to an aerial, a PC and a microphone. It was created by Hytera's DMR team which was headed by Professor Sun. 750 The design task which had been given to Professor Sun was to create a DMR device which complied with the 2005 DMR Standard. As anyone who has got this far in these reasons will appreciate, this task was a complex one. Hytera had previously manufactured analogue two-way radios but the technology involved in those devices was far more straightforward. It will be appreciated from the patent section of these reasons that the DMR standards cast upon Professor Sun and his team the necessity of creating a system which could observe the two timeslot architecture of a TDMA system. This included the concepts of timing, synchronisation, control messages, activity indicator bits and a host of other matters dealt with in the 2005 DMR Standard. As has been seen, a great deal of what the 2005 DMR Standard required turned on computer technology of a complex kind. It was therefore Professor Sun and his team's task to produce something which could comply with, and give effect to, the byzantine requirements of the 2005 DMR Standard. 751 The prototype which was produced in September 2007 was probably not the first prototype made by Professor Sun's team. The testing of different parts of a system to give effect to the 2005 DMR Standard had many theatres of operation and the design process was not aimed initially at producing a single device. Such an approach would have been impossible. Rather, concepts were likely tested by means of different prototypes. A lesser concept than a prototype was the proof of concept or 'POC'. In any event, it is clear that there was much development along these lines in the lead up to 2007. 752 The significance of the September 2007 prototype was that, for the first time, a device was produced which successfully communicated data and voice with another device which was certainly known to be compliant with the 2005 DMR Standard. This other device was a Motorola DMR. The extent to which the prototype was developed is disputed between the parties but it is clear enough from the successful testing that this device must at least have been able to observe the two timeslot architecture of the 2005 DMR Standard and to send and receive payload in 30 msec bursts. 753 The second event, or series of events, is connected to the first. It involved a sober assessment by Professor Sun and his team of what they had actually achieved and where they were going. By this time, Motorola had entered the market (it had done so in the first quarter of 2007). Hytera therefore knew what its competition looked like. In particular, it knew how much the Motorola devices cost and how long their batteries lasted. In a series of presentations to Mr Chen, the President of Hytera, Professor Sun and his team outlined their concerns that the commercialisation of their prototype appeared to be heading in a direction which was problematic. The problem identified was that the Hytera device had many more components than the Motorola devices, used more power (and hence had a shorter battery life) and would be more expensive. As will be seen, Professor Sun was so concerned that he recommended setting up a 'Macro Overall Team' which operated across multiple departments including those responsible for the marketing of future DMR products. He also suggested that another team be assigned to re-examine the existing product and technology development. He recommended that this team have authority to 'overturn the existing platform and do it again'. Ultimately what he sought was 'a decision-making result correlated with the product planning'. This pessimistic assessment has proved correct as the facts have fallen out. What Professor Sun feared might be necessary did in fact turn out to be necessary. 754 The third series of events centred on the actions of Mr Chen. In late 2007, Mr Chen met with Mr GS Kok who had been an employee of Motorola working in a senior position on its DMR project. By early 2008, Mr GS Kok was employed by Mr Chen to replace Professor Sun as the head of Hytera's DMR project. Professor Sun was sent to Harbin. Mr GS Kok's initial examination of the Hytera device revealed the same problems which had been identified by Professor Sun and his team. Soon Mr GS Kok was joined by two other engineers who had worked for Motorola. These engineers were Mr Sam Chia and Mr YT Kok. It is useful to refer to these three people as the 'ex-Motorolans'. I deal with this in more detail below in Chapter IX. 755 By the middle of 2008, Mr GS Kok was recommending that Hytera abandon its use of a processor within its prototype known as an FPGA. Eventually a decision to that effect was made. In a way which I will return to in detail in the next Chapter, a large amount of Motorola's source code for its DMR devices came with the ex-Motorolans. Motorola's basal contention is that the ex-Motorolans and the (large number of) Hytera engineers working under them systematically copied this source code to allow the rapid advancement of the Hytera DMR devices. 756 Those matters are not the subject of this Chapter. Instead, this Chapter is devoted to tracing the existence of a motive on Hytera's part to abandon its prototype. Motorola sought to demonstrate that Hytera had such a motive, indeed, an imperative to abandon its prototype. Although they were not always distinct, Motorola's case about this had three strands. These were, first, that the fact that the prototype was going to result in a device which had a shorter battery life and was more expensive than Motorola's device was the result of a management blunder. This blunder was the decision made to treat the problem of creating a system which complied with the 2005 DMR Standard as separate from the problem of creating a saleable DMR device which would be competitive. The way in which Professor Sun and his team went about creating their prototype did not have as an input prior to the end of 2007 the important questions of how much the device would cost or how much power it would consume. A successful implementation of a DMR device in a competitive market meant that it was folly to solve first how to make a device which complied with the 2005 DMR Standard and then only afterwards to turn to the question of how much it would cost and how much power it would use. Commercial imperatives were an essential element of the design process and could not be dealt with sequentially in the fashion which Hytera had. 757 Professor Sun's realisation at the end of 2007 that the prototype would be more expensive and have a shorter battery life than the Motorola devices was the inevitable consequence of this flawed design methodology. As will be seen, I accept this criticism. 758 The second strand was another design criticism. It was that Hytera had not sought to test the elements of its prototypes in simulations of real world conditions. Thus, the prototype suffered from several drawbacks relating to an absence of robustness in the real world. In a sense, this second strand has some relationship with the first strand inasmuch as both reflect a failure to approach the production of the device not just as a series of technical problems to be solved as a matter of computer engineering, but also as a series of problems relating to the manufacture of an actual working DMR. 759 The third strand involved criticisms of the actual state of the prototype. Ultimately, Motorola narrowed its criticisms to four areas. The first was the FPGA processor which the ex-Motorolans recommended should be abandoned. Motorola submitted that the FPGA was beset with problems which had yet to be solved by Hytera and which would take a considerable amount of time to solve. The second was the state of the prototype's RF unit which Motorola criticised on a several bases. The third was the state of the prototype's 'protocol stack'. I postpone an explanation of what the protocol stack was but it will suffice to say that it involved a lot of complex software. Motorola's submission was that Hytera's protocol stack was very far from complete. The fourth was the fact, not disputed, that Hytera had not developed a Man Machine Interface ('MMI') which is the means by which a device communicates with its user either by displaying information (typically on a screen) or receiving information (by the user pressing buttons). 760 This third strand of Motorola's overall case on motive was intended to have as its end point a conclusion that Hytera had a long way to go before Professor Sun's prototype could have been developed into a working DMR. As I later explain, this contention is perhaps not productive of much which is useful if it be concluded, as I will, that the prototype was uncommercial because it cost too much and used too much power. Once that was appreciated within Hytera, it seems to me that the prototype was never going to be further developed because to do so would have been to spend resources on developing a device which would be a commercial failure. Asking how long it would have taken, had Hytera persisted with the prototype, to get it to market is therefore a somewhat arid question if one is satisfied, as I am, that this would never have happened. The third strand perhaps makes more sense as a contention that, in addition to the commercial problem which Hytera had encountered from its underlying methodological error, these technical problems of implementation provided it with increased incentives to abandon the prototype. Motorola also submitted that the technical problems it asserted in its third strand were manifestations of the development error alleged in the second strand, that is to say, the failure to conduct simulations at the outset. 761 The third strand formed the largest part of the disputes between the parties and occupies most this Chapter. As will be seen, I accept that as at the end of 2007, the prototype was at least two years away from being turned into a device which it would then be sensible to consider turning into an actual saleable device (a process which itself would have taken some time). The computer code was in a less than ideal state from a development perspective. An internal Hytera document described it as the 'monolithic spaghetti' code. It is possible, although not certain, that had Hytera persisted with the prototype it might well have given up and started again. Whether that would have happened would have been a function of the understandable determination of Professor Sun's team to make their prototype work and the tolerance of management for the delay that that determination might have entailed. 762 Regardless, the technical state of the prototype as at the end of 2007 guaranteed that there would be a considerable delay before commercialisation could commence, probably no earlier than the end of 2009. By that time, the Motorola products would have been on the market for nearly three years and Hytera would just be beginning the process of commercialisation. 763 It is possible that the likelihood of such a delay may have formed part of Hytera's decision largely to abandon its prototype in 2008. My strong impression, however, is that it was the question of cost and battery consumption that doomed the prototype. Professor Sun and his team could possibly have fixed the problems with the prototype within two years or so. Doing so would have been messy and time consuming but I accept that it was probably technically feasible. What killed the project was the fact that there was no point in allowing Professor Sun's team to perfect their prototype if, as became obvious, it was going to lead to a commercial product which would cost more than the Motorola device and have a shorter battery life. It is that fact which sounded the death knell for the prototype. 764 The balance of this Chapter is structured as follows: Strand Three: How Long Would It Have Taken Hytera To Bring the Prototype To Market? • Motorola's DMR Project and Entry to Market • Hytera's DMR Project and Entry to Market • The Evidence of Professor Sun • The Problems with the Hytera DMR Project • The Available Objective Evidence about the State of the Hytera DMR Project at the end of 2007 • The Important Elements of a DMR Device • Baseband Unit • RF Unit • The Protocol Stack and Application Software • The MMI • Hytera's Prototype • Motorola's Attack on the Technical Adequacy of the Hytera Prototype • Technical Problems with the FPGA? • No Carrier Detect Algorithm • No Implemented AGC • The Significance of the Non-Implementation of AGC and Carrier Detect Algorithm • Reliability of 4FSK Modulation • Other Problems Identified with the FPGA • Conclusions on Technical Problems with the FPGA • Technical Problems with the RF Unit? • Technical Problems with the Development of the Protocol Stack? • Technical Problems with the Development of the MMI and Application Software • How Far Did Hytera Have To Go with Its MMI? • How Far Did Hytera Have To Go with Its Application Software? • Conclusions on how far Hytera had to go to develop its prototype into an actual DMR device Strand Two: The Failure To Carry Out Simulations • Algorithms • Impairment • Professor Rangan's Point • Were Simulations Carried Out? • Did the Physical Layer Change between the Prototype and V1.0? • Conclusion Strand One: The Failure to Consider Cost and Battery Life at the Development Stage Overall Conclusions 765 I turn first to the third strand of Motorola's contentions against the Hytera prototype. STRAND THREE: HOW LONG WOULD IT HAVE TAKEN HYTERA TO BRING THE PROTOTYPE TO MARKET? 766 It is first necessary to locate the prototype in terms of where the market was. This involves a consideration both of Hytera's position and of Motorola's devices. Motorola's DMR Project and Its Entry to the Marketplace 767 Motorola began discussing the use of DMRs in the late 1990s: DPZ-1 at §7. It began work on a DMR project in earnest in 2003 which it regarded as imperative. The software development for this project was entitled the 'Matrix' project. Because much of the dispute in the copyright case turns on Hytera's use and subsequent abandonment of the FPGA processor, it is useful for the reader to know that Motorola's devices used two processors: one called an 'ARM' processor (a kind of reduced instruction set processor) and one called a digital signal processor ('DSP'). The ARM ran the radio firmware and applications and the DSP was responsible for low-level audio processing: DPZ-1 at §10. The Matrix project involved the development of firmware both for a DSP and an ARM. Motorola did not use an FPGA, or to put it another way, the Motorola devices contained two processors not three. This involved reduced costs and also meant that only one relationship between the two processors had to be managed. 768 In April 2005, the 2005 DMR Standard was published. The development of the Matrix software continued until February 2007: DPZ-1 at §8. The Matrix software was intended to run on portable radios, mobile radios and repeaters. Each of these was given a codename, respectively, Neo, Morpheus and Cypher: DPZ-1 at §9. Motorola began selling its devices in the US and Canada in the first quarter of 2007. These devices utilised the initial version of the firmware resulting from the Matrix project which was known as 'Release 1'. It is the copyright in Release 1 which is said to have been infringed. Hytera's DMR Project and Entry to Market 769 There is a dispute between the parties as to where Hytera was up to in terms of its development of DMR products at the end of 2007. According to Hytera, by September 2007 it had developed a prototype DMR that communicated in accordance with the 2005 DMR Standard. All that remained was for this to be commercialised with a planned launch in early 2009: Sun-1 at §4. On the other hand, according to Motorola, this prototype was nowhere near ready for commercialisation. It is therefore necessary to make findings about the state of Hytera's DMR project as at the end of 2007. It is useful to begin with the evidence of Professor Sun who was in charge of the DMR project. The Evidence of Professor Sun 770 Professor Sun gave evidence by means of two affidavits, dated 1 December 2019 and 23 July 2020, and was cross-examined. Professor Sun is a Vice President of Hytera. He is responsible for its Harbin Research and Development Centre. He is qualified in and has a substantial background in radio communications. From 2005 to 2008, Professor Sun led the development for Hytera of a conventional DMR product. According to his evidence, he was asked to transfer the commercialisation project to Mr GS Kok in 2008. It is Professor Sun's understanding that by September 2007, Hytera had developed a prototype two-way radio that communicated in accordance with the 2005 DMR Standard which was ready for commercialisation and that the launch of the products was expected in early 2009. In his second affidavit, he gave more detailed evidence of why he had this understanding. 771 In the second affidavit, he explained that the prototype that his team had developed by September 2007 consisted of a three chip solution. The chips were the FPGA, a DSP and an ARM. Professor Sun referred to the ARM as the MCU but I will refer to it as an ARM in the interests of clarity. It will be recalled that Motorola's devices used only an ARM and a DSP. The prototype consisted of three circuit boards. One housed the FPGA, another board ('the baseband') housed the DSP and the ARM, and the third contained the RF unit. According to Professor Sun, the three processors did not run the software. Instead, the software was run on a computer to which the prototype was connected. It was also connected to a microphone, an antenna and a speaker. 772 Professor Sun said that the work on the baseband and RF unit was complete by September 2007. He also said that he and his team had written and tested 'most of the protocol stack software'. The protocol stack is a complex concept which I explain more fully below. 773 Professor Sun said that the writing and testing of most of the protocol stack had included the composition of software which implemented all of the commonly used functionalities of a DMR radio, such as voice group call, voice individual call and text messaging. 'Other software' was under development and testing. Professor Sun did not say what this other software was. 774 In around mid-2007, Professor Sun and his team purchased a Motorola DMR radio. It will be recalled that these had only just been released in the first quarter of that year. They purchased this device to conduct interoperability tests on the prototype. This they did in September 2007. They were successful in sending voice and data signals between the two devices. Professor Sun said that these tests indicated to him that the 'development of the software necessary to implement all the core elements of the DMR Standard had been successfully completed': Sun-2 at §8. 775 Professor Sun also explained that the development process at Hytera usually involved two phases: a research and development phase, and a commercialisation phase. He thought that his team had completed the research and development phase by completing a functional prototype. There still remained, however, the commercialisation phase during which the prototype would be converted into a device suitable for sale to customers including the selection of radio housing and other physical elements as well as the manner in which the circuitry would be housed within the device. As I understood it, this process would include miniaturisation. 776 As will be seen, Professor Sun's evidence about this exhibits a structural flaw in Hytera's development process. That flaw is the assumption that the process of designing a complex piece of equipment such as a DMR can be divided into two distinct sequential phases, viz, technical solution and commercialisation. In fact, the design choices for the actual devices are beset with interrelated real world problems such as cost, battery power and the number of components in the devices. To solve the technical problems of how to make a standards compliant system divorced from the reality of how the devices were actually to be made in a competitive environment was to invite disaster. I return to this topic later. Problems with the Hytera DMR Project 777 As I have said, Motorola's case against Hytera's DMR project had three strands. The first strand was that the entire design process was flawed because it separated the solution to the technical problem of implementing the 2005 DMR Standard from the real world problem of making a DMR which was competitive on price and battery consumption. The second was that Hytera had failed to carry out sufficient real world simulations in the development process. The third was that the prototype was very unfinished and would require much more time to develop (contrary to the evidence of Professor Sun). 778 The third strand is the most complex. To make good the existence of the suite of problems for which it contended, Motorola called Professor Rangan. Professor Rangan examined the code which Professor Sun's team had assembled and the documents which were available about its development. He concluded that the project was beset with many serious problems which he identified. In response, Hytera called Mr Grimmett to give evidence that the DMR project was essentially finished and was just awaiting commercialisation. Professor Rangan and Mr Grimmett crossed swords on a large number of topics, many of which lie at the outer reaches of the arcane. In the closing submissions of the parties, however, Motorola did not pursue each and every one of Professor Rangan's accusations against the state of Hytera's DMR project but narrowed the focus a little to four nominated clusters of problems. 779 In the interests of clarity, I will examine the debate in the following terms. First, I will explain the objective evidence which is available about what Hytera's DMR project looked like at the end of 2007. This material consists of the development code and development documents. Secondly, I will explain as precisely as possible what Hytera's prototype looked like. Thirdly, I will then deal with Motorola's criticisms of the prototype which may be grouped into four categories: the FPGA processor, the RF unit, the protocol stack, and the MMI (and application software). Fourthly, I will draw some conclusions about Motorola's third strand. The Available Objective Evidence about the State of the Hytera DMR Project at the End of 2007 780 Between 2005 and early 2008, Professor Sun's team created a number of documents recording their work on the development of Hytera's proposed DMR devices. These documents have been collected and were provided to both Mr Grimmett and Professor Rangan. I shall refer to these, as they did, as the 'Development Documents'. At the same time, Professor Sun and his team also produced source code. This source code was also given to Mr Grimmett and Professor Rangan who referred to it as the 'Development Source Code'. Both Mr Grimmett and Professor Rangan based their opinions on what they read in the Development Documents and the Development Source Code. 781 To understand the criticisms which Professor Rangan made, it is necessary to have a grasp of the important elements of a DMR device: The Important Elements of a DMR Device 782 According to Mr Grimmett, the necessary elements of a DMR device are (AG-18 at §55(a)): (a) a baseband unit; (b) an RF unit; (c) a protocol stack and application software; and (d) an MMI. 783 What do these concepts mean? Baseband Unit 784 Neither party really explained what 'baseband' meant. Motorola pointed to Mr Grimmett's explanation at AG-18 at §56 where he said this: Baseband refers to the original frequency range of a transmission signal before it is converted, or modulated, to a different frequency range and therefore can be thought of as the stage of audio processing before it is converted to RF. On the transmit path, the baseband will process audio received from the microphone, and on the receive path, it will process audio received over air prior to presentation to the speaker. 785 I do not understand what this explanation really means. In the first sentence Mr Grimmett says that the baseband is a frequency but in the second he seems to suggest that baseband does something. I assume the second sentence is a reference to a baseband unit and Mr Grimmett has left the word 'unit' out to keep the reader on their toes. I therefore assume that what Mr Grimmett means is that the baseband unit is part of the system which converts audio to a signal and vice versa. RF Unit 786 According to Mr Grimmett, the RF unit principally performs two functions: the transmission and reception of RFs: AG-18 at §68. In a digital context, the operation of an RF unit is, in principle, the same as in an analogue radio but with the added requirement in a TDMA context of being able to turn the transmitter on and off very quickly (because of the alternating 30 msec burst structure inherent in the 2005 DMR Standard). The Protocol Stack and Application Software 787 The concept of a protocol stack is a difficult one. Mr Grimmett explained it this way in AG-18 at §§83-84: The protocol stack is a set of network protocol layers that work together to communicate data between the top layer and the bottom layer. The layered approach lets different protocols be swapped in and out to accommodate different network architectures. The protocol stack is divided into three layers: the physical layer (PL), the data link layer (DLL) and the call control layer (CCL). It can be supplemented with management layer (ML) and application layer (AL). The PL mainly deals with synchronization and modulation/demodulation, the DLL mainly deals with data framing/de-framing and error correction and the CCL mainly controls the connection process and transaction processing. 788 Mr Grimmett did not explain what modulation and demodulation are but I take them to be a reference to the process of converting data into a signal and vice versa. So, conceptually the physical layer can be seen as that part of the operation of the device that handles the physical signalling which is taking place. When receiving a signal, the physical layer takes the radio signal and converts it into data which it then passes to the layer below. Similarly, when transmitting, the physical layer takes data passed to it by the layer below and converts that data into a radio signal. In short, the physical layer is the interface by which data and radio signals are interchanged. 789 The data link layer is the next level down from the physical layer. Whilst the physical layer converts data into signal and vice versa, it performs no handling of the data. At the data link layer, the data is then handled with processes of the kind mentioned by Mr Grimmett (data framing/de-framing) and error correction (as I discuss later, error correction also occurs in the physical layer). Once this bundling (or unbundling) has occurred, the fruits of the process are then handed to the call control layer where the nitty gritty of extracting meaning from the data and the handling of that meaning occurs (with the help perhaps of two deeper layers, the management layer and the application layer). 790 If the layers are thought to sit on top of each other they can be seen to be in a stack. The point of the stack is to allow data to move up and down it. In order for the stack to work properly, the data transmission between each layer and the next must be seamless. For that to occur it is necessary for adjacent layers to have protocols which they both observe about how data will be passed between them. For example, between layers A and B, one protocol might be that packages will be of a certain length. In any event, the protocol stack is the complete collection of these protocols. As may be imagined in a system as complicated as the two timeslot system in the 2005 DMR Standard, the protocols are likely to be complicated. 791 A final point is worth making. At one point in the submissions, Hytera sought to elide the difference between the layers themselves and the protocol stack. They are however distinct. One is a collection of applications within a system arranged hierarchically, the other a collection of protocols governing how data moves between those layers. Whilst I have no doubt that there is a degree of structural correspondence between the protocol stack and the layers it regulates, they are not the same thing. I return to this topic in more detail later. The MMI 792 According to Mr Grimmett, the MMI refers to the elements of the device which interact with the users. He explained it this way in AG-18 at §116: MMI stands for Man Machine Interface and refers to those elements of a product that interact with the user. On a radio subscriber, for inputs this would usually involve the interface to handle user inputs from buttons and dials and for outputs would usually consist of messages displayed on a screen and/or LED indication. Outputs from the speaker in terms of tones/beeps or pre-recorded messages may also be considered part of an MMI. 793 These then are the basic concepts which dictate the architecture of the debate between the parties. The actual debate was conducted over the Development Source Code and to an extent its embodiment in Professor Sun's prototype. It is useful to describe the prototype. Hytera's Prototype 794 By September 2007, Professor Sun said that he had developed a prototype which was able to work with a Motorola device. It is likely, as Mr Grimmett observed, that this prototype was preceded by earlier prototypes and POCs. These may be disregarded in the present context. The focus of both sides was on gauging what state of development this last prototype was in. 795 There was some uncertainty as to what this prototype actually was. According to Professor Sun, the prototype consisted of three circuit boards. One housed the FPGA processor, another board, the baseband, housed the DSP processor and the ARM processor, and the third contained the RF unit. The three processors (FPGA, DSP and ARM) did not run software according to Professor Sun. Instead, the software was run on a PC to which the prototype was connected. The three boards were also connected to a microphone, an antenna and a speaker. 796 On the other hand, Hytera submitted that the prototype was made up of an RF board, a baseband board or boards (which contained the FPGA and a DSP), an AMBE-2 voice board (vocoder) and a PC host (which hosted the MMI simulation software): HCS(C) Mod III at [66]. There is no doubt that Hytera intended to implement its MMI on an ARM processor. However, Hytera's submission suggested that the entirety of the MMI function was performed by code which was running on the PC and that there was no ARM processor in Professor Sun's prototype. 797 Motorola did not chance its arm at an exact description of Professor Sun's prototype. I am unable directly to explain where the AMBE-2 voice board fits into the picture however there is evidence which suggests that it was attached to the microphone and speaker described by Professor Sun. That evidence consists of a diagram contained in a report produced on Hytera's efforts to use the prototype with a Motorola device. The diagram is as follows: 798 It seems likely to me that this contemporaneous account of the prototype is most likely reliable. Overlaying it with Professor Sun's evidence about which processors were on which boards I conclude that the correct position is as illustrated above so that the prototype consisted of: (a) a board housing the RF unit connected to an antenna; (b) a baseband board on which was located an FPGA chip; (c) another baseband board on which were located the DSP and ARM chips; (d) a board containing a vocoder which was connected to a microphone and a speaker; and (e) a PC host computer connected to the second baseband board housing the DSP and ARM processors. 799 Whilst there seems to be no debate that a PC host was being used, there is confusion about the extent of its use. Professor Sun thought that no processing was being conducted on any of the three processors but there was evidence referred to by Hytera which suggested that processing was being carried out on the FPGA processor: HCS(C) Mod III at [66(e)]. I will return to this topic where necessary. Motorola's Attack on the Technical Adequacy of the Hytera Prototype 800 Motorola submitted that the prototype was not anywhere near ready to be deployed as a DMR due to technical problems from which it suffered. This attack is to be distinguished from Motorola's other attacks on the state of Hytera's development of its DMR: (a) a failure to integrate the solving of the technical problems involved in creating a TDMA system which complied with the 2005 DMR Standard with the practical problem of building a DMR device which was commercially viable (Strand 1); and (b) the failure to carry out adequate simulations at the start of the development process (Strand 2). 801 Motorola identified the technical problems as lying in four areas: (a) the FPGA processor; (b) the RF unit; (c) the extent of development of the protocol stack; and (d) the extent of the development of the MMI. 802 It is convenient to deal with these in the above order. Technical Problems with the FPGA? 803 Motorola submitted that Hytera's baseband unit envisaged the use of three processors: the FPGA, the DSP and an ARM. As I have already noted, in the prototype, the FPGA was located on one board whilst the DSP and the ARM were located on another board which was connected both to a PC and a vocoder. The functions of these three processors were: FPGA: the implementation of the physical layer; DSP: the operation of the protocol stack and communication between the protocol stack and the physical layer; and ARM: the operation of the MMI and scheduling of the protocol stack. 804 The three problems identified by Motorola as afflicting the FPGA (and which were known by the end of 2007 to Hytera independently of the involvement of the ex-Motorolans) were: (a) no carrier detect algorithm had been implemented on the FPGA; (b) automatic gain control ('AGC') had not been implemented on the FPGA; and (c) the 4FSK modulation/demodulation which had been implemented on the FPGA had reliability issues. 805 Dealing with each in turn: No Carrier Detect Algorithm 806 Motorola submitted that the FPGA design was incomplete as at the beginning of 2008. It was incomplete because Hytera had not designed or implemented a carrier detect algorithm: MCS(C) Mod II(C) at [14]. There was some uncertainty as to whether carrier detection took the form of an algorithm or a circuit or possibly both: T326.5-14. Given that the FPGA is a processor chip which appears to be programmable, I incline to the idea that it is both. In any event, this does not matter. 807 There was internal documentary evidence which suggested that the prototype did not include carrier detection functionality: JP-3 at p 5051. The purpose of carrier detection functionality is to detect the presence of a carrier wave (or frequency) that is carrying a signal: T326.13-14. Although this document came into existence after the arrival of Mr GS Kok, I did not understand Hytera to dispute its accuracy. In any event, each of Professor Rangan, Mr Grimmett and Mr John Peck agreed that carrier detection was missing: T326.41-327.5. Hytera did not submit that the prototype had implemented a carrier detect algorithm. 808 Hytera's response to the submission that its FPGA lacked a carrier detect algorithm was that this was not a substantial problem and could easily have been overcome. It was not a real problem because algorithms for carrier detection were published in the relevant industry literature as at 2007 and were readily implementable as hardware designs within an FPGA which Hytera had the expertise to do: HCS(C) Mod III at [102]. Mr Peck gave evidence that such algorithms were available in relation to carrier detection. 809 Motorola then submitted that the absence of carrier detection was a longstanding and troublesome aspect of Hytera's DMR development which was reflected in its 'contemporaneous' documents: MCS(C) Mod II(C) at [14]. Only one such document was however nominated by Motorola: a report dated 29 October 2007 titled 'Overview of Hardware Platform Design of DMR System' ('Overview of Hardware'): CB14.212 at p 14. Nothing in this report refers to the absence of carrier detection or to its absence being, as Motorola submitted, a longstanding problem. 810 I therefore conclude that Hytera had not implemented a carrier detect algorithm in the FPGA chip as at the end of 2007. I accept Hytera's submission that it was easy to provide for carrier detection because algorithms were published in the literature and because the carrier detection had already been achieved by Hytera in respect of its analogue devices. I was not taken to any evidence which suggested that carrier detection differed between digital and analogue systems. 811 The implementation of a carrier detect algorithm was not a matter which was required by the 2005 DMR Standard although it assumed that carrier detection was present (it is hard to see how a system could work without carrier detection in a practical sense). As such, I do not think that the creation of a carrier detect algorithm was caught up on the baroque niceties of the timeslot structure of the 2005 DMR Standard. Indeed, it will be remembered from the patent part of the case that carrier detection was something which happened before even the detection of a synchronisation pattern. 812 Therefore whilst it is true that Hytera had not developed a carrier detect algorithm, I do not think that would have delayed the development process. Whilst this was not a minor issue, neither was it a large one. No Implemented AGC 813 AGC is an automatic way of levelling the audio to make sure it is more consistent as people change the quality of their speech and their position in relation to the microphone: HCS(C) Mod III at [98]. AGC takes place both during transmission and reception. How it works on the receiving path was not explained. 814 Motorola submitted that AGC had not been implemented in the FPGA: MCS(C) Mod II(C) at [14]. This appeared not to be disputed by Hytera on the transmitting path although it was disputed on the receiving path: HCS(C) Mod III at [104]. 815 I do not accept Hytera's submission that it had been implemented on the receiving path as at the end of 2007. Hytera relied on CB14.211 at pp 5 and 10 to make good this proposition. The document in question is entitled 'DMR Radio Frequency Test Board: Overall Design Instructions for Circuits' ('DMR Frequency Test Board') and is dated 29 October 2007. The document refers to AD9864 as a medium frequency processing chip. Hytera did not seek to explain the relationship between the AD9864 and the FPGA as to which I remain ignorant. Assuming that the AD9864 processor is separate from the FPGA, I do not read what is at pp 5 and 10 as demonstrating anything about the implementation of AGC on the receiving path. At T369.43-45, Professor Rangan thought that the document showed the AD9864 had some facility to do AGC but that it had not been implemented. Mr Peck thought that it had not been 'completed entirely' (T370.2) and Mr Grimmett was not sure whether it was fully implemented: T370.6. 816 Hytera also submitted that it was clear from pp 9 and 20 of the same document that AGC was implemented on the receiving path. It was also said that what was said by Mr Grimmett at T397.34-398.4 supported this. I reject the submission. Neither of those pages nor Mr Grimmett at that transcript reference appear to say such a thing. 817 In those circumstances, I do not accept that implementation of AGC on the receiving path has been proven. 818 Next Hytera submitted that, as with carrier detection, algorithms for AGC were readily available and that it would have been a straightforward matter for Hytera to implement AGC into its FPGA processor. I do not accept this submission. The Overview of Hardware report referred to above establishes that the implementation of AGC in the prototype had been found to be problematic. Under the heading 'Key Difficulties in Radio Frequency Circuits' this comment on AGC appears: How to realize AGC control in transmitting circuit is not involved in this design. Because after studying the MOTO prototype, it is found that MOTO implements AGC in the IF amplifier part, but it is still unknown how to implement it. This is also a difficult point in the design. 819 I therefore conclude, as Motorola submitted, that the implementation of AGC had been problematic for Hytera and that its solution was not, as Hytera submitted, necessarily straightforward. 1. THE SIGNIFICANCE OF THE NON-IMPLEMENTATION IN THE FPGA OF AGC AND CARRIER DETECT ALGORITHM 820 It was not in dispute that for a device to operate in the real world it needed to have both AGC and carrier detection: MCS(C) Mod II(C) at [14]. I therefore conclude that the prototype could not have operated in the real world. Motorola also submitted that the absence of either of these matters was a manifestation of an underlying design problem. This was the failure of Hytera to perform sufficiently robust simulations of its physical layer algorithms prior to commencing the implementation of their design (i.e. the second strand of Motorola's case). I do not accept this submission. I explain later how Motorola's argument about this works in more detail. However, for present purposes it suffices to say that the criticism concerns the folly involved in implementing in computer code an algorithm in the physical layer before it has been tested in simulated real world conditions which include channel impairments (i.e. interference with a signal). Accepting that, for present purposes, to be a fine and proper aspiration from a development perspective, the argument is silent where the FPGA did not have an AGC or carrier detect algorithm which could suffer from this deficiency. Reliability of 4FSK Modulation 821 Motorola submitted that Hytera's prototype had reliability issues in relation to its 4FSK modulation: MCS(C) Mod II(C) at [15]. Hytera did not appear to dispute this. In any event, the Overview of Hardware report of 29 October 2007 (referred to above) clearly refers to the existence of this problem at p 14 at (1) under the heading 'Key Difficulties in Radio Frequency Circuits': Because 4FSK cannot determine the characteristics of the correctly modulated signal, the correctness of 4FSK two-point modulated signal cannot be judged temporarily. Follow-up discussion is needed to find an answer to this question. 822 I therefore accept Motorola's submission that the prototype FPGA as it stood at October 2007: (a) did not implement a carrier detect algorithm; (b) did not implement AGC; and (c) suffered from reliability issues in relation to 4FSK modulation. 823 I do not think that (a) would have delayed Hytera's DMR project. However, it seems that (b) and (c) had some way to go and had proven to be problematic. Other Problems Identified with the FPGA 824 Motorola also submitted that after the arrival of the ex-Motorolans, further problems with the FPGA were identified. In June 2008, a document entitled 'FPGA Analysis' was prepared by Mr Chia. I will return to this document when tracing the decision which was subsequently made to ditch the FPGA processor. However, for present purposes the document identifies further problems with the FPGA including that: (d) the analog modulator whilst developed had not been tested or debugged; (e) the functionality of the modulator limiter had been completed but its performance had not been tested. The implementation was such that it would result in poor performance and require a redesign; (f) the squelch initial algorithm had been implemented but its performance had not been tested since the RF signal was not stable; (g) the performance of the analog demodulator was expected to be poor; and (h) the receive signal strength indicator had not been realised. 825 This document also noted that some of the earlier problems mentioned above had now been solved. For example, the 4FSK physical layer modulation/demodulation realisation was now said to be 'completed'. 826 Hytera submitted that the ex-Motorolans had been motivated by their lack of expertise in FPGA to move towards a solution that did not involve the FPGA. If that submission be correct then this would provide a reason perhaps to look askance at the conclusions in this document. However, the submission is not correct for reasons I give in Chapter IX. 827 That being so, I do not accept that the problems identified by the ex-Motorolans above are to be downplayed on the basis that they had an animus against the FPGA. On the contrary, their statements are contemporaneous assessments by experts about the state of Hytera's development. Conclusions on Technical Problems with the FPGA 828 Whilst it is clear that by 2008 the problem with 4FSK modulation/demodulation had been solved, that problem existed as at the end of 2007. I therefore conclude that the FPGA had the technical problems identified at (a)-(h) above. The absence of a carrier detect algorithm and AGC in the FPGA meant that the prototype was not ready to be used in a real world environment. Technical Problems with the RF Unit? 829 A distinction may be drawn for present purposes between the RF unit and the antenna. I did not understand Motorola to suggest that there was a problem with the antenna. In relation to the RF unit itself, Motorola submitted that (MCS(C) Mod II(C) at [20]-[21]): (a) it had not been tested for adjacent channel and carrier interference; (b) there were problems with its design; and (c) more work was required to be done on the RF unit to achieve a satisfactory RF circuit. 830 Hytera submitted that (HCS(C) Mod III at [94]): (d) it had conducted further testing on the RF unit after the prototype was tested for interoperability with the Motorola device; (e) Hytera was undertaking an ordinary process of testing and modification and any difficulties would have been resolved within six months; and (f) in any event, the difficulties which were encountered were resolved by late 2007. 831 Proposition (a) is supported by the testimony of Professor Rangan at T392.4-5 and I accept it. Proposition (b) overstates the evidence of Mr Grimmett at T395.20-23. All that Mr Grimmett said was that the result of a particular test presented 'some challenges'. I accept proposition (c) which was said to be supported by the evidence of Mr Grimmett at T401.24-32 and by a document contained in AG-16. I conclude that Mr Grimmett accepted that Hytera's Development Documents showed that more work was required to be done on the RF unit to achieve a satisfactory RF circuit. It is not necessary to refer to the document. 832 For Hytera, proposition (d) was said to be supported by T330.45-46 and the DMR Frequency Test Board document referred to above. The transcript reference does not make good the proposition. No page reference within the document is given. I do not find (d) proven. 833 Proposition (e) was said to be supported by the evidence of Professor Rangan at T370.43-371.1 and by the evidence of Mr Grimmett. The extract of Professor Rangan's evidence is incomplete. A more complete reference would be T370.43-371.9 (noting that the transcript is incorrect and records the cross-examiner as Mr Moore rather than Mr Dimitriadis): MR MOORE: Well, that's just a part of normal testing, Professor Rangan. You test – you make modifications, you test them, you identify problems, you fix them. That's part of normal DMR development, isn't it? PROF RANGAN: Sure, absolutely. But the problem – my general problem is that – is the – every design is going to have problems and errors, even commercial designs get improved and find bugs and fix them. That's not unreasonable. The problem is that that whole process by which Hytera had undergone, that started off without having any systematic simulations to understand what happened in real RF impairments, both within the circuits and over the channel, and then proceeded to develop. And they're going to start seeing problems, and they're going to have very difficult – it's going to be difficult for them to try and track them down and fix them going forward. 834 Read in full, Professor Rangan was not saying that the testing process was usual. So far as the evidence of Mr Grimmett is concerned this was at T402.13-17: MR GRIMMETT: Well, look, I guess I believe that the RF team were continuing to develop from the point this document was written in October through to – you know, pick a date, 2008, March, they would have been continuing to work on the RF. So I would expect a number of these issues to have been resolved in that six-month period. To point to a specific document … to do that. 835 I do not therefore find proposition (e) proven. The difficulties outlined by Professor Rangan meant that the issues which would be thrown up would not be the kind Mr Grimmett suggested would be resolvable within six months. 836 I also do not accept proposition (f). Whilst the RF unit in the prototype had been successfully tested, the gravamen of Professor Rangan's evidence was that it had not been tested against real world impairments. As such, I do not accept that the work on the RF unit was at all likely to be at an end. 837 On the RF unit, my conclusion is that it had not been tested for adjacent channel or carrier interference and that more work was required to be done on the RF unit to achieve a satisfactory RF circuit. I do not accept that the RF unit would have been finished by the end of 2007. This appears overly optimistic. A more likely timeline would find it completed in the middle of 2008. Technical Problems with the Development of the Protocol Stack? 838 There was no dispute that Hytera had developed some code for the protocol stack. Motorola submitted that as at the end of 2007 (MCS(C) Mod II(C) at [23]-[24]): (a) necessary functionality was missing and the protocol stack needed to be further developed; (b) to the extent that voice or group call functionality had been implemented, it was only in a very limited manner and had only been tested in an idealised lab environment; and (c) the code was poorly designed in that it was not sufficiently modular to permit future development. 839 Hytera submitted that (HCS(C) Mod III at [85]-[86]): (d) it had developed 90% of the physical and data link layers of the protocol stack; (e) it had developed the core control layer of the protocol stack to a lesser extent; (f) it had tested the functionality of the protocol stack; (g) it had completed all of the essential elements of the protocol stack prior to the arrival of the ex-Motorolans; and (h) the completeness of the work on the protocol stack was underscored by the fact that after the ex-Motorolans arrived, the source code for the protocol stack remained largely unchanged. 840 In relation to (h), Motorola submitted that (MCS(C) Mod II(C) at [25]): (i) whilst it was true that elements of the pre-2008 protocol stack were present in Hytera's final version, the structure and framework had significantly changed; (j) additional functionality had been added in the form of reverse channel signalling; and (k) additional functionality had been added in the form of support for TDMA timeslots. 841 I accept propositions (a), (d) and (e) which are established by the evidence of Mr Grimmett at T425.45-426.12. Plainly, the core control layer had some way to go. A lot of the code was being run on the PC and there was more development and testing which needed to be done. There was 12 to 18 months of data still to be processed most of which would have been surrounding the application software and further developments in the protocol stack. 842 As to proposition (b), Motorola relied on the evidence of Professor Rangan at T431.17-23. That evidence establishes proposition (b) which, it will be noted, is conditional in nature. Professor Rangan did not accept that voice and group call functionality had been implemented. I agree with Professor Rangan. It is apparent from Professor Sun's description of the interoperability test conducted on the prototype with the Motorola device that the so-called voice and group call functionality was of the most basic kind and did not resemble anything like full voice and group call functionality. I therefore accept (b) and additionally find that voice and group call functionality had not been implemented other than in the most protean and artificial of ways. This was not a device which awaited commercialisation. It was a collection of boards and processors which were able to use the 2005 DMR Standard to make a highly artificial set of communications in laboratory conditions. 843 As to (c), Motorola relied on the evidence of Professor Rangan at T426.43-427.2. It also relied upon Hytera's own description of the code as the 'monolithic, spaghetti system' in one of its documents. I would refer to a slightly longer passage involving the evidence of both Professor Rangan and Mr Grimmett at T426.22-41: MR MOORE: Yes. You will agree that the code that had been developed took the form of a complex interrelated form, rather than a separation into individual components which would enable, for example, the amendment of just the individual aspect, rather than the entire software, if one needed to make a change. MR GRIMMETT: No, I don't agree with that. There certainly is some layering within the software, and it's split into the physical layer, the data link layer and the core control layer, with well defined interfaces between those. So I don't think there is that degree of complex interrelation between those modules. MR MOORE: Professor Rangan. PROF RANGAN: Yes. So I think that we're maybe disagreeing on this part too. I think that, really, the way that they've structural code kind of undermines the whole concept of modularity. So if you look at the software – you can pull it up if you want to – all the – there were layers in the sense that there was one file related to … another file related to link control layer, but they all shared variables by what I call global variables, which means that any part of any file can touch any memory, and that is what was being meant by this monolithic structure instead of defining clear interfaces between them. 844 Professor Rangan's criticism was that the code was not sufficiently modular. Mr Grimmett thought that the code was well structured because it separated the layers. However, I do not think that this quite meets Professor Rangan's point about global variables being shared between different parts of the code. I therefore accept Professor Rangan's point about the absence of modularity. 845 This conclusion is supported by a presentation prepared by Mr YT Kok on 4 July 2008: CB8.11. This presentation was entitled 'HYT Common Platform Architecture'. The first two slides contained the following text: Monolithic, Spaghetti System • Coupling lead to a big fat system that very difficult to isolate the component and reuse. • HW and OS dependent lead to a poor portability when changing processor or RTOS. • We typically get system devolution, not system evolution! Monolithic, Spaghetti SW lead to following typical issues • Increasingly difficult to change, harder to respond to market shifts, and costs more, takes longer • Hard to isolate chunks to reuse, chunks are highly tuned to specific product/environment • Hard to control quality, hard to find defects, hard to solve defects and fixes introduce new problems 846 This in-house criticism of the code provides support for Professor Rangan's views. Hytera submitted that no weight ought to be attached to these observations because they were made by the ex-Motorolans. This was on the basis that the ex-Motorolans had a motive to get rid of the FPGA processor. 847 I have already rejected that proposition. Once that objection is cleared away, this description of the code emanates from the head of Hytera's own DMR project. 848 I therefore accept proposition (c). 849 As to proposition (f), Hytera submitted that the functionality of the protocol stack had been tested through the interoperability testing which took place between the prototype and the Motorola device. I do not accept that proposition. Whilst no doubt some functionality was tested, that testing was so far divorced from real world circumstances that it cannot be accepted as a proper or complete testing of the protocol stack. I therefore reject proposition (f). 850 As to proposition (g), Hytera submitted that Mr Grimmett had conducted a detailed analysis of the Hytera Development Source Code and had found that Hytera had completed all of the essential elements of the protocol stack. I was referred to AG-18 at §§121-153. Hytera submitted that this evidence had not been disputed by Professor Rangan. 851 I accept that in AG-18 Mr Grimmett examined the Development Source Code closely including those parts which related to the protocol stack. Generally, he reached the view that Hytera had completed the basic elements of the protocol stack. At §153 he said this: In my opinion, in order to achieve successful voice and data calls with a Motorola DMR radio, all of the fundamental elements of the DMR protocol stack at all layers must have been implemented within the prototype in accordance with the ETSI DMR specifications. 852 However, as I have found in proposition (b), the implementation of the voice and group call functionality was protean at best. I do not share Mr Grimmett's view that Professor Sun's success in getting the prototype to interact in highly artificial circumstances with the Motorola device proves that the stage had been reached where it could be said that there had been successful voice and data calls by the prototype. 853 It is true, as Hytera submits, that Professor Rangan never produced a reply report to AG-18 in which he said that Mr Grimmett was wrong. However, he had already delivered a report in which he expressed the view that the protocol stack was far from complete. Issue had been joined between Mr Grimmett and Professor Rangan on the state of the protocol stack. When they gave their evidence concurrently it resulted in evidence being adduced which has resulted in me finding as having been proved propositions (a), (b), (c), (d) and (e) and rejecting the idea in (f) that the functionality of the protocol stack had been meaningfully tested. Consequently, I do not accept it is accurate to submit, as Hytera did, that Professor Rangan had accepted Mr Grimmett's view that all the elements of the protocol stack had been prepared. I do not therefore accept proposition (g). 854 As to (h), this is conveniently dealt with at the same time as propositions (i), (j) and (k). At the heart of these is the question of how similar the protocol stack as developed by Professor Sun's team up to the end of 2007 was to the version of the protocol stack which eventually emerged when Hytera's products were launched in 2010 (known as 'V1.0'). 855 Motorola submitted that it was common ground between the parties that the structure and framework of the protocol stack had been significantly changed. Motorola relied on T439.5-27: PROF RANGAN: Yes. So under that assumption – sorry, not – not - putting aside – putting the validity of the assumption aside, we do know actually – we do see elements of the protocol stack code that had some origin from the pre-2008 emerge in the 2010 code, but what we see when we look at them side by side and compare them – if you actually open them up internally, which we can do – we don't have to hypothetically speculate – we see that the insides and the way that they're actually called are radically different. So, for example, you see logging information infrastructure in that code. You see that the way that the messages are passed are now through an operating system. You would have also had to change that if you wanted to use a task scheduler. So the whole framework by which the parts interact changed as you will also see other functionality changed to, like, TDMA timeslots and things. Yes. But even if that had been completed, you can see that this kind of infrastructural changes would necessitate revisiting all that code. MR MOORE: Yes. Thank you. HIS HONOUR: Mr Grimmett? MR MOORE: Yes. MR GRIMMETT: Yes. So I would agree with Professor Rangan that the – the structure and the framework changed fairly significantly, you know, from pre 2008 to the version 1 code … 856 I take from this that Mr Grimmett thought that those parts of the protocol stack which reflected the protocol stack in the 2005 DMR Standard were largely the same. However, it was agreed that the structure and framework of the V1.0 protocol stack had changed fairly significantly. I therefore accept proposition (i). 857 As for proposition (j), this was said to be supported by Mr Grimmett's evidence at T440.18 which I accept. I therefore find proposition (j) proved. 858 In relation proposition (k), I am not so sure. Professor Rangan certainly gave evidence above that support for the TDMA timeslots had been added in V1.0. But there is force in Mr Grimmett's observation that it is difficult to see how Professor Sun's interoperability test could have succeeded if support for the TDMA timeslots was not present: T440.12-13. I am not affirmatively satisfied of this matter and do not find it proved. 859 Having accepted propositions (i) and (j), I therefore do not accept proposition (h). The protocol stack did not remain largely unchanged as between the prototype and V1.0. Whilst those aspects of it which related to the 2005 DMR Standard did, many other aspects did not. 860 In summary I conclude that as at the end of 2007: (a) Hytera had developed 90% of the physical and data link layers of the protocol stack; (b) It had developed the core control layer of the protocol stack to a lesser extent; (c) Necessary functionality was missing and the protocol stack needed to be further developed; (d) Voice and group call functionality had been implemented in only the most protean way. To the extent that it had been implemented this had been done in a very limited manner and tested only in an idealised lab environment; (e) The code was poorly designed in that it was not sufficiently modular to permit future development. It was 'monolithic spaghetti' code; (f) Whilst it was true that elements of the pre-2008 protocol stack were present in Hytera's final V1.0 in 2010 (being principally those relating to the protocol stack in the 2005 DMR Standard), the structure and framework had significantly changed; and (g) Additional functionality in V1.0 had been added in the form of reverse channel signalling. 861 In relation to (a), whilst I accept that Hytera had developed 90% of the physical layer for the protocol stack, this is a description of how far Hytera's development of that layer had got to from its perspective and does not involve any assessment of how adequate the work which it had done was. As I explain below when dealing with the second strand of Motorola's case against the prototype, Hytera had not adequately tested two of the algorithms in the physical layer by means of simulations which accounted for impairments which occur in real world environments. This failure guaranteed that difficulties lay ahead for Hytera's physical layer and would almost certainly require future revision. It is likely that these future difficulties would have had implications for the way in which the protocol stack dealt with the physical layer. Technical Problems with the Development of the MMI and Application Software 862 As already noted, the MMI is the interface between the device and the user and determines the way the two interact with each other. It handles both inputs and outputs. The inputs consist of matters such as button presses and the output of matters such as the display of data on a screen and the sounding of tones through a speaker. Mr Grimmett thought that typically the MMI was put together once the underlying layers were complete. I accept that this may well be so but I would not conclude that circumstances may not make it appropriate to commence work on the MMI in parallel with the development of the rest of the device. As I later discuss, there is a project management risk in entirely separating out from each other the questions of technical implementation (such as the development of a system which complies with the onerous requirements of the 2005 DMR Standard) and commercial issues such as cost and battery life. It may be that the MMI falls into a similar category. I am not able to say definitively that it does. However, whilst I do in principle accept Mr Grimmett's point, I do so with a degree of caution about how far its practical implications should be taken. 863 In relation to the application software, there was no real explanation by either Mr Grimmett or Professor Rangan of what the application layer was. No doubt this was because they did not disagree about the extent to which Hytera's application layer had been developed. I will proceed on an assumption that the application layer (and the software constituting it) includes applications which are used by the user and contains protocols by which they communicate (this, however, is only an assumption). How Far Did Hytera Have To Go with Its MMI? 864 Both Professor Rangan and Mr Grimmett agreed that by 2008 Hytera had not progressed very far at all in its design or implementation of an MMI. The PC, which was attached to the prototype which had successfully interoperated with a Motorola device in the limited fashion I have previously described, had some features of an MMI emulated upon it, for example, a talk button. But this was written in code for the PC and was not part of the prototype itself. It was Hytera's intention that when it created an MMI it would be implemented on the ARM processor. 865 It was also not in dispute that Hytera had not developed an operating system to underpin the MMI. Professor Rangan thought that it was essential to have an operating system underpinning the MMI: T422.41-423.8. The problem which an operating system deals with is the management of simultaneous tasks across the processor. As I understood this evidence, what this meant was that a processor can be tasked with performing multiple tasks at once. It does this by doing a little bit of work on one task and then a little bit of work on another task and so on. There must be a framework which controls the way in which the processor moves from task to task (or from application to application). This involves stopping one task, storing results so that they can be returned to, and then sending the processor off on the next task. Overlaid on top of that problem is the fact, referred to by both Professor Rangan and Mr Grimmett, that interrupts must be handled. As I understood it, an interrupt was a signal received by a processor which required its attention more or less immediately. Some of these might occur at regular intervals, others might occur unexpectedly. In any event, the point of the operating system was to permit all of these activities to be controlled in an orderly fashion. Another important aspect of an operating system was that it permitted flexibility. 866 The evidence of Mr Peck suggested that an operating system was not essential. Mr Peck is a computer engineer called by Hytera to give evidence about the stage of development of Hytera's code from the perspective of the FPGA. He instanced examples of computers which did not have operating systems such as arcade computer games from the 1980s. To that might be added the example of an old fashioned desk calculator. Professor Rangan's observations on the problem were as follows: PROF RANGAN: What I was saying was that the role of the operating system is to be able to manage simultaneous tasks across the processor, and that becomes more important in an MMI because it's – it's interfacing with multiple peripheral units, multiple types of events. So there's events coming from the radio at some rate, then there's also, for example, you're listening to a call and then a text message shows up or something like this, or there's an emergency signalling and it needs to transfer, and it becomes – I – I cannot imagine how you could do that without an operating system plus all the other structure to try to manage it, and this is where skilled software expertise becomes very, very key. Or at least that was my view, and I think Mr Grimmett and I have maybe a different view on that point. 867 Mr Grimmett then expressed his view in these terms: MR GRIMMETT: Again, I – I agree with Professor Rangan. It is typical to use an operating system in – in these modern times, but it's certainly not a prerequisite and – and it's – it's fairly easy for an engineer who works with these kind of products to write what's called a task scheduler and manage the interrupts to deliver this kind of concurrent processing. And, as we discussed with Mr Peck the other day, that – that's the way that all software engineers used to do it. It's unusual not to use an operating system now, but it's certainly still possible. 868 Subsequent exchanges between Professor Rangan and Mr Grimmett at T423-424 persuade me that Mr Grimmett's position was the theoretical one that it was, in principle, possible to operate an MMI without first creating an operating system. However, accepting that to be so, there would be a number of difficulties in going down that path including the fact that future hardware changes would be more easily dealt with if an operating system were present. Mr Grimmett himself accepted at T423.20-21 that '[i]t's unusual not to use an operating system now, but it's certainly still possible'. 869 I do not think that the fact that Hytera had not yet composed an operating system suggests that it was not intending to do so. I can see no reason why Hytera would have decided to dispense with an operating system and to write instead a 'lean task scheduler': T425.7-8. This was not, after all, what was usually done. Although, as Mr Grimmett explained, a system might run more efficiently without an operating system (an operating system being an additional system burden), I do not think that the risk of future difficulties if there were hardware changes would have been worth running. 870 From the fact that Hytera had not developed an operating system, I therefore conclude that its task of creating an MMI would have involved creating an operating system as well. The point of this, from Motorola's perspective, is that it meant that Hytera's prototype had somewhat further to go than just the development of an MMI. In the counterfactual where Hytera proceeded to turn the prototype into a commercialised DMR, I am satisfied that it would have, in fact, created an operating system and, on the platform of that operating system, it would then have composed an MMI. The evidence did not make clear how long it would take to develop an operating system but I take it to be a non-trivial task. 871 As I have mentioned, it is not in dispute that it was Hytera's intention to implement its eventual MMI on the ARM processor. What is in dispute is how involved a task it was to create an MMI. Motorola's position was that it was a substantial undertaking and would have taken considerable time and resources. Hytera's position was that it was a relatively minor matter which would not have taken long. 872 The question at hand is similar to the question of the length of a piece of string. This is because the form and nature of an MMI is up to its creator. Motorola's MMI was known as the Darwin Ergonomics Platform. It was an extensive interface of considerable complexity. If the question is how long would it have taken Hytera to develop an MMI of the complexity of the Darwin Ergonomics Platform then I am satisfied that this could not have been done in a short period of time, as both Professor Rangan and Mr Grimmett accepted: T420.24-36. 873 On the other hand, Mr Grimmett said that one could decide to have a much simpler interface than the Darwin Ergonomics Platform and, if one did, it might be created much more quickly. Mr Grimmett thought that such a system might be created by a single person in a period of six months: T421.39-43. 874 The difficulty with the present debate is that in order to know how long it would have taken Hytera to develop an MMI one first needs to know what kind of MMI it wished to have. In the counterfactual where one is considering how much further Hytera had to go in order to turn Professor Sun's prototype into an actual DMR device, there are a series of hypothetical decisions which Hytera would have had to have made. How much functionality did it desire on its DMR devices? How long would that functionality take to develop? The first question no doubt is informed by practical considerations directly related to ease of use by a user. But there is a competitive element to them as well. A DMR device which was simpler in form but required much more of the user would have been less competitive with the Motorola devices which were already on the market in the first quarter of 2007. 875 There is one constraint, however, from which I think something useful may be inferred. Motorola had entered the market in the first quarter of 2007. As at the end of 2007, it was still Hytera's plan to enter the market with a working DMR device within 12 or so months. The longer Hytera took to enter the market, the more entrenched Motorola's position would be. In that circumstance, I do not think that Hytera would have been likely to pursue the creation of an MMI which delayed in any significant way its market entry. This may well have meant that Hytera's MMI was not as sophisticated as Motorola's if that was the price to be paid to get to market. 876 I therefore conclude that Hytera would have cut its cloth to its commercial situation. Assuming that the MMI was developed at the end of the development process (as Mr Grimmett suggested would usually be the case), I think the most likely outcome was that Hytera would have chosen an MMI with the degree of sophistication which could be achieved in the time available to it. In reaching that conclusion, I accept Mr Grimmett's evidence at T421.39-44 that an MMI could be developed within six months with a relatively small workforce. 877 In that circumstance, it is not necessary to form a view on Hytera's contention that the Darwin Ergonomics Suite was excessively complex and filled with unnecessary features having no place in a DMR system. Whether that be so or not is not relevant to the present question of how long Hytera would have taken to bring its DMR device to completion. 878 There were then some ancillary points of secondary importance. The first concerned Professor Rangan's acceptance at T411.46 that it would have been possible for Hytera to repurpose some of the code it had written for the MMI for its analogue devices: But in principle, yes one can leverage earlier MMIs. and Mr Grimmett's evidence to the same or similar effect at T412.5-6: So Hytera could easily have used one of their previous analogue product MMIs for DMR. 879 This tends to confirm the conclusion already drawn that Hytera would have been able to produce an MMI for its DMR device in a way which would not delay its entry into the marketplace. 880 The second concerns the question of whether the code which was present in the PC and which was used to emulate an MMI for the purposes of Professor Sun's prototype could have been repurposed as part of an actual MMI. I do not think that this is really a sensible question. The MMI emulation was quite protean and repurposing it in this fashion would have served little real purpose since so much more would have remained to be done. It does not strike me as a solution which Hytera would have been likely to pursue. There is a related question as to whether the code in the PC could have been translated directly into code for the ARM processor. Professor Rangan and Mr Grimmett had different views about this. Given my conclusion, this issue does not matter. Its resolution would turn, I think, on the nature of the operating system (which I am satisfied Hytera would have produced) and whether the code on the PC was compatible with that operating system. The evidence does not permit an answer to that question. How Far Did Hytera Have To Go with Its Application Software? 881 The evidence about this was less clear. Professor Rangan's evidence was that the application software was caught up on the problem of the 'monolithic spaghetti code' which I have discussed above in relation to the protocol stack: T425.38-39. Mr Grimmett thought that most of the application software was running on the PC and it was unknown the extent to which this could be ported to the ARM processor: T426.4-12. He thought that maybe another 12 or 18 months' work lay ahead in relation to this issue: T426.10. I accept this evidence. Conclusions on How Far Hytera Had To Go To Develop Its Prototype into an Actual DMR Device 882 As at the end of 2007, it is clear that there were significant problems with the development of the FPGA. It had not been tested for adjacent channel interference or carrier interference, there were design problems, more work was needed to achieve a satisfactory RF circuit, the analogue modulator had not been tested or debugged, the functionality of the modulator limiter had not been tested and was expected to result in poor performance and likely require redesign, the functionality of the squelch algorithm had not been tested, the performance of the analogue demodulator was expected to be poor, and the receive signal strength indicator had not yet been realised. I do not think that these problems were insurmountable. I am sure that in time, had Hytera continued to pursue the commercialisation of Professor Sun's prototype, the application of sufficient engineering resources to these problems would eventually have led to their resolution. The evidence did not provide an answer to how long it would have taken to do this. The best that can be said is that the problems were significant. 883 So far as the RF unit is concerned, it had not been tested for adjacent channel or carrier interference and that work was required to be done on the RF unit to achieve a satisfactory RF circuit. Whilst this was a problem, it seems to me to be likely that Professor Sun's team would have resolved it fairly quickly given its narrowness. 884 So far as the protocol stack is concerned, a great deal of work remained to be done. Because I accept that the code was 'monolithic spaghetti' code it seems to me that the task of sorting out the protocol stack would have been difficult and time consuming. The foundations on which it rested were poorly constructed and that poor construction was likely to extract an increasing toll on the process of completing what remained to be done. Whilst I accept that a significant part of the physical and data link layers of the protocol stack had been done, as I have adverted to above (and as I explain in more detail below), two of the algorithms in the physical layer itself had not been properly simulated to assess their robustness to the impairments which happen in real world conditions. The part of the protocol stack corresponding to the physical layer might have been 90% complete, but the layer which it regulated rested on poorly constructed foundations and was, in my view, almost certain to require revision. I am not satisfied that these revisions would not have impacted the protocol stack itself. 885 Further, the fact is that the core control layer of the protocol stack was much less advanced. The protean nature of the testing which was done underscores how far this aspect of the prototype had to go. I do not think that Hytera would have had a fully functioning protocol stack for some time, possibly 12 to 18 months. Professor Rangan was less sanguine and thought that there would have been no choice but to throw it in the bin and start again: SR-21 at §23. This may well be correct. However, as I will explain shortly, it is perhaps not that useful to get into that level of detail in the counterfactual. 886 So far as the MMI is concerned, I am satisfied that Hytera would have been able to produce an MMI, probably not of the same complexity as Motorola's Darwin Ergonomics Suite, within the timeframe it had set itself for the project (on the assumption that that timeframe was achievable). 887 Combining these issues, it seems to me that the two critical ones are the FPGA processor and the state of development of the protocol stack. In my view, these constituted significant impediments to the development of Hytera's DMR device. Whilst I am satisfied that with time and patience Professor Sun's team could have surmounted these issues, the question of time brings one back to an important fact. This is that the direction in which Hytera's development would have gone after the end of 2007 would inevitably have been influenced not only by the technical abilities of Professor Sun's team, but more importantly, by the commercial realities in which Hytera by then found itself enmeshed. 888 The question then of when it was that Professor Sun's team would have been able to convert the prototype into a working DMR device is therefore not a question which arises in the correct counterfactual. The correct counterfactual includes the technical problems and the commercial realities. 889 As will shortly be seen, the real driver in Hytera's thinking at the end of 2007 was the growing realisation that if the prototype was commercialised, the resulting DMR device would cost more and have a shorter battery life than the competitor Motorola product. Lest I be wrong in that assessment, surveying the problems above, I consider that it would have taken at least another two years to iron out the problems which existed with the prototype. It could well have taken longer if, as Professor Rangan thought, the protocol stack had to be abandoned and started again. 890 In any event, I find that Hytera would not have had a working prototype suitable for commercialisation until, at the very earliest, the end of 2009. This conclusion is contrary to the evidence of Professor Sun. On the whole I accept that Professor Sun was trying to tell the truth but I am satisfied that, as the father of the prototype, he was to a degree invested in seeing merit in his own work and this tended to cloud his assessment of how far advanced the prototype actually was. 891 Having surveyed the technical issues relating to the third strand of Motorola's case against Hytera's DMR prototype, it is then useful to turn to the second strand which concerns Motorola's claim that Hytera had failed to carry out adequate simulations. STRAND TWO: THE FAILURE TO CARRY OUT SIMULATIONS 892 Although Motorola pitched its submissions about the absence of simulations as a general indictment of the way in which Hytera had approached the development of its algorithms (MCS(C) Mod II(C) at [8]), in substance its point was limited to the extent to which Hytera had performed simulations on the algorithms that it had implemented in the physical layer. It is useful to pause and recall that the physical layer is where radio signals are converted into data (to be handed to the data link layer below) or, in the opposite direction, where data (from the data link layer) is converted into a radio signal. At the risk of stating the obvious, the physical layer directly interacts with the outside world in a way in which the other layers do not. 893 It will also be recalled that I have found above at [860] that Hytera had, by the end of 2007, implemented about 90% of the physical layer in the protocol stack. At that time, I noted that Motorola criticised the work that Hytera had done on the physical layer on the basis that the algorithms in Hytera's physical layer had not been subject to simulations prior to being encoded to see whether they were adequate to deal with the kind of impairments which happen in the real world. To that issue, it is now useful to turn. 894 There are two concepts to explore here: algorithms and impairments. Algorithms 895 What algorithms were implemented in the physical layer? Professor Rangan identified two sets of algorithms in the physical layer which would require simulation in real world conditions prior to being implemented in code: SR-21 at §30. These were: algorithms dealing with modulation and demodulation; and algorithms dealing with error correction (both in transmission and on reception). 896 As I understood the evidence, the process of modulation in the physical layer is where the rubber hits the road. It is the process which takes the data which is to be transmitted and, applying it to the frequency which is being broadcast, operates on that frequency so that the data is transmitted in the signal. This may occur by causing the amplitude of the signal to be increased and decreased (amplitude modulation – AM) and also by altering the frequency within a short compass (frequency modulation – FM). The process of demodulation is what happens when the receiving devices receive the signal. Perturbations in the amplitude or frequency of the signal are converted into data. 897 As I understood Professor Rangan's evidence, the process of modulation and demodulation involves the use of algorithms (which is unsurprising). I did not understand Mr Grimmett to dissent from this view. 898 What is error correction? The topic of error correction is large. For present purposes, it may be seen as consisting of a variety of methods for ascertaining whether a message has been received without error. As a very simple example, every bit may be sent twice. The receiving device can check to see whether both bits are the same. If they are not, an error has occurred. As might be expected, a great deal of ingenuity has been expended on this topic and error correction mechanisms can be quite complex. 899 The point for present purposes is the same as the point in relation to modulation and demodulation. Error correction, of whatever sort, is performed at both the transmitting and receiving ends by means of algorithms. 900 Turning then to Professor Rangan's point, it was this: because these algorithms are operating on radio signals which happen in the real world, it is important to ensure that they work in the circumstances which can actually happen in the real world. 901 Turning then to the concept of impairments: Impairments 902 Although Professor Rangan (and Motorola) referred to impairments plurally, only one impairment was identified and this was that constituted by transmission errors resulting from signal interference: SR-21 at §30. I took this to mean the muddle which occurs when a signal being carried on a frequency finds itself degraded because some external perturbation happens to the frequency. This external perturbation could be caused by another transmission on the same frequency or result from other sources of radio waves such as lightning. Professor Rangan's Point 903 Professor Rangan thought that it was a mistake to implement one's algorithms dealing with modulation/demodulation and error correction without first checking to see how they fared when confronted with interferences of this kind. One can see the force in this. Unlike the algorithms present in all of the other layers, the algorithms in the physical layer have to navigate a world made up of actual radio signals accompanied by all of their eccentricities. I therefore accept Professor Rangan's evidence that it is wise to find out how well one's modulation/demodulation and error correction algorithms hold up in the real world before encoding them in the physical layer. 904 Of course, at the stage of development where one is thinking of writing code to give effect to these algorithms, the reality is that there is no actual device which can be tested in the real world. It was for this reason that Professor Rangan thought that the physical layer algorithms should be tested in simulations of the real world. As I understood it, this entails computer modelling of the performance of the algorithm under simulated real world frequency impairments. Professor Rangan's concern is that if one proceeded directly to encoding the algorithms in the physical layer, one ran the risk that when the device was constructed and used in the real world, one would discover that the algorithms were not up to the task at hand. At that point, one would be confronted with the difficult task of rewriting the code in the physical layer. If the code in the physical layer had already been embedded in a processor handling signalling (in the Hytera prototype, the FPGA) this would involve re-doing that processor. 905 Motorola submitted that Professor Rangan's view had been accepted by Mr Peck and by Mr Grimmett. The relevant exchange is at T359.41-360.7: MR PECK: I think it depends. In an FPGA design where you're actually building hardware and you are able to test as you build, there's at least some chance that you could successfully iterate in your hardware design in order to bring out issues, but I do agree that the simulations are typically done in advance, and if you don't do those simulations where you don't iteratively pursue your hardware design – that you could have issues. MR LANG: Thank you. And, Mr Grimmett, do you agree with that? MR GRIMMETT: Yes, with – with what John said there. So – yes. The timing of the simulations, I would agree with that Professors – Professor Rangan has written here. The extent to which you could correct issues that you find would very much depend on what the testing found and what the underlying issue was with the hardware language implementation for the FPGA. 906 Hytera submitted that this showed that simulation was not necessary in the context of FPGA (where the physical layer was implemented) because one could test as one designed: HCS(C) Mod III at [80]. The way I read Mr Peck's evidence is that if one were not designing one's hardware in an iterative fashion, testing as you went, then it would be necessary to engage in simulations first. I did not understand the evidence to mean that if one were not engaged in such an iterative design process that simulation was not necessary. The question then becomes whether Hytera was engaged in a design process which was iterative or not. I was not taken to any evidence that suggested that Hytera's development process was of the iterative kind referred to by Mr Peck. Consequently, I do not conclude that his evidence means that simulation was not necessary for the algorithms in the physical layer. I accept the evidence of Professor Rangan (and Mr Grimmett) that simulation was necessary. 907 The burden of Professor Rangan's evidence is that a failure to carry out these simulations at the outset would entail a very high likelihood of unhappiness further down the development path. In response to that suggestion, Hytera marshalled two further arguments. First, it submitted that simulations of the algorithms in the physical layer had in fact been carried out. Secondly, it submitted that the final version of the physical layer which appeared in Hytera's V1.0 in 2010 was the same as the physical layer which was present at the time of prototype. It is necessary to consider these points separately. Were Simulations Carried Out? 908 Professor Rangan, Mr Peck and Mr Grimmett all contributed to a Joint Experts Witness Conference ('JEWC-1') dated 7 July 2020. In JEWC-1, they each agreed 'that there were few wireless channel performance-related simulations, at least as found amongst the HYT produced documents'. 909 In another part of JEWC-1, Mr Peck expressed an opinion, which at first blush, appears to be at variance to the agreement he subscribed to in the preceding paragraph. That evidence was as follows: Hytera created simulation models for the DMR physical layer algorithms including digital modulation and demodulation in Matlab source code (see top-level and subdirectories: Confidential Exhibit SPF-2 - Confidential Source Code\Directory B\HYT\HYT\DMR 项目\DMR_预研\BB 基带\10.8 代码文档) as part of the FPGA design and development process. 910 These simulations were discussed with reference to two MATLAB files (MATLAB is a programming language useful for the simulation of algorithms). These two files related to simulations of the modulation/demodulation algorithms. 911 I do not think, however, that there is an inconsistency between the agreed statement and Mr Peck's particular statement. The simulations referred to in the agreed position were simulations relating to 'wireless channel performance'. Mr Peck's statement is about simulation of algorithms in a general sense and is not a statement that the algorithms had been simulated in way which tested how they performed with channel impairments. This is the natural reconciliation of the two passages. It is also the effect of Mr Peck's evidence under cross-examination. This evidence is at T359.1-14: MR LANG: Thank you, Mr Peck. Would you just focus on my question, just reading this sentence again: For example, Hytera performed few, if any, simulations of the physical layer algorithms to validate their performance in the presence of impairments in real wireless channels. Do you agree with that sentence? MR PECK: I'm unaware of any evidence I've seen that would convince me that there were – that there was such a – that there were such models created in order to do this study, other than that the hardware design – the hardware algorithms themselves – the algorithms themselves, for modulation and demodulation, had been developed as a MATLAB source code implementation. 912 Mr Peck's answer is, I accept, not altogether clear. However, on balance I accept Motorola's submission that Mr Peck was saying yes to the question he was asked. The passage read to him by Mr Lang was to the same effect as the statement Mr Peck had agreed to in JEWC-1. Since he had agreed to the statement in JEWC-1, it seems to me unlikely that he was intending to depart from it. 913 I therefore do not accept Hytera's submission that simulations of the algorithms in the physical layer had been conducted which tested their suitability when impairments were present. The simulations referred to by Mr Peck were not of this nature. 914 I reject Hytera's submission (HCS(C) Mod III at [79(a)]) that Hytera's simulations were confirmed by the interoperability test conducted in September 2007. Real world impairments were exactly what was not tested in September 2007. Did the Physical Layer Change between the Prototype and V1.0? 915 The point of this contention was to undercut Professor Rangan's suggestion that to embark upon the encoding of the physical layer without first performing simulations which included channel impairments, would mean that it was very likely that more work would need to be done down the track. By submitting that there had been no real change in the code between the prototype and V1.0, Hytera sought to demonstrate, I think, that Professor Rangan was wrong about this. 916 Hytera's submissions about this were in HCS(C) Mod III at [79(b)]. It was said that the code for the physical layer remained unchanged between the prototype and V1.0 and said this was 'discussed below'. The only discussion below I have been able to detect is the discussion at [86] where a submission was developed that the code for the protocol stack remained unchanged between the development code and V1.0. The protocol stack dealt with the protocols by which data moved between the layers and was located on the DSP. That part of the protocol stack dealing with the physical layer is not the same thing as the physical layer itself. The physical layer was implemented on the FPGA processor. I therefore do not find it proved that the evidence referred to shows that the code on the FPGA processor did not change between the development code and V1.0. Conclusion 917 I accept in principle the second strand of Motorola's criticism of the Hytera design process but find that it was only established in relation to the modulation/demodulation and error correction algorithms. The generality of the agreed statement in JEWC-1 is capable of applying to all algorithms in the physical layer. However, Motorola did not identify any actual algorithms beyond the modulation/demodulation and error correction algorithms. It has not been demonstrated that the problem was more widespread than that. 918 Motorola sought to paint this picture as blighting the entire development of Hytera's DMR project. In particular, it sought to argue that all or many of the problems I have identified in the third strand, were symptoms of this underlying design deficiency. However, this cannot be correct. As it was actually developed, the simulation problem was only shown to extend to the modulation/demodulation and error correction algorithms. I do not accept that three of the four sets of problems identified in the third strand (the RF unit, the protocol stack, and the MMI) can be seen as being symptomatic of a failure to simulate with channel impairments the modulation/demodulation and error correction algorithms. Indeed, because of the nature of the problem created by the failure to conduct the simulations, the reality is that whatever the problems were, they would not manifest until the devices were tested in a real world situation. Since this had not happened, it cannot be the case that any of these problems can be linked to this failure. The time when the failure to conduct simulations would rear its ugly head in the form of actual problems would only arise when the device was tested in real world circumstances. Further, I find it conceptually impossible to link the RF unit and the MMI to failures in these algorithms. 919 I think therefore that Motorola considerably overstates the problem. Whilst I accept that there was a likelihood that the process which Hytera adopted meant that the algorithms for modulation/demodulation and error correction would need to be revisited later in the piece when the device was finally exposed to real world conditions, I am not persuaded that this would have been quite the calamity painted by Motorola in its submissions. 920 It is then necessary to turn to Motorola's first strand: STRAND ONE: THE FAILURE TO CONSIDER COST AND BATTERY LIFE AT THE DEVELOPMENT STAGE 921 Here the contention was that Hytera had erred by separating the development of a standards compliant system from the development of a device which could be competitive. In my view, this error is abundantly established by Hytera's own documents. 922 In October 2007, Professor Sun and his team gave a presentation to Mr Chen. This was one month after Professor Sun and his team had produced the prototype. The presentation was accompanied by a document entitled 'Knowledge Guidance of DMR'. This document contained extensive background about the move to a TDMA DMR system. At slide 13 it examined the DMR development project under four headings: 'Progress and results', 'Validation objectives', 'Existing results', and 'Defects'. Under 'Defects' it said this: Platform integration is low, resulting in reduced cost, volume and power competitiveness. It is difficult to support product competitiveness because product feature function is not fully defined and developed. 923 Professor Sun was cross-examined about the meaning of the phrase 'platform integration is low' and accepted that it meant that the prototype had too many components and that they needed to be reduced in number: T1167.24-27. 924 Professor Sun subsequently oversaw a further presentation to Mr Chen which took place later in 2007. This document identified a 'platform competitiveness gap' with Motorola's products. Part of this gap was described as an 'integration gap' which was analysed at p 620.29. The Motorola devices had about 800 components whereas the Hytera devices had about 1,200. The size of the board for the Motorola devices was about 44×99 (presumably millimetres) whereas Hytera's was about 50×110. Other problems of integration were referred to on this page but may be passed over. 925 On the following page, the analysis of the 'platform competitiveness gap' continued. It is worth setting out in full: 926 It will be noted that there was a significant power consumption and cost gap. The presentation then proceeded to ponder the question of why the gap had arisen (at p 620.32) where, inter alia, the following was said: • Lab-level digital platform technology has proven to be viable, but to face the pressure of product implementation, to reduce costs and power consumption, it is into the misunderstanding of low integration. The core technical fortress-attacking team is focused on solving the technical space, and there is no clear and detailed understanding on the strict performance requirements and integration demand related to product competitiveness. The laboratory-level technical research results for each module require the guidance and integration of powerful system design and planning capabilities. • With the prototype of MOTO, after comparing the integration degree and indicators, it found that there is a gap, then we re-proposed the requirement of improving the integration degree, resulting in the adjustment of the technical plan and affection of the overall progress. At the start of the project, only the key indicators of the core technology were defined, but the other key characteristics that affect the competitiveness of the product were not defined. Due to the vacancy of this functional team all the time, the key characteristics requirements have been confirmed initially until the company's strategy meeting, but the detailed and clear positioning and requirements still need to be completed by the functional department. 927 As is common in engineering work, there then followed a root cause analysis of the problem at p 620.33: • The planning and implementation of the DMR project is a complete new technology and market industrialization project. From the strategic goal of this project, this is a large-scale company-level project. However, for the current DMR, it does not set up a cross-functional team according to the requirements of its mission and objectives. Only the R&D team that undertakes the core technology development was conducting specialization work, and the development of the platform is only a technology platform for product derived from solving core technical problems.. • The capabilities required for DMR system design are much higher than expected. It turns out that it is difficult for core technology developers to take system planning and design absent from one's special technical research work. From the difference in capabilities, system design capability and technical fortress-attacking capability need to be in an organic separation, the dedicated system design team has the energy, the ability and impetus to integrate and design a technology platform that is closer to the market and products. Other than technology development, relevant functions-bearing team for DMR is vacant, and the system design capabilities were insufficient. Compared with the progress of core technologies development, it has become a key shortcoming for the overall development of DMR project. 928 At p 620.35 under the heading 'Measures and suggestions for solving problems on DMR project' this recommendation appeared: It is recommended to immediately set up a Macro Overall Team that crosses functional departments, which is responsible for the marketing of future DMR product lines, carrying out macro-planning for products, then establishing a Micro Overall Team according to the plan, to embody the macro plan, and re-examine the existing product and technology platform. If necessary, they can overturn the existing platform and do it again. But now it is not from zero. After the previous efforts, we have accumulated a lot of valuable technical achievements and lessons, and each solution update and verification will no longer be a simple and random technical change, but will be a decision-making result correlated with the product planning. 929 I accept that these two documents demonstrate that Hytera's development process was flawed because it had failed to integrate the pursuit of the practical questions of implementation with the solving of the technical issues involved in creating a system which was compliant with the 2005 DMR Standard. Hytera assumed that these could be distinct processes when they were not. 930 Hytera's own documents therefore show that by the end of 2007, its DMR project was in trouble. The trouble derived from the problem just adverted to. It had manifested itself in the fact that there was a competitive gap between where Hytera's device appeared to be heading and Motorola's devices. This consisted of the fact that Hytera's device would consume more power and cost more. OVERALL CONCLUSIONS 931 Hytera's DMR project was confronted with two significant problems by the end of 2007. The first was that it was going to result in a product which would not be competitive with Motorola's device. The second was that that product would take at least until the end of 2009 before the process of commercialisation could begin. Professor Sun's evidence in Sun-1 at §4 was that he expected Hytera to be able to commercialise his prototype as it was in September 2007 in time for a market launch in early 2009 i.e. about 18 months. Assuming this second point to be correct, the fact that the prototype would not be ready for commercialisation until the end of 2009 entails that a product launch would not occur before the middle of 2011. Whilst I have accepted Motorola's submission that the failure to conduct simulations of the modulation/demodulation and error correction algorithms in the physical layer was another problem with the development process, I do not think that it was of the order of these two considerations. In my view, it is plain that by the end of 2007, Hytera's development of its DMR device was in disarray. It could not be permitted to go on in the same direction and something had to be done. IX THE EVENTS AT SHENZHEN INTRODUCTION 932 An action for copyright infringement does not have a mental element so if that were all that was in play, a consideration of the states of mind of the various actors would not be relevant. However, two matters make the mental state of Hytera relevant. 933 First, the claim for additional damages makes it relevant to consider whether the alleged conduct was deliberate. In this case this requires an assessment of the motives of the persons who engaged in the infringing conduct. A legal question, to be dealt with later, concerns whether this knowledge should be attributed to Hytera. Hytera's argument in that regard turns on the proposition that the ex-Motorolans were acting without authority and contrary to Hytera's interests. This raises factual questions about what Hytera's personnel were doing and why they were doing it. 934 Secondly, the question of whether Hytera is liable for infringement by reason of importation turns on whether Hytera ought to have been aware that its conduct, if performed in Australia, would have involved copyright infringement. 935 In this section therefore I consider what took place at Shenzhen under the leadership of Mr GS Kok. The questions are, broadly stated, what was happening and why. PROBLEMS CONFRONTING HYTERA'S DMR PROJECT AT THE END OF 2007 936 At the end of 2007, three challenges confronted Hytera. The first was a mandate issued by the Federal Communications Commission ('the FCC'). It is unclear precisely when this was issued but there is evidence in Hytera's own documents that suggests that the FCC had mandated that non-frequency efficient equipment would not be approved after 2005 as a result of spectrum congestion. At some point, this deadline had apparently been moved back to 2011. There was a further requirement that all public safety equipment (which I take to include the police, fire and ambulance services equipment) had to be migrated by 2013. For a manufacturer of analogue two-way radio communications, these requirements therefore imposed an impending deadline for the creation of a DMR compliant product. These stipulations were recorded in presentations given in 2009: see C14.272 at p 3. 937 The second challenge was to generate fresh business by selling DMR devices to entities which already had Hytera's analogue devices. The same presentation refers to this as the 'churning' of the analogue business. 938 The third was the fact that by the end of 2007, Hytera had not developed an actual working prototype of a DMR device. As I have explained in the previous Chapter, Professor Sun's prototype was not really a prototype in any useful sense. At best, the Hytera team had managed in a very basic way to communicate with a Motorola DMR device using equipment sitting on tables connected to a PC. Whatever one might call this, it was nowhere near ready to be turned into a saleable product. Indeed, within Hytera it had been understood by the end of 2007 that its DMR development programme had led it to a position where, even if a saleable device were produced, it would not be competitive with the Motorola DMR devices which were already on the market. 939 These were serious problems within Hytera. It had just wasted three years getting to this unfortunate position and it had less than four years before the FCC deadline. Worse, Motorola was already in the market. 940 Although it is not altogether clear, Hytera possibly sought to downplay the significance of these problems by resorting to a breakdown of its operating income attributable to analogue and digital products: HCS(C) Mod III(Supp) at [27]. These revealed that: in 2008 it derived no income from digital terminals but 83.85% from analogue terminals; in 2009 it derived 1.98% from digital terminals and 71.05% from analogue terminals; and in 2010, 6.3% from digital terminals and 54.69% from analogue terminals (by way of explanation, Hytera has other digital products). If this was intended to lessen the seriousness of the state of disarray of its DMR project from Hytera's perspective, I do not accept that it does so. The fact that the FCC mandate would be in place by 2011 provided the strongest imperative to move to digital devices. The relatively low figures for 2008-2010 are a reflection of the fact that Hytera's ability to get DMR devices to market was a mess, not that it was unimportant. 941 It is appropriate to pause and note that the significance of this problem must have been known at the highest levels within Hytera. It is known that Professor Sun had identified the third problem to Mr Chen in late 2007. Mr Chen did not give evidence but given that he was the President and Chief Executive Officer of Hytera, it is open to infer that he knew of the other problems too. I draw that inference and do so more comfortably where Mr Chen did not give evidence. 942 As I will now explain, it was also Mr Chen who set out to solve the problem. His solution was to engage Mr GS Kok who was then an employee of Motorola. THE ENGAGEMENT OF THE EX-MOTOROLANS BY HYTERA 943 The ex-Motorolans may be divided into two groups. The first group consists of Mr GS Kok, Mr YT Kok and Mr Samuel Chia. Of these, Mr GS Kok was the most senior. Mr GS Kok then brought another group of former Motorola employees across. These were Wong Kiat Hoe, Eunice Chua, Yu Kok Hoong, Han Seong, Todd Gong, Koh Yih Tze, Cheah Keng Woo, Ooi Phaik Ee (also known as Peiyi Huang (MCS(C) Mod II(C) at [48])), Lam Wai Ming and Mark Lui: HCS(C) Mod III at [146(b)]. It is useful to begin with Mr GS Kok. The Recruitment of Mr GS Kok 944 The first to arrive at Hytera was Mr GS Kok. The evidence as to what he had done at Motorola is to an extent obscure. A document discovered by Motorola (C14.243) is a spreadsheet of the ex-Motorolans. It suggests his area of work at Motorola was the subscriber device hardware and that he was on the 'Neo' hardware team (it being recalled that Neo was the internal Motorola code for the portable subscriber unit inside the Matrix program). His employee grade is listed as being 'E13?' which is higher than all of the other ex-Motorolans and consistent with my impression that he was the senior person involved. 945 The circumstances of his arrival are, to some extent, also obscure. Mr Wu Mei, a Senior Vice President of Hytera and one of its directors, gave some evidence about the recruitment. At the time of the recruitment of Mr GS Kok, Mr Wu was the Deputy General Manager and was responsible for operations, administration and human resources. Although Mr Wu was candid in his affidavit that he was responsible for recruitment, his evidence suggested that he was not responsible for the decision to engage Mr GS Kok. Instead, his evidence was that in late 2007 or early 2008 he had been asked by Hytera's President, Mr Chen, to prepare an employment contract for Mr GS Kok. He said that it was common for senior employees to be interviewed directly by Mr Chen first. If Mr Chen recommended the interviewee to the HR Department then the standard recruitment process would follow. The standard recruitment process conducted by Mr Wu did not include Mr Wu interviewing Mr GS Kok because, as he said, Mr Chen had already done that. On the other hand, he did accept that he spoke with Mr GS Kok about his relocation with his family to Shenzhen. That discussion tends to suggest, and I conclude, that Mr Wu's role in the recruitment of Mr GS Kok was no more than facilitative of a decision which had already been made by Mr Chen. Mr Chen's actions in hiring Mr GS Kok are the sine qua non for the events giving rise to this litigation. 946 Mr Chen had told Mr Wu that Mr GS Kok had strong technical experience in DMR technologies gained from working with Motorola in Malaysia. He also had good interpersonal and communication skills (particularly in English) and had leadership potential. From this, one may infer that Mr Chen was aware that Mr GS Kok had strong technical experience in DMR technologies. 947 The contract of employment was signed on 21 February 2008 although there is some evidence that he may have started a few days before on 18 February 2008. Mr Wu thought that at this time, Mr GS Kok's title and position were still unclear although he knew that Mr Chen had decided that he would take on a senior role within Hytera's Research and Development Department in relation to DMR. Mr Wu said it was hoped that Mr GS Kok would take a management and leadership role in that department: Wu at §10. Other evidence suggests that the position he was initially appointed to was that of Director of the Shenzhen Research and Development Centre Department: MCS(C) Mod III at fn 1. 948 Although Mr Chen was not ultimately called by Hytera as a witness, he did prepare an affidavit. Paragraph §12 and, at Hytera's insistence, §13 of that affidavit were tendered by Motorola. They were in these terms: 12. … We gave Mr Kok authority to manage the personnel of the DMR team, including organising the structure of the team and hiring additional people when required which is Hytera's normal practice with senior managers. 13. At around the time that Mr Kok joined Hytera, in early 2008, I recall saying to him words to the effect of 'I expect that you will adhere to your obligations to Motorola'. I trusted that Mr Kok knew what he could and could not do within the limits of his continuing obligations to his former employer, Motorola. 949 Paragraph §13 was admitted subject to a direction under s 136 of the Evidence Act 1995 (Cth) limiting its use to qualifying the second sentence of §12 (the only sentence in §12 extracted above). I take from this fragment that Mr GS Kok's role included the grant to him of authority to organise the structure of the DMR team, to manage that team and also to hire new personnel. Hytera placed reliance on §13 to advance a submission that Mr Chen had told Mr GS Kok that he expected him to adhere to his obligations to Motorola: HCS(C) Mod III at [27(b)]. Leaving aside the effect of the s 136 direction, I do not propose to act on §13. Whilst Mr Chen's affidavit is inherently reliable in terms of establishing what Mr GS Kok's role was (and, indeed, is an admission in that regard) I do not regard §13 as having the same quality. The question of whether Mr GS Kok was instructed by Mr Chen that he should adhere to his obligations to Motorola is a central question in the case. Had Mr Chen given evidence this would, no doubt, have been tested by cross-examination. There are questions about Mr Chen's role in the events which transpired. Since his evidence has not been tested, I think it would be unsafe to rely upon it. I therefore do not find on the basis of §13 that Mr Chen told Mr GS Kok that he should adhere to his obligations to Motorola. I do not find it on any other basis either. 950 Since Mr Wu seems to have taken no substantive role in the decision making which underpinned Hytera's decision to engage Mr GS Kok and since no one else apart from Mr Chen is a plausible candidate for that role, it is open to infer that it was Mr Chen who decided that Mr GS Kok should be hired to sort out the DMR problems with which Hytera was confronted. I draw that inference. Mr Chen knew that Mr GS Kok was from Motorola's DMR team and regarded him as having strong technical skills in that area. What precisely passed between Mr Chen and Mr GS Kok will never be known. One thing is known, however, and that is that on 26 February 2008, Mr GS Kok sent Mr Chen an email. Although long, it is worth reproducing in full: Dear Mr Chen, Thanks you for giving me the oppurtunity to work in your HYT organization. In the shiort 2 weeks that I have been here in Shenzhen I have meet many friends and HYT family members. First of all I would like to thank; Wumei who had gone out of his way to make sure that my stay in Shenzhen is as comfortable as possible. I would also like to that Mr Xu, Zhao Jian Jun and Zhu Guo Ping, who came to Shenzhen airport on the 11th Feb 2008 at 11:00pm to fetch me and my family to the hotel. I am also indepthed to Zhengyuanfu, who had help me during my 1st week in office. At the present moment, it looks like my accommodations is fixed and my eldest boy schooling is being arranged by "Maya" as we speaks. There are still outstanding school arrangement that I hope will be resolved very soon! I trust HYT will take care of this matters as promised prior to my trip here. As for the DMR project I am pleased to hear that there had been a team working on this project for the past 3 years. This should means that there are people familiar with the DMR requirements. However in my 1st review with them, I was shocked to find out that the radio part count was > 1,100 parts. This is extremely large part count and this need to be reduced further. I was informed that it used to be 1,275 parts. I am surprise also to find out that we do not have a prototype radio after 3 years. In order to understand interfacing and integrating problems, each circuit blocks need to be merged and a board layout! Without this we do not have any idea about the problems that we are going to face for the project. Currently I had instructed the team to do the following: 1] Compile and release the technical requirement documents; TRD. 2] Consolidate and update all sub-sections schematic into a single Proto board schematic with OMAP processor. 3] Re-organize the whole DMR group to focus on the smaller DMR models and mobiles for Uhf1 bands. 4] Source a new Frac-N Synthesizers IC. As the current one with only 3.6V tuning range is not sufficient to meet the stringent ETSI specifications. Current Motorola uses ~5V tuning range and this year they have re-designed and migrating to the 9V tuning range. The higher control voltage is desired to enable superior SNBR performance to meet European specifications. 5] There is a separate FM models? In Motorola, the FM and non-FM models are the same. The only different is the sticker and the FM battery. The rf boards are the same. So we should also look into the possibility of having the same rfto meet FM requirements. This will require the team to focus on getting the radio total capacitance to be <350uF, including worst case tolerance. 6] The team will need injection of Subject Matter Expert; (SME) from Motorola Penang and Motorola Chengdu. This will be most important if we want to leap frog onto the DMR business. 7] I will forward to you my resource proposal when you are back from your business trip. 8] The team feels that we will require 24 months to work on the DMR radio before we can move into production. Other items that the team is working on are: 1] Marketing Requirements documents (Completed) 2] Technical Requirements documents. (Completed this week need to be reviewed) 3] Hardware Management System (Pending) 4] Hardware Software Interface document. (Pending) 5] Factory Test Document (Pending) 6] Project Milestone (In progress) 7] Resource loading Plan (Under Review) 8] Organization Chart for DMR (Completed & Being Review) 9] Detail Parts and Cost Listing (Pending) 10] Engineering Capability Mapping (Done, last week) 11] Alpha & Beta test Plans and requirements (Need Sales & Marketing feedback) 12] Complete feasibility study Reports. (In Progress) 13] Accessories List and test Plan (Pending) 14] Current Conceptual Issues List and mitigation Plans (Pending) Best regards, GS Kok 951 From this email and the context in which it was sent, several matters may be inferred. First, Mr GS Kok and his family arrived late on the evening of 11 February 2008 with his family from Malaysia. Secondly, in the two weeks following his arrival, Mr GS Kok had worked assiduously on Hytera's DMR project and had drawn conclusions about it which were similar in kind to those expressed by Professor Sun just the previous year. Thirdly, whatever had passed between Mr Chen and Mr GS Kok had not included Mr Chen giving him any information about just how far behind the Hytera project was. It was for this reason that Mr GS Kok was 'shocked' to find out that the parts count exceeded 1,100 and was 'surprised' that there was no prototype. I have described the state of Hytera's prototype in the previous Chapter. Whilst there was a prototype, it was so primitive that Mr GS Kok's statement that there was no prototype may be regarded as a realistic appraisal by a person skilled in the field. As I have previously mentioned, Hytera sought to downplay Mr GS Kok's candid criticisms of what he found on the basis that he was trying to hide his own lack of expertise with the FPGA processor. I discuss this proposition later in this Chapter and reject it. Mr GS Kok's lack of enthusiasm for the FPGA processor was driven by his desire to get Hytera's product to market as quickly as possible, at the lowest possible price and with the best battery efficiency that could be achieved. 952 Fourthly, consistent with the authority that Mr GS Kok had been given, in point 6 he canvassed that he needed to get more subject matter experts from Motorola's outfit in Penang (in Malaysia) and Chengdu (in China). 953 Fifthly, Mr GS Kok thought that Hytera would be able to move into production in 24 months, that is to say, by the beginning of 2010. This 24 months estimate would have production commencing in around February 2010. As will be seen, Hytera brought its products to market in early March 2010. 954 Mr GS Kok sent Mr Chen another email on 10 March 2008. Again, although long, the contents of this email need to be set out so that the inferences to be drawn from it can be explained: Dear Mr Chen, Visitors from Penang: We had a very busy week, with 4 visitors from Penang Design Center; 2 from hardware and 2 from software. They had a wonderful stay thanks largely due to great organization from Mr Tang, Mr Wu and Stephanie! Overall they are very impressed with HYT and feel that this is a good place to work as they like the environment and the organization. During their visit here they were given technical interview by the RND team lead by Dr Sun and Mr Guo (RND General Manager). I trust they may already provided you with a summary report. We need to bring them here as soon as possible to help With the DMR project! On the technical portion of the DMR radios; [a] Frequency Generation Unit (FGU) • We find that the present scheme will have difficulty meeting the stringent DMR modulation specification of 0.15db modulation flatness needed for the 4FSK modulation. If this is not met then the digital signal cannot be recovered correctly as the 4 levels can be difficult to differentiate. • The present 3.6V Vcontrol range is too small. In Motorola, they had a 5V Vcontrol range and it was very difficult to meet DMR ACS and ACP specifications. Motorola new generation radios uses a new IC that have a 12V Vcontrol range • HYT design uses a shared buffer amplifier. This is not advisable, as there may be a need to have different injection level between transmit L/O and receiver L/O! In addition we may need different level of isolation between transmit VCO and receiver VCO. The present scheme does not allow us to perform that and will compromise our rf performance. • HYT VCO uses switch resonators for their oscillator to switch between oscillating to the transmit or receive frequency. Again this is not desirable as it does not allow us to optimize the circuit to have highest performance! [b] FPGA IC; Modulation and Demodulation IC This is a very clever IC. In it's early years it would had help HYT establish a presence, but with the new powerful OMAP processor this is now obsolete and add US$4.50 cost to the radio. I would like to propose that we write DSP code to perform the IC function. Similar to Motorola doing today. We would like to talk to Dr Sun to see if we can use his design code in the DSP processor? The team should proceed layout with FPGA but have option to remove it or by pass the IC. [c] F2 protocol requires a 1.5mS power ramp to -1dB of it's maximum power level. This is to ensure that all IQ signal send by the processor is propagated out! Currently Motorola use a 32bit RAMP DAC to full fill this requirement. his is a must as it's a DMR protocol requirements! [d] Engineer From Penang: I need you to review urgently on their package. I need them in HYT by mid April. We need to quickly work on solidifying the architecture and layout a board for proto-radio in anticipation of the coming Asia Product show in Hong Kong. Similar to IWCE in Las Vegas! Last year the show was in October. This year maybe earlier clue to the Beijing Olympic. My initial request for 8 engineers from Penang still stands. So far I had identified 5 candidates and all are waiting for you to give the Green lights and they can be here with one month notice! I may need 1 or 2 more engineers since we are going to do repeater and trunking in parrallel. [e] Engineer from Chengdu: I need you to spell out the package that HYT is willing to give to pull in good Chengdu Motorolan to come to HYT! They are well paid and taken care of by Motorola and we need to have attractive packages for them to lure them to come to Shenzhen! Our initial target of 6 Chengdu engineers may be expanded to 10 due to additional 2 for Repeater and 2 for Trunking needs. My Personal Items: [a] Children School: We had resolved the 2 youngest children school last week. Both are attending the primary school that your sons attended and they had been in schools for a week already. As we are still not able to fine suitable schools for the 13 year old and 15 year old children, I would like to propose that we sent them to International schools in Shenzhen and HYT to bear their fees for the first 2 years until they are able to catch up with their mandarin and then move them to local type schools. What's your opinion? [b] My Log In Time: Last week my secretary came and told me that I was logging in to work late on numerous occasion. I apologize for that I I want to explain to you that, I wake up at 6:00am every morning and will be waiting outside my apartment at 7:45am. I do not have a chauffeur and often I have to call either Mr Xu or Seow Wong to fetch me. Like this morning the chauffeur only arrive at my apartment at 8:15am. I had take taxi to work 3 times and twice had asked Mr Zheng and Wumei to fetch me back clue to shortage of company car. It's very troublesome for me as I don't speak good mandarin and taxi drivers are quite sneaky. Last week I had to pay RMB31 .80 for taxi from Seaview Hotel to HYT because the driver took me to somewhere else! [c] My Visa: My work visa is still pending and I had to take a trip to Hong Kong on Sunday with my wife. I hope that my work permit will be resolve by this month as I don't want to have to cross over to Hong Kong every month! We wasted half a day on Sunday going to Hong Kong and returning! [d] Stock Option: I am still not clear about how and when I'm going to get my stock option and how and when do I need to transfer money to purchase the option. Please clarify? [e] Taxation: As promised earlier, we need to figure out how to transfer RMB50,000 of my pay to a Hong Kong account! I am not sure how much tax I'll have to pay if I were to have the whole pay deposited in China account? [f] Visit to Temple at Lohu: On Saturday your chauffeur; Mr Xu, took me and the whole family up to the mountain to visit the Buddhist temple. It was very kind of him! We enjoyed that very much and really appreciate his hospitality. Best regards, GS Kok 955 The inferences are four. First, Mr GS Kok was on a recruitment drive of Motorola personnel. He had asked Mr Chen to hire eight engineers from Motorola in Penang. He was trying to get six engineers from Motorola in Chengu but might need 10. Secondly, the recruitment drive was of some urgency. Thirdly, Hytera's employment of Mr GS Kok was generous. It included the education of his children and stock options. 956 Fourthly, Mr GS Kok for the first time identified the problem with the FPGA chip. His proposal was that the DSP would be implemented on an OMAP processor (instead of an ARM) and that the whole of the hardware function which was to have been performed in the hardware on the FPGA would instead be performed in software running on the OMAP (the OMAP was eventually a C55). This would reduce the number of processors in the design and save US$4.50 per device. As I have previously noted, and as Mr GS Kok said in this email, this was what Motorola had done. The Recruitment of Mr Chia 957 As with Mr GS Kok, what precisely Mr Chia had done at Motorola is not altogether clear. The same Motorola spreadsheet I have referred to above records that his area of work was the DSP and that he was on the 'SW' team which I take to be the software team. His employee grade is listed as being 'E09'. 958 Hytera admits that Mr Chia commenced employment with it on 16 June 2008. Little more detail than that is available. Mr Wu had less involvement with this hiring because, unlike Mr GS Kok who was employed in a senior management position, Mr Chia was recruited into an engineering position: Wu at §11. Mr Chia's contract of employment is not available: Wu at §11. Given what passed between Mr GS Kok and Mr Chen, I infer that Mr GS Kok asked Mr Chia to join him at Hytera and that Mr Chia accepted that invitation. The Recruitment of Mr YT Kok 959 As I explain below, Mr YT Kok ceased attending Motorola's offices on 4 June 2008 but continued to be employed full time by it until 3 October 2008. At the time of his departure it appears that he had three roles at Motorola: Vox Feature Manager, Enhanced Privacy Feature Manager, and Matrix Overall GCP Co-ordination: C14.293. 960 Mr Wu's evidence about the recruitment of Mr YT Kok is the same as it is about Mr Chia. Motorola submitted that Mr YT Kok had given a presentation at Hytera on 4 July 2008 'within weeks of arriving at Hytera': MCS(C) Mod II(C) at [44]. In its submissions, Hytera identified that it had employed Mr YT Kok on 10 June 2008: HCS(C) Mod III at [110(a)]. I will proceed on that basis. At Hytera, Mr YT Kok appears to have worked on the HAL: C14.243. Like Mr Chia, he was a grade E09. As with Mr Chia, I infer that he was invited by Mr GS Kok to join him at Hytera. 961 It will be noted that Mr YT Kok was still employed by Motorola when he began working at Hytera. The Other Ex-Motorolans 962 The names of the other ex-Motorolans appear in the Motorola spreadsheet referred to above. By and large, these persons are not as important as the three main ex-Motorolans. Later in this section, I identify as best can be done what the personnel needs of the Hytera DMR team were after the arrival of the ex-Motorolans and the decision to abandon the FPGA processor. As will be seen, these requirements were principally for DSP engineers and persons who could do coding. 963 From the Motorola spreadsheet, it is therefore to be noted that the team of ex-Motorolans included two persons who had worked on software for the DSP at Motorola: Mr Chia and Lam Wai Ming; one who had worked on the software for the Darwin Ergonomics Platform, Mr Todd Gong; two whose designated role was software management, Ms Peiyi Huang and Mr Mark Liu; and one who had worked on the software for the hardware abstraction layer ('HAL'), Mr YT Kok. Ms Peiyi Huang's background in software management should be particularly noted since it is her Hytera laptop upon which, at one time, a large amount of Motorola's source code was present before its untimely, although not entirely successful, reformatting and its subsequent but temporary disappearance. WHAT THE EX-MOTOROLANS BROUGHT WITH THEM Matters Not In Dispute 964 The present discussion may be confined to Mr GS Kok, Mr Chia, Mr YT Kok and Ms Peiyi Huang. In its closing written submissions at [13(c)] Hytera accepted, with some qualifications, that: (a) without authorisation from Motorola, they had retained certain Motorola documents, including computer code, at the time they ceased to be employed by Motorola and when they were later employed by Hytera; (b) made use of some of these materials, including the computer code, in the development of Hytera's firmware; (c) passed on certain Motorola documents, including computer code, to other Hytera personnel involved in the development of Hytera's firmware; and (d) took steps, prior to doing so, to conceal the fact that the documents had their origin at Motorola. 965 The two qualifications are that Hytera says that the ex-Motorolans did this without the knowledge of other Hytera officers or employees and that the steps taken in (d) were taken for the purpose of concealing what was taking place from Hytera. I will return to assess both these propositions in due course. What Was Taken by the Ex-Motorolans from Motorola? 966 Dealing first with the position of Mr YT Kok, there is some debate about when it was that he actually left Motorola. Evidence obtained in the course of parallel proceedings in the US indicates that Mr YT Kok's last day of work at Motorola was 4 June 2008 (recalling that he commenced at Hytera on 10 June 2008): C14.462. However, it also suggests that he did not cease to be employed until 3 October 2008. The period after he finished work and before his employment ended was apparently accounted for by sick leave or some similar accrued entitlement not to be in the office. However, after 4 June 2008 all of his work was assigned to others and he had no actual work to do. Despite this, he had continued to have access to Motorola's systems. He attended the office on his last day on 3 October 2008 to complete what was presumably separation paperwork. 967 Unsurprisingly, Motorola keeps logs of the access its employees have to its systems. These are known as Compass Logs. The Compass Logs for Mr YT Kok indicate that on 24 March 2008 he downloaded in excess of 500 documents from Motorola's systems: T510.20. Exhibit SAS-2 to the affidavit of Mr Scott Shepard contains the relevant Compass Logs. It shows that between 20 February 2008 and 5 August 2008, Mr YT Kok accessed 880 documents. Neither party suggested that I should examine the logs to identify the nature of what was taken however a brief examination of them is useful. Although the significance of the titles of these documents will not be clear until the question of infringement is addressed, it is apparent that the documents accessed included very many directly relating to concepts which are the subject of the copyright infringement and patent infringement allegations. The documents have titles such as: Scan State Machine Design; HAL Architecture and Design Documentation; [Redacted]; Design Handbook; Power Up Time Profiling.xls; and Matrix SW Architecture. 968 Within this period, 249 files were accessed after his last day of work on 4 June 2008 including the following: darwin_architecture.doc; US Software Documentation; SR6.X Subscriber Software; Subscriber software – Mobile & Portable; Matrix_Subscriber_Unified_F2_Stack_Architecture_Document_HAL.doc; TrunkingTutorial.doc; and Scan_Architecture.ppt. 969 I conclude, having examined this log, that Mr YT Kok took large quantities of Motorola's confidential information having in many cases document names redolent of the subject matter of this litigation. 970 Turning then to Mr Chia, the accessing was much more extensive. On the following dates Mr Chia downloaded documents running into the thousands (HCS(C) Mod III at [156]): 8 April 2008: 1,310 10 April 2008: 1,524 20 April 2008: 1,081 23 April 2008: 1,822 5 May 2008: 623 971 Indeed, Mr Chia's full logs are at SAS-3 and reveal, with respect, Mr YT Kok's efforts to have been modest. From 11 March 2008, Mr Chia accessed 12,984 documents until his departure on 21 May 2008. By comparison, in his entire time at Motorola from 12 August 2003, he accessed only 13,321 documents. There is no plausible reason for him to have accessed Motorola's records on this scale beyond the obvious one that he was misappropriating its confidential information. Without dwelling too much on the detail of what was taken, it may at least be said that it included files with names such as: DMR Information Repository; Matrix SW Core/Neo Program Review – July 2004; TDMA Digital Transmit for Matrix POC (Proof of Concept); Matrix Ergo Folder; Trunking Research information; and XPR Subscriber Firmware RRR Paper Work for 1.1A M3 Alias. 972 It is clear therefore that Mr Chia also took large quantities of Motorola's confidential information. 973 As for Mr GS Kok, his logs are contained in SAS-1 and reveal more modest activity. The activity does include a document entitled 'Subscriber Hardware – Mobile & Portable' which was downloaded on 18 December 2007 (recalling that Mr Chen appears to have been considering hiring Mr GS Kok towards the end of 2007). 974 Lastly, mention should be made of Ms Peiyi Huang whose laptops I discuss in more detail later in this Chapter also in relation to the particular allegations about infringement. The forensic logs of these laptops have over 130,000 entries. Motorola extracted the highlights and attached them to its written submissions. Glossing over a lot of the detail, it is clear that this laptop at one point had upon it a very large quantity of Motorola's source code files including a large number which are the subject of Motorola's copyright infringement allegations. There is no corresponding Compass Log for Ms Peiyi Huang. My quick perusal of the Compass Logs for Mr YT Kok and Mr Chia indicates to me that they do not contain source code files on the scale which once existed on Ms Peiyi Huang's laptop. 975 It is not possible to say where Ms Peiyi Huang obtained these source code files but, inevitably, they must have come from Motorola at some point. The simplest explanation is that she took them but it is possible that someone else took them and gave them to her. What is clear, however, is this: (a) Ms Peiyi Huang certainly had them at one point; (b) she cannot have been in the slightest doubt about what they were; (c) somebody attempted to erase the evidence of these indisputable facts by the act of formatting the hard drives on her laptops; and (d) somehow the laptop was lost (although eventually found). The most likely person to have done so is Ms Peiyi Huang herself. She was not called to give evidence. I conclude that this is what she did. What Did the Ex-Motorolans Do with this Stolen Confidential Information? 976 As I have said, Hytera does not dispute that the ex-Motorolans used the confidential information they had stolen from Motorola to develop the firmware for its devices. What it does dispute, however, is the following. 977 First, it disputes that the source code which was developed within Hytera is actually objectively similar to the Motorola source code from which Motorola alleges it was copied. If objective similarity is established, Hytera accepts that the code was copied. This issue is addressed in Chapter X. The analysis is complicated by the fact that a large amount of Hytera's source code is no longer available. It was most likely on Ms Peiyi Huang's laptop at one point. As I later conclude, it was also likely present on a particular directory on a Hytera server marked '\SVN'. It too has been lost. In any event, a large portion of Motorola's case on objective similarity takes place through what can be discerned about the lost source code from disassembled object code. As will be seen, an assessment of Motorola's contentions in that regard require attention to be paid to what it actually was that the ex-Motorolans were setting out to do viz a viz the Motorola source code. 978 Secondly, Hytera submits that the acts of the ex-Motorolans were not authorised by it. 979 Thirdly, as an aspect of that submission, Hytera submits that the ex-Motorolans concealed what they were doing from Hytera and the other software engineers working on the DMR project. This raises a factual issue which calls for resolution: Did the Ex-Motorolans Conceal What They Were Doing from Other Hytera Employees? 980 The submissions of both parties on this question did not attempt to wrestle with the organisational structure of Hytera's DMR team under Mr GS Kok. It is worth pausing, however, to consider what the team was doing. 981 To read the documents in this case is to see at once that the hurdles which confronted Hytera were a series of interconnected problems. At one end, there were electronic engineering issues about how to make the physical object which is a mobile or portable radio (and receivers too). Within the device there were fundamental electronic engineering issues about how to create a system which could utilise TDMA. These overlapped with software design issues which turned on the nature of the hardware, particularly the processors, which were to be selected. Once the hardware decisions were made, there were then a set of issues about how the electronic engineering issues were to be embodied in computer code which was to run on those processors. As the Chapter dealing with the state of Hytera's DMR project at the end 2007 hopefully demonstrates, these problems could not be approached in silos. Nevertheless, the question of the creation of computer software to run on the various processors inside the devices and the questions involved in solving the electronic engineering issues which existed are conceptually distinct even if they blur into each other. For example, I think it very likely that a DSP engineer would necessarily be heavily involved in computer coding. As will be seen, Hytera's internal documents confirm that the engineers were directly involved in coding. 982 Both parties tended to elide these distinctions. Motorola relied on bountiful evidence that the ex-Motorolans shared a great deal of Motorola's electronic engineering expertise with other DMR team members such as, for example, information about how a particular technical problem had been overcome at Motorola. But it tended to ignore, although not altogether, the fact that very little of this kind of sharing involved the actual distribution of computer code. 983 Hytera, on the other hand, sought to show that whilst there was evidence that computer code had been shared within the DMR team this had been limited to distribution amongst the ex-Motorolans. 984 In my view, any assessment of the significance of the breadth of the distribution of the computer code within the DMR team must start with a consideration of what the various personnel in the DMR team were doing. For example, if there was a team of two people who were composing the computer codes based on electronic engineering specifications given to them by others, then it may not be altogether surprising that the distribution of the code largely took place inside that team. So viewed, the tight distribution of computer code may reflect not a conspiracy to keep a secret, but a natural corollary of the way in which the team worked. On the other hand, just as Motorola tended to shy away from the limited evidence of source code distribution amongst the DMR team, so too Hytera tended to avert its gaze from the overwhelming evidence that Motorola's electronics engineering information was being widely shared amongst the DMR team in circumstances where it was plain to all involved what was going on. 985 This wide scale misappropriation of Motorola's confidential electronic engineering information makes problematic Hytera's contention that the ex-Motorolans were keeping to themselves the fact that plundering was taking place. As I will explain, the evidence is clear that it must have been known to many members – probably all – of the DMR team that they were engaged in the plundering of Motorola's trade secrets. 986 Later in this Chapter, I will conclude that the distribution of repurposed Motorola source code was kept tight amongst a small group which was not, however, entirely limited to the ex-Motorolans. The evidence shows some anxiety amongst the software engineers to keep to themselves the fact that they were systematically writing some of Hytera's source code off the back of some of Motorola's source code. The question is whether this was an attempt on their part to keep the rest of the DMR team in the dark about this or whether, as Motorola would have it, it was a concerted effort to thwart any lawsuits that were brought against Hytera afterwards. Both sides' cases take as their point of departure that the ex-Motorolans and relevant software engineers were setting out to deceive somebody; they differ only as to the identity of the intended deceived party. 987 It is therefore necessary to begin with who was doing what. ROLES WITHIN THE HYTERA DMR TEAM 988 Hytera did not attempt to explain who was in its DMR team or what their roles were. The picture it painted was that there had been a team under Professor Sun; that Professor Sun and most of his team had gone to Harbin; that there was a DMR team under Mr GS Kok; but that all of the nefarious activity took place only amongst the ex-Motorolans. An unresolved question in the case includes why did Professor Sun go to Harbin? How many of his engineers did he take with him? And, to the extent that Hytera suggests that Mr GS Kok's team lacked particular resources (i.e. expertise in the FPGA processor), why its FPGA experts could not return to Shenzhen if necessary. There is clearly a missing piece about this aspect of the matter which those anxious to grasp precisely what happened will find frustrating. 989 A good place to start is with Mr Chia's presentation to Mr GS Kok on 25 June 2008 entitled 'FPGA Analysis': C8.13. As I have discussed above, Mr Chia's specialisation at Motorola had been in the software development for the DSP. It will be recalled that the DSP was one of two processors used by Motorola's DMR devices (the other being the ARM) and that the FPGA was an additional third processor used by Professor Sun's prototype. This presentation dealt in close technical detail with the advantages and disadvantages of abandoning the FPGA processor. On the assumption that the FPGA processor was to be removed, it is clear from the presentation that quite a lot of code would then need to be rewritten for the C55 processor. 990 Mr Chia's consideration of the matter is very useful because it acts as a window into what Hytera's DMR team was engaged in and, in particular, it specifies both the personnel requirements for the foreshadowed tasks if the decision to remove the FPGA were taken and the activities in which those personnel would be engaged. 991 The language is technical but it is worth stepping through it carefully. The relevant discussion begins at p 147 under the heading 'Work Estimation for the FPGA removal'. The first topic dealt with is 'Digital Tx': Digital Tx (This can be done by a non skilled DSP engineer) – 1/2 month • Bit to Symbol Mapping. Recode to C55. • RRC and LPF Filtering with rate conversion (aka Splatter Filter). Recode to C55. • 2-port modulation with amplitude and phase adjustment. Recode to C55 992 So this work was to require a non-skilled DSP engineer and would take half a month. The task involved recoding what had been written for the FPGA into what was needed for the C55. The next task was 'Digital Rx': Digital Rx (This needs to be done by a skilled DSP engineer) – 2 months / 4 months • Symbol/Bit Recovery. This may need to be changed to a lower MIPS algorithm as the current algorithm is expected to be MIPS intensive when running in the C55. • Frame Sync. Recode to C55. • IF Filter is missing. This will need to be coded in the C55 993 This work required a skilled DSP engineer and involved a change in algorithm. The coding which was available needed to be rewritten into code for the C55. Two to four months would be required. The next task was 'Analog Tx': Analog Tx (This needs an experienced DSP engineer who is familiar with Analog signaling) – 3 months • Interpolation LPF (aka, Splatter Filter). Recode to C55. • Limiter (aka Modulation Limiter). Need to reuse as the current design is too simple. • Signaling Generation (2-Tone, 5-Tone, HDC, CDCSS, CTCSS). Recode to C55 994 This required an experienced DSP engineer who was familiar with analogue signalling. Conversion of the pre-existing FPGA code for the C55 was necessary. Importantly, because the current Hytera design of the 'Limiter' was too simple this item needed to be reused. As the document taken as a whole well-shows, there is no doubt that reuse is a reference to the reuse of Motorola code. The next item is 'Analog Rx': Analog Rx (This can be done by a non skilled DSP engineer) – 1/2 month • LPF (aka IF Filter). Recode to C55 • Carrier Sync (aka AFC). Recode to C55 • Discriminator (Cordic + Diff). Recode to C55 995 This could be done by a non-skilled DSP engineer and would take two weeks. No reuse of Motorola code was envisaged, just rewriting of Hytera's FPGA code into C55. The next item is 'Common Items': Common Items (All this are new code) – 6 months • L1 Timer. Need to have this created in the C55. YT is suggesting to use a scaled down Mot solution. • Carrier Detector. This is missing from the lineup and need to be created. 1 month work. Possible reuse. • RSSI Calculation. Need to have this created in the C55. • SSI driver interface to have the C55 communicate directly with the RF Tx and Rx hardware. 996 Here the presentation makes clear that all new code would be necessary, i.e. there was no Hytera code available and it was not simply a matter of converting the FPGA code into C55. The first two items suggest that rather than writing these items from scratch, the solution was to use Motorola's code. 997 The presentation then summarised this by saying that the total amount of time needed for all of these tasks would be 14 months. 998 Turning then to the next page of the presentation, it is headed 'Additional algo work in the C55' (which I take to be a reference to further work which needed to be done on the algorithms for the C55). The first entry is 'Digital Rx': Digital Rx • LLR (Log Likelihood Ratio). This is a new algorithm to be coded. 3 months assuming reuse and performance test. 999 So the task here is to code an algorithm. The presentation contemplates that it will be reused, i.e. Motorola's source code will be utilised. The next entry is 'Mic samples processing': Mic samples processing • Mic AGC. This is a new algorithm to be coded. 2 months assuming reuse and performance test. • Mic Equalizer. This is a new algorithm to be coded. 1 month effort including capturing acoustic freq response. • Noise Suppressor. This is a new algorithm to be coded. 2 months assuming reuse and performance test. • AMBE++ and RALCWI encoding. Need to either interface or call the library component. Needs to be tested to conform to the test vectors. Estimated 1 month effort. 1000 It will be seen that two of the items involved the use of Motorola's code and two did not. The next entry is 'Speaker samples processing': Speaker samples processing • Speaker Equalizer. This is a new algorithm to be coded. 1 month effort including capturing acoustic freq response. • Alert Tone Generator. This is a new algorithm to be coded. 2 months assuming reuse and performance test. • AMBE++ and RALCWI decoding. Need to either interface or call the library component. Needs to be tested to conform to the test vectors. Estimated 1 month effort. 1001 New algorithms are to be coded. One of them is to be recoded using Motorola code. The next entry is 'Analog Tx': Analog Tx • Pre-emphasis. Code has been done and just needs performance test. Estimated to be 2 more weeks effort. 1002 So no coding needs to be done since it has already been done. The next entry is 'Analog Rx': Analog Rx • Squelch. An initial algorithm has been done but performance evaluation is still to be done. Estimated to be 3 month effort to get it to an acceptable performance level. • De-emphasis. Code has been done and just needs performance test. Estimated to be 2 more weeks effort. • Signaling Decode. Work is completed but will require a lot of performance analysis work. Estimated to be 5 months remaining work 1003 All of the code in this case has been done but more work is necessary. 1004 The presentation then summarises that a total of 23.5 months will be necessary to complete these tasks. As it happens, the Hytera products were launched in early March 2010. The FPGA Analysis document was circulated on 25 June 2008. Mr Chia's estimate is quite close to the length of time actually taken. 1005 Two matters should be inferred from the above. First, the range of personnel who were to be involved included: a non-skilled DSP engineer; a skilled DSP engineer; and an experienced DSP engineer who was familiar with analogue signalling. 1006 Although there was no reference to a need for software engineers, I infer that for the 'Common Items' at least software engineers would be necessary. The correctness of this inference is confirmed by the facts that: (a) there is no dispute that a great deal of computer coding took place; and (b) there were several software engineers amongst the ex-Motorolans including managers Ms Peiyi Huang and Mr Mark Lieu: C14.243. As I discuss later, the contents of Ms Peiyi Huang's laptop strongly suggest that she was working on the components of the Darwin Ergonomics Platform rather than the DSP. I am unable to say anything definitive about the role of Mr Mark Lieu. 1007 However, there is evidence about the structure of the Hytera's DSP team. Document C14.035 is entitled 'Portable Presentation' and at p 8 sets out the structure of the DSP team: 1008 It also provides evidence that, at least in the DSP team, engineering and coding were concurrent activities. For example, at p 9 there is set out the key people development skills for the following year: 1009 It will be seen that 'coding skill' is one of the topics. From this I infer that coding took place across the team. The document also points to a commercial launch by July 2009 at p 6. 1010 Returning to the 'FPGA Analysis' document, the second matter it demonstrates is that it was by no means the intention of the ex-Motorolans to take all of Motorola's source code. Quite a lot of the work involved rewriting the Hytera FPGA code to C55 code. Indeed, from the whole list, the only items where the copying of Motorola's code was contemplated was for the Limiter, the L1 Timer and the Carrier Detect. The fact that it was contemplated that Hytera's own code would be repurposed for the C55 detracts from Motorola's contention dealt with later in these reasons that the Court should proceed on the basis that Hytera's now missing source code was a wholesale copy of Motorola's source code. What this document shows is that what was contemplated was a more selective process than the word 'wholesale' is apt to suggest. 1011 My impression, which fits with the commercial reality with which Hytera was confronted, was that the overwhelming imperative was speed. If the fastest solution involved using Motorola's code then this would occur, but if the fastest solution involved reusing Hytera's FPGA code or even the composition of fresh code, that path would be taken. 1012 In any event, the team which was contemplated therefore included several DSP engineers of varying degrees of expertise and some software engineers. Of course, these were the team members who would be involved in the process of removing the FPGA. Naturally, there was more to the DMR team than merely the removal of the FPGA. As the list of ex-Motorolans at C14.243 shows, there were several other topics which were involved such as, for example, the design of the synthesiser and the receiver. 1013 The outline of the position is therefore discernible, although only roughly. It was open to Hytera to give evidence about the structure of its DMR team. It could have explained who its personnel were and it could have explained their respective roles. It did not seek to do this. It would have been straightforward to elicit evidence from the many persons who continue to be employed by it and who worked on this project to explain just how the DMR team worked. Even allowing that the affairs of the senior ex-Motorolans might to an extent be a little inaccessible (since they were fired sometime after Motorola's allegations came to light), this provides no credible reason for not giving an account of how its DMR team worked. I see no reason why Hytera could not have produced a complete organisational chart. I see no reason why the personnel who worked on the project could not have been called to give evidence about the topics such as the distribution of confidential information and computer code. As events transpired, one such witness was called. Later in these reasons, I conclude that the evidence of this single witness is unreliable. 1014 I turn then to the distribution of Motorola's confidential information, apart from its source code, within the Hytera DMR team. In my view, the evidence establishes that this practice was very widespread and the proposition is untenable that only the ex-Motorolans were aware that Motorola's know-how was being distributed within the Hytera DMR team. EXTENT OF KNOWLEDGE WITHIN THE HYTERA DMR TEAM THAT MOTOROLA'S OBVIOUSLY CONFIDENTIAL INFORMATION WAS BEING USED 1015 Although Motorola's submissions elides the difference, there is a distinction between the extent of knowledge within the Hytera DMR team of, on the one hand, Motorola's confidential information about how its devices worked, and on the other, knowledge that Motorola's source code was being used to develop some of Hytera's source code. This section deals with the former topic, not the latter. 1016 Mr Roger Zhang is not one of the ex-Motorolans. On 23 June 2008 he sent an email to Mr Chia: C14.058. It is worth setting out the email in full: Dear Sam: Firstly welcome your arrival warmly, we always hope that an expert of DMR protocol can come to help us and this exciting moment has finally come. We feel very honoured that you are willing to join our company and your rich experience in DMR protocol will be a big help for us. Our group has been engaged in protocol development for a period of time and met many problems which troubled us for a long time, so if you can help us solve these problems we will feel very happy and excited. We hope to learn more from you and can improve us ability in protocol stack and DSP immediately. The main questions are as follows: 1. Why did you say that Reverse Channel can't be implemented in DMR? Whether all of the services supported by two slots can't be implemented in DMR? 2. What's the main function of call hangtime and channel hangtime and how to realize these in MOTO ? What's the difference between data hangtime and voice hangtime? Would you please tell us the details of these ? 3. Would you please tell us the processing details of digital emergency signalling in direct mode? 4. Whether MOTO can support FNS service? 5. Why the value in Answer Response field filled by MOTO is differnet from protocol definition in section 7.2.2 of 102 361-2? DMR definition is"proceed = 0x20, deny=0x21", but MOTO fill"proceed = 0x00, deny=0x01". 6. Whether confirmed data service need to send data terminator after last data block has beed sent? 7. Would you please tell us the processing details of IP service? How did moto realize related IP service? 8. Would you please tell us the working process of MOTO repeater? Whether repeater need to analysis the content of physical layer frame or just repeat the frame transparently when receive it? 9. How can MOTO realize single frequency repeater at present? or can't realize it at all? 10. What's the best way to realize DSP bootloader? Can you give us some suggestions about this? 11. How much memory occupied by the code section and data section seperately of DMR protocol stack in MOTO? Which part must run in internal memory and which part can run in external memory, Can you give some suggestions about code arrangement in memory? 12. If we realize physical layer such as sync,modulation/demodulation in DSP to replace FPGA, can you give evalution about the feasibility and DSP resources occupancy? Whether we should consider transplant the upper layer code from DSP to ARM now? Best Regards! (^_^) 张颖哲 Roger Zhang 1017 There is no question that Mr Zhang is soliciting information from Mr Chia about the operation of Motorola's products. Mr Chia had only started at Hytera on 16 June 2008. Within eight days he was being asked by Mr Zhang to disclose detailed information about Motorola's devices. This is such a forward thing to do that Mr Zhang can only have sent the email if he was confident that Mr Chia was going to respond positively. Mr Zhang's email is candid in its terms. 1018 On the same day, Mr Chia then forwarded this email to Mr YT Kok at his Hytera email address (even though he was still working for Motorola): C14.058. Mr Chia replied to Mr Zhang on the same day: 'You sure have lots of questions … please feel free to drop by and discuss about some of these issues'. His email includes answers from Mr YT Kok and himself. Between them each of the questions posed by Mr Zhang was answered. The questions and answers for Mr Zhang's questions 8 and 10 will illustrate what was happening: 8. Would you please tell us the working process of MOTO repeater? Whether repeater need to analysis the content of physical layer frame or just repeat the frame transparently when receive it? (SAM) The repeater will need to decode some of the information. It is not just a dumb repater. For instance, the FEC will need to be decoded and then re-encoded to improve the data reliability. Basically all the packets will need to go through LMAC decode and LMAC encode. … 10. What's the best way to realize DSP bootloader? Can you give us some suggestions about this? (YT) DSP bootloader is not needed. The ARM bootloader will take care of this whereby it will copy the DSP code from Flash to the SDRAM and map the SDRAM to C55 memory space. Then it will start the C55 from that start vector. 1019 On the basis of this exchange I conclude that in addition to the ex-Motorolans, Mr Zhang was aware that the role of Mr Chia and Mr YT Kok was to provide information on how the Motorola products worked so that Hytera could use that information for itself. 1020 Mr Zhang subsequently asked Mr Chia about problems that he was having with the protocol stack. This exchange took place months later on 3 November 2008: C14.547. I have already rejected Hytera's contention that its protocol stack was basically ready at the end of 2007. This exchange confirms that it was not ready at the end of 2008. More importantly, it shows Mr Zhang seeking guidance from Mr Chia, Mr Chia providing that guidance, and Mr Chia telling him to use the same as was done in the Motorola products. The questions and answers are as follows: We meet some problems about protocol stack during the implementation, so we hope to get your help to solve these problems. 1. As for the call hangtime, whether the call can be interrupted by other radio during call hangtime? For example, A is calling B and when A release PTT it will get into call hangtime state, C start to call A during the call hangtime, is this be allowed or not? We have tested MOTO old version that it can be interrupted during call hangtime? or maybe the new version of MOTO has changed this? (SAM) You should follow the same as Mot. The requirements states that if the My_lD is received during the call hangtime, it will listen to the call. The mode of operation will not change. 2. As for the text message service, what kind of sap and data format should we use? If we choose short data SAP maybe we can't be compatible with MOTO, because MOTO use IP based Packet data SAP to realize text message. (SAM) You should use 0100 as it is defined as a Short message for Mot products requirements. This is to ensure compatibility. 3. What should be filled in the SP and DP field of status/precoded data? (SAM) I dont think that Mot supports this feature. Do you know what feature that we are planning to deliver would use this type of header? 4. What relationship between call type and access type? For example, whether the group call must use impolite access type and individual call must use polite access type? But Access type will be set in channel configuration, so one channel only have one kind of access type, how can we deal with this kind of difference? (SAM) Non Emergency Voice Call (Individual or Group) - Should be selectable whether it is polite or impolite (This is set for that specific channel in CPS). Emergency Call - Impolite Data Calls - Polite to both voice and other data CSBK - Polite to both Voice and other data 5. As for the psuedo trunk, if we can support two slots to receive at the same time, maybe we can receive voice in one slot and receive data in another slot to avoid missing data. Is this necessary? Whether the individual and group call have default priority? whether the call can be interrupted by the radio when it's power is strong enough? (SAM) For now, lets stick to only one slot Rx and Tx. Just go along the lines that it can use either slot. This means do not decode the data on the other slot when voice is being decoded. As of the channel access rule, we should still follow the same polite and impolite access in the non-psuedo trunk mode of operation. 1021 This shows that Mr Zhang, by this stage, had access to the internal operating mechanics of the Motorola devices. Mr Chia's advice that he should follow the Motorola approach presupposes that Mr Zhang knew what that approach was or had access to it. 1022 On 23 June 2008, Mr Zhu Guofu sent an email to Mr Chia: C14.017. Mr Guofu is not one of the ex-Motorolans. From the email, it is apparent that Mr Guofu is an engineer. The email was copied to eight other persons with Hytera email addresses. Four of these persons are ex-Motorolans but four are not. The email attaches a document setting out a series of questions about an element called AD9864. Mr Guofu's covering email says, in part, 'Grace and Yangfan have submitted some questions about AD9864's configuration'. Two of the email addresses to which the email was copied include one for a Yangfan but does not apparently include one for 'Grace' (although given the different languages this possibility is not necessarily excluded). I infer that the list of questions was prepared by at least Yangfan. The questions occupy a single page. Questions 1 and 5 are (C14.018): 1. The registers about AGC only are configured once in MOTO, dose this configuration need to be varying with the input signal strength? … 5. Why does MOTO set the reference frequecy of LO synthesizer and CLK synthesizer with 300KHZ(LOR=56 and CKR=56)? Why is not other value? The 300KHZ is the best? How to choose ? what is the principle? 1023 It will be recalled from Chapter II that the Hytera DMR project had not used an AGC so the inquiry is about Motorola's AGC. From both questions, it is apparent that the authors are aware of the internal operation of the Motorola device already and are seeking further information about it from Mr Chia. There is an openness about the inquiry which indicates candour. The questions do not suggest that their authors saw anything inappropriate about what they already appeared to know or what it was that they were seeking to know. The fact that it was distributed to eight other people within Hytera including 4 who were not ex-Motorolans likewise suggests that the parties to this exchange were not trying to keep a secret. 1024 The evidence also shows that Motorola's confidential information was available to another Hytera employee, Mr Roger Leung. On 11 April 2008, he sent an email to Mr Chia and one 'panzheng': C14.181. This email set out an extract from a Motorola document dealing with 4FSK deviations with a remark from Mr Leung: 'I saw this in the document "MOTO DMR conformance testing of radio hardware". Why the 4KSK max. deviation should be limited to 2.5kHz?' From this I infer that Mr Leung had access to confidential Motorola documents and also that that had been shared with 'panzheng'. The same email was forwarded to another Hytera engineer, Zhu Deyou. 1025 There is other evidence whose effect is the same. It is not necessary to set it out. 1026 It is open to infer on the basis of this evidence that it was widely known within Hytera's DMR team that Motorola's confidential information was being used in the development of the Hytera products. I draw that inference. EXTENT OF KNOWLEDGE WITHIN THE HYTERA DMR TEAM THAT MOTOROLA'S SOURCE CODE WAS BEING USED TO DEVELOP HYTERA'S DMR FIRMWARE 1027 To accept that Hytera's entire DMR team was aware that Motorola's confidential information was being used to develop Hytera's devices is not necessarily to accept that every person on that team was aware that its source code was being used to develop the firmware for Hytera's devices. Hytera's contention that the ex-Motorolans were keeping the repurposing of Motorola's source code to themselves is not entirely inconsistent with the fact that the team was otherwise aware that Motorola's know-how was being exploited. I now consider the question of whether knowledge of the repurposing of Motorola's source code was confined to the ex-Motorolans. After consideration of 12 matters, I am persuaded that the knowledge that Motorola's code was being used to develop Hytera's firmware was not confined to the ex-Motorolans but was most likely known by the entire team. First Matter: The Fact That It Was Widely Known within the Hytera DMR Team That Motorola's Confidential Information Was Being Used 1028 As I have said, this does not prove directly that knowledge of the repurposing of the source code was taking place. However, it is to a degree, inconsistent with the proposition that the Hytera DMR team would not have had such knowledge. The reason for this turns on motive. Hytera's case is that the ex-Motorolans wished to deceive the other members of the DMR team about their code exploitation activities. However, if everyone on the Hytera DMR team knew that Motorola's confidential information was being used to develop Hytera's devices, this secrecy makes little sense. On this hypothesis, the ex-Motorolans were content for the Hytera DMR team to know that Motorola's confidential information was being used but not content for them to know that its source code was being used as well. This bifurcated approach to secrecy appears to make little sense. Consequently, I accept that the fact that the Hytera DMR team knew that Motorola's confidential information was being used makes less likely the proposition that they did not also know that its source code was being used as well. Second Matter: The Major Work Report of 26 August 2008 1029 The presentation entitled 'Major Work Report' is at C14.028. It was circulated to a number of engineers by an email dated 27 August 2008: C14.184. Many of these engineers were not ex-Motorolans. The presentation is a review of where the DMR work had got to. The tone is upbeat. At p 7, it noted that the team had expanded from over 20 persons at the beginning of the year to 60 persons. The number is worth mentioning because it demonstrates that the team was large. Apart from Ms Xu not a single one of these persons was called. At p 10 a statement appears: The lib file provided by engineers of Pinang make us avoid to buy AMBE++ LIC from DVSI before mass production, it reduce the research risk and shorten developing period. 1030 The engineers from Penang were, of course, the ex-Motorolans. The library file provided by them shortened development time. It is not clear what this library file is. Not having a clear understanding of what AMBE++ LIC is, it would not be safe to conclude that the library file had been constituted from repurposed Motorola code. I acknowledge that it may well have been so but without more information about AMBE++ LIC this is mere speculation. I disregard this matter. Third Matter: The Subscriber Unit Task List 1031 This comprehensive document sets out the tasks involved in the development of Hytera's subscriber unit: C14.012. It was distributed within Hytera to 14 people by an email dated 7 August 2008 from Yu Yang who was not an ex-Motorolan: C14.539. The persons to whom it was sent included the ex-Motorolan, Mr Chia. It included the certainly non-ex-Motorolans Ms Ni Huang and Ms Yan Xu. Of the other 11 recipients, their names do not match any of the names of the ex-Motorolans. I conclude that they were not ex-Motorolans. The email includes instructions to update the status of the allotted task 'to your leader before noon'. It also noted, in passing, that 'we must know it is urgent for us all to ship the radio next Jun' (i.e. June 2009). It is apparent that the task list is about the subscriber unit from the last page, indicating that work on repeaters would not start until there was a working subscriber unit architecture, and the general nature of the entries. 1032 It sets out tasks for the 14 people to whom it is addressed and divides the subscriber unit project into separate tasks, for example, for the speaker. For each task, the person responsible is listed. There are a number of references to the reuse of code. Hytera submitted that these were references to the reuse of Hytera's FPGA code. I accept that there are indeed references to that topic. However, there are other references to the reuse of code which can only be references to Motorola's code. For example, in the entry for 'Frame Sync' the task list says this: Current algorithm is only doing bit-comparing mechanism. This looks like a possible solution as the symbol recovery is done even though the sync has not been recoverd. Need to investigate reuse as the current solution will not work in weak and fading signal conditions. NOTE: Mot uses Coarse Frame sync for initial sync recovery and then fine Frame sync for timing recovery for the Symbol recovery to start. 1033 What this means is that the current solution in the Hytera FPGA code does not work in weak or fading signal conditions. Consequently, code will need to be reused. It is impossible that the code being referred to is Hytera's FPGA code because that code does not work. Any doubt about this is dispelled by the explicit reference to Motorola's approach to the problem. Hytera submitted that a Hytera employee would have understood the reference to the reuse of code as being a reference to the reuse of the Hytera FPGA code. I do not accept this submission. 1034 The entry for the L1 Timer says: Interface to have the C55 communicate directly with the RF Tx and Rx hardware. 1035 It is possible that this could be a reference to an element in Professor Sun's prototype known as the L1 Timer. However, I was not taken to any evidence that Professor Sun's device had a component known as L1 Timer. On the other hand, Motorola's DSP Firmware certainly has an L1 Timer. Consequently, it appears to me more likely that the L1 Timer being referred to is Motorola's L1 Timer. I therefore infer that the list is giving to Mr Chen Ming Jun the task of creating the L1 Timer by using Motorola's source code for its L1 Timer. 1036 Motorola called only one witness in relation to this task list. This was Ms Yan Xu who had first given evidence during the patent phase of the hearing. She was recalled during the copyright trial and gave evidence that the references to the reuse of code in this task list were only understood by her to be references to the reuse of the Hytera FPGA code: see, e.g. T842.38-42. The cross-examination of Ms Xu satisfies me that it would be unsafe to rely upon this evidence. My impression was that Ms Xu was unwilling to give evidence which was adverse to the interests of Hytera (as she perceived them to be). The matters upon which I rely in reaching this conclusion are as follows: 1037 First, there is her evidence about the email exchange between Mr Chia and Mr Zhang at T828.30ff. I have discussed this email above. It shows that Mr Chia was providing Mr Zhang with confidential information about the operation of Motorola's devices. Over a series of questions, Ms Xu evaded engaging with this proposition: T828.30-831.9. At T830.8 she said she was unable to form a judgment as to whether the information was confidential; she then accepted that the information was not publicly available and this was obvious to her at the time. This demonstrates that she was unwilling to agree to the obvious. 1038 Secondly, at T837-838, Ms Xu was asked about the Frame Sync entry in the task list discussed above. It will be recalled from that discussion that it referred to the existing FPGA algorithm and said that it would not work in weak or fading signal conditions. It therefore proposed 'reuse' and explicitly referred to Motorola's approach to frame synchronisation. Ms Xu was asked about this and said that 'reuse' did not indicate 'or doesn't necessarily mean' the reuse of Motorola's code. She was then challenged that this was obviously not correct because there was no current working FPGA algorithm. To this she responded (T838.12-14): THE INTERPRETER: Okay. Our then-current FPGA algorithm did work. We did so – we verified to that, that it could still work, by various methods or means. For example, we used MPIS means to verify that our FPGA algorithm could work. 1039 This answer ignores the point being made which was that the Hytera algorithm did not work in weak or fading signal conditions and was not being used. Her response that there was a working Hytera algorithm seeks to evade the point being made. 1040 Thirdly, at T845, Ms Xu was confronted with some source code sent by her which contained a Hytera copyright date of 1988-2008. Hytera did not exist in 1988. Ms Xu thought that the copyright notice had been added by the person who created the document: T846.4. The person who created the document was Mr Zhang: T846.8-11. Ms Xu worked for Mr Zhang. When asked to explain why the reference to 1988 appeared in the document Ms Xu said that she was not quite clear about it as she had not paid attention to it before. In relation to the code, she was then asked about why the word 'Moto' was in it: T846.46-47. This exchange occurred: MR MOORE: And can you tell the court what the word "Moto" is doing in this document? THE INTERPRETER: According to my under – according to my understanding of this line – but my understanding, I'm not sure if it's correct or not – this should say that all core ID value of Motorola's for this line should be 16777215. However, this value is also included within the range of the all core ID in the DMR standard. HIS HONOUR: I don't think that was Mr Moore's question. MR MOORE: I will ask my question again. Can you explain what the word "Moto" is doing in this source code? I will ask another question, in case there's an ambiguity. Can you explain why the word "Moto" is in this source code? THE INTERPRETER: This line is only a comment, and the comment says that the default value of Motorola's all core ID is 16777215. HIS HONOUR: No. I don't think that's an answer to the question you've been asked. The question you've been asked is why does the word "Moto" appear in your source code? THE INTERPRETER: I am unable to offer an explanation on that. The reason is that I do not know who added this or what this person who added this was trying to convey. 1041 There are two possible views of this evidence. First, Ms Xu knew nothing about the fact that Motorola's source code was being used or 'reused'. On this view, this was being done by Mr Zhang and she did not know about it. She failed to notice the 1988 anomaly and the fact that the code had the word 'Moto' in it. Consequently, she was not able to say why either appeared in the code. 1042 The other view is that she was aware that the Motorola code was being used. On this view, her answers were not true since she knew precisely why both appeared in the code. 1043 The former view requires for its acceptance either that she did not read the code or that she did not understand it. I do not accept that she did not read it. I also do not accept that she did not understand it. It is inconsistent with her role of working on the protocol stack. It is also inconsistent with the role she subsequently undertook in the reprogramming of Hytera's devices when Hytera was confronted with Motorola's patent infringement allegations. In the patent phase of the hearing, Ms Xu filed a large number of affidavits explaining the steps which had been taken to reprogram the Hytera devices so that they no longer infringed Motorola's patents. This evidence is not consistent with Ms Xu not understanding code. This inconsistency can only be averted by positing that she did not understand computer code when working on the protocol stack but had learned enough by the time she came to be involved in the reprogramming of the Hytera devices some years later. This is possible but, in my view, unlikely. 1044 Accordingly, the second view of the evidence is the correct one. Against this it might be said that she had read and understood the code but had not appreciated the significance of the references to 1988 and 'Moto'. I accept the former, on its own, is possible. I do not accept that the latter is possible. There are no acceptable reasons for Motorola's name to appear in Hytera's code and its presence would, in my view, have jumped off the page. 1045 I therefore conclude that Ms Xu's evidence that she understood the references to 'reuse' in the task list as referring to the reuse of Hytera's FPGA code is only half true. She understood the word 'reuse' to be a reference to both the reuse of Hytera's FPGA code but also to the reuse of Motorola's code. There are three footnotes to this conclusion. 1046 First, the cross-examination of Ms Xu was conducted virtually with the assistance of an interpreter and with the presence of a check interpreter provided by Hytera. Many witnesses gave evidence in this format. It was not my impression that translation was an issue. 1047 Secondly, the cross-examination took place on 14 August 2020 whereas this part of the reasons is being prepared in October 2022, over two years later. The advantages of a trial judge in relation to the credibility of a witness reduce over time and generally are thought to dissipate entirely after 12 months. It is therefore appropriate to reflect on the significance of this effect. The time taken to produce these reasons relates to the significant complexity of this proceeding and the other matters pending in my docket. As at October 2022, of the matters set out above, I have only a recollection of that part of the cross-examination about the presence of the word 'Moto' in the code. At the time of the hearing, Ms Xu's evidence about this struck me as implausible. I have reviewed her examination and the documents upon which it took place. Having done so, they confirm my initial impression that this part of her evidence was implausible. For completeness, the implausibility arose from the questions asked and the answers given. I had and have no view about Ms Xu's demeanour in the sense of the way in which she held herself whilst giving those answers. Given the process of interpretation which was taking place and the difference in cultures, it would be unsafe to venture an opinion on demeanour in that sense. In any event, I formed no such opinion. 1048 Thirdly, Ms Xu is only one of a number of persons who were working on the DMR project. None of the others have been called. Mr Zhang has not been called. Mr Chen Ming Jun has not been called. Nor has any explanation been proffered for why they have not been called. Even if I had accepted Ms Xu's evidence, which I do not, it would not have established that the (many) other non-ex-Motorolan members of the DMR team did not know what was going on. Fourth Matter: The Sending of a Library File to Ms Ni Huang 1049 Later in these reasons, I find that Ms Peiyi Huang sent to Ms Ni Huang a series of files. The forensic log of Ms Peiyi Huang's laptop reveals the names of those files to be as follows: cc_build_Debug.log cc_build_Release.log Debug.lkf default_frame_list.cpp default_frame_list.h EventCode.h finel1timer.cpp finel1timer.h framer.h framer_api.cpp framer_api.h framer_common.h [Redacted] [Redacted] frame_list_primitive.cpp frame_list_primitive.h frame_primitive.h hal_omap_rftimer.cpp hal_omap_rftimer.h l1timer.h qspi.cpp qspi.h Release.lkf rfhal.h rfhal_c55.paf2 rfhal_c55.pjt rfhal_c55.sbl run_dvi.cpp run_dvi.h [Redacted] [Redacted] RFHALV01.01.000.xls framer_test.wks 1050 As will soon become clear, these are all Motorola file names. I therefore conclude that Ms Peiyi Huang sent multiple Motorola files to Ms Ni Huang. Ms Ni Huang is not an ex-Motorolan. Consequently, I find that Motorola source code files were distributed to persons who were not ex-Motorolans. Fifth Matter: The DmrDspLib Library File 1051 In Chapter XI, I reject Motorola's case that the process of disassembling object code, such as the code contained in the library file entitled DmrDspLib.lib, and a comparison between the disassembled object code and the function names appearing in Motorola's code allows one to conclude that the now missing Hytera source code for that library file was objectively similar to Motorola's source code. However, as I explain later, I do accept that the missing source code was developed from Motorola's code. 1052 In 20 February 2009, it is apparent that the source code for DmrDspLib.lib was being distributed between Hytera engineers. On that day Mr Chia emailed the following to Yu Yang, Ms Ni Huang and three other Hytera personnel: This is a library that can be used to perform Noise Suppression, Carrier Detect, Squelch and Modulation Limit. Please use this library to call those functions. There is a file which include examples of how to use it (DmrDspUT.cpp). You will need to include the DmrDspLib.h and DmrDspLib.lib files to the current porject you are using. Please use this one going forward and if there is any issues, please feedback to me. 1053 It will be recalled from Chapter VIII that one difficulty with Hytera's development prior to the arrival of the ex-Motorolans was that the squelch algorithm had not been tested, that a carrier detect algorithm had not been implemented in the FPGA, and the modulation algorithm which had been developed had not been tested. I am prepared to infer from this email that the library file which had been distributed contained code derived from the Motorola source code dealing with squelch and carrier detect. 1054 On the other hand, I am not clear on what is involved in the modulation limit and whether it corresponds to the modulation algorithm problems which Hytera had encountered (discussed in the previous Chapter). 1055 In any event, I do accept Motorola's submission that in relation to the squelch and carrier detect algorithms this is an example of code derived from its code being distributed amongst Hytera engineers including Ms Ni Huang. I am unable to identify the other three engineers to whom this email is addressed but Hytera did not seek to prove that they were ex-Motorolans and, in that circumstance, I infer that they were not since they do not have names which I accord with the names of the ex-Motorolans. Sixth Matter: The Announcement of the Removal of the FPGA 1056 On or around 2 July 2008 a decision was made, presumably by Mr GS Kok, that FPGA would be removed. This may be inferred from an email sent that day by Mr Chia enclosing a PowerPoint presentation explaining the reasons for the decision: C14.019. That email said that 'I have made the announcement to the team on the reason for the removal of the FPGA. This only covers the PS and FPGA team'. From this, one may infer that the only people affected by the removal of the FPGA were the people working on the protocol stack and those working on the FPGA. One can also infer that each member of those teams received the presentation. The presentation is at C14.020. It is clear that it is an amended version of the earlier FPGA Analysis document. 1057 I have previously referred to the fact that the task list made clear to its recipients that the current algorithm for Frame Sync was inadequate and that 'reuse' needed to be investigated as the current solution did not work in fading signal conditions. In the announcement document, this now appears in attention grabbing red letters as follows: Frame Sync. Current algorithm is only doing bit-comparing mechanism. Need to investigate reuse as the current solution will not work in weak and fading signal conditions. 1058 It is not possible to read this as a reference to the reuse of the Hytera's FPGA code because the very point being made is that the Hytera FPGA code is no good. It can only be a reference to Motorola's code. As a matter of logic, the task list must post-date the announcement document. However, the fact that the issue was flagged in the announcement to the FPGA and protocol stack teams in red letters undercuts any suggestion that the persons to whom the presentation was given would have been unaware of what was intended. 1059 In the same vein, there are two references on p 6, again in red letters, which can only be references to the reuse of Motorola's code. The first is to the L1 Timer which is in these terms: L1 Timer. Need to have this created in the C55. Looking into reusing a scaled down solution. 1060 Because it needs to be created in the C55, the discussion of the L1 Timer cannot be a suggestion that any Hytera FPGA code for an L1 Timer be reused. Further, there is no evidence that the Hytera FPGA had an L1 Timer. Consequently, when the presentation says 'Looking into reusing a scaled down solution', it can only be referring to a scaled down version of Motorola's code. Of course, as I have noted above, when this matter came to be translated into the task list (above) an explicit reference to using a scaled down Motorola solution was added. 1061 The second is the reference to a carrier detector which was in these terms: Carrier Detector. This is missing from the lineup and need to be created. Possible reuse. 1062 Here the point is that there was no carrier detect in what Hytera had by that stage done. This is consistent with the analysis in the previous Chapter that Hytera had not yet done a carrier detect algorithm. Hytera's response to that argument was that this was a minor task and that many such algorithms were publicly available. It did not submit that it had, in fact, done one. The absence of a carrier detect algorithm was inevitably known to at least the FPGA team since it was their work which lacked the carrier detect algorithm. Consequently, the statement 'possible reuse' can only be a reference to the possible reuse of Motorola's source code. 1063 Motorola also relied upon the reference to the Limiter on this page: MCS(C) Mod II(C) at [56(b)]. I am unpersuaded by this. It has not been established that the FPGA lacked a modulation limiter. The evidence only showed that its modulation algorithms had not been tested. Seventh Matter: The Sending by Ms Peiyi Huang to Wang Fei and Her On-Forwarding To Ms Ni Huang of the c55 RFHAL Library 1064 As I explain in Chapter XI, there existed within Hytera a library file known as the RAF library. This file was not ultimately compiled. The degree of copying of Motorola's code into the RAF library is much more extensive than elsewhere. However, since none of the code in the RAF library was ever used to produce the object code which Hytera then loaded into its devices, the copying into the RAF file is not directly relevant to the events in this litigation. I explain this in more detail in later in these reasons, but Motorola's case is confined to the firmware in Hytera's devices which were imported into Australia. That firmware was compiled from the now mostly missing Hytera source code. Motorola seeks to show that Hytera copied Motorola's source code into its own now mostly missing source code which it then compiled into the firmware. The compilation of one program into another is an act of adaptation (I discuss this in more detail later). A consequence of this is that unless the copied source code was itself compiled into Hytera's firmware, the copying falls off the critical path of Motorola's adaptation case. The copying into the RAF library file is therefore not directly relevant to Motorola's case. 1065 However, it seems likely that the RAF library file used a repository from which Hytera's actual source code for its devices was crafted. Although it is not possible to be definitive, it appears likely that what happened was that Hytera copied some of the source code for Motorola's DSP Firmware into the RAF library and thereafter used that code (rather than the Motorola code itself) as the base material from which its actual source code was developed. 1066 With that background, in April 2019 Ms Peiyi Huang sent an email to Wang Fei with the message 'Please try this library file out': SR-31. The file attached was rfhal_c55.lib. That file contained files with the titles including frame_list_primitive.obj, frame_primitive.obj, framer.obj and [Redacted]. As will be seen in Chapter XI these are file titles which have corresponding files in Motorola's DSP Firmware (specifically in a component called Framer, one of the works in suit). It is thus beyond argument that Wang Fei was in receipt of code derived from Motorola's code. As Professor Rangan observed, in terms of software development, the distribution between engineers of software by email is very irregular. Usually, successive versions of software under development are centrally located so that a clear record can be maintained of the development of the software. Ad hoc email distributions of library files between engineers is not how software is usually developed and in ordinary circumstances is a receipt for chaos. In my view, whilst such a process might be expected in a high school class on coding, it is not what would be expected in a multinational producer of digital mobile radios. 1067 The conceivable competing explanations for this aberrant behaviour are incompetence or deceit. Professor Sun gave evidence that the software development processes at Hytera were regular. He said that software was uploaded to a central directory on a server entitled SVN. Although Hytera now denies that there was such a directory and has not discovered such a directory, there is evidence which I explain elsewhere that makes that contention impossible to accept. Thus, at least at the time that Professor Sun was in charge of the DMR team, regular software development procedures were in place. 1068 Did they alter when the ex-Motorolans arrived? My impression of Mr GS Kok, Mr Chia and Ms YT Kok is that these were highly competent individuals deeply skilled in DMR technology and software development. They had come from the highly disciplined software development environment at Motorola and, having examined their work, it is clear that they were imbued with its rigour. Perhaps this was one of the reasons Mr Chen hired them. 1069 Did they check these skills at the door when they arrived? I think not. Mr GS Kok was working to the tightest timetable. Now more than ever was discipline in development needed. I therefore do not accept that they allowed through oversight software engineering discipline to decay into the messy state of affairs where versions of software were being circulated by email in library files. Incompetence is therefore excluded. 1070 Once incompetence is removed from the picture, only deceit remains. Motorola invited me to infer, and I do, that this highly irregular practice was designed to make it more difficult to prove that there had been any infringement of copyright. That the use of library files was hewn to this precise end is apparent from a communication which passed between Mr Chia and Mr YT Kok. C14.527 is a spreadsheet maintained by Mr Chia. It is in effect a task list with comments. Row 38 records a discussion between Mr Chia and Mr YT Kok in which the decision to use library files was discussed. The recorded discussion is this: 8/1: Discussed with YT and the decision is to 1) Reuse entire GCISS subscriber library. Requires all components to use the connection interface. 2) Extract only required component and change interface to own interface. 3) Convert required library to C Out of the selection, option 2 is the best one due to the fact that the effort to migrate is the lowest among the 3. It also has a low chance of detection if the code was disassembled by Mot. 9/26: Create code wrappers and only provide 1 header and 1 lib file. 1071 The idea being discussed is that all of Motorola's GCISS subscriber library would be reused. However, only the relevant component would be extracted and it would be converted to C (I assume it being in C++). This would result in a single library file and a header file. As such, it would have a low chance of detection if disassembled by Motorola. From this one may infer that Mr Chia and Mr YT Kok regarded the use of library files as having the purpose of being difficult for Motorola to detect. As a matter of fact, that is precisely the effect it has had as the next Chapter will demonstrate. 1072 So, from the email exchange, one may infer that both Ms Peiyi Huang and Wang Fei were involved in what I would characterise as clandestine distribution of code developed off the back of Motorola's source code. The very process of using email and a library file bespeaks deceit. 1073 Wang Fei then forwarded the library file to Ms Ni Huang thereby adding to the list of implicated individuals. Neither Wang Fei nor Ms Ni Huang is an ex-Motorolan. Neither was called to give evidence. Eighth Matter: The Email from Ms Ni Huang to Huang Guang Bi of 14 May 2015 1074 On 14 May 2015, Ms Ni Huang sent an email Huang Guang Bi. Neither is an ex-Motorolan. Its subject was 'L1timer materials'. It enclosed an .rar archive file. It contained files relating to Hytera code for the L1 Timer component (discussed in Chapter XI). I infer that these had been created using Motorola's source code (noting for now that the fact that the former was developed from the latter does not necessarily imply that they were objectively similar for copyright purposes). The email said: Guang Bin This information can only be shared between the both of us. Others cannot have access to the code and information, including Zhu Deyou, unless authorized by me. Only lib and .h can be uploaded even after implementation. The code can only be stored on your computer and mine. Best Regards! Maggie 1075 This is consistent with the deceit referred to in the previous section. The range of Hytera personnel is expanded now to include Huang Guang Bi. Ninth Matter: The Two Unsuccessful Attempts by Hytera's Commercial Terminal Product Department To Obtain Access To the HAL Software The First Attempt 1076 The Commercial Terminal Department was in the process of developing an FDMA, as opposed to TDMA, product on a standard known as dPMR. As will be recalled from the patent section, FDMA works by dividing the frequency rather than time. The nuts and bolts of such a system are therefore different. Nevertheless, it would appear they had a shared need for a DSP and a protocol stack. The person in charge of the dPMR project was Mr Gabriel Wang: SR-43. 1077 On 13 February 2009, Mr Wang attempted to obtain the assistance of the DMR team with the DSP and the protocol stack. The email was sent to Yu Yang and large number of what, I assume, were DMR engineers. The email was in part as follows: Greetings! I am a commercial terminal software development engineer and the Commercial Terminal Product Department is in the early stage of development of DCR products. Of which, it involves two tasks, namely the introduction of the DSP platform and development of the DCR platform stack. These two tasks are something new for software engineers of our department and you are experts with an abundance of related experience, so we hope that you can guide and support us. Please provide (or approve the relevant engineers to provide) the resources we want (if you already have such resources). Our project is on a tight schedule and we do not have the knowledge on this area (DSP and DCR protocol stack), so we have many problems and questions. Thank you so much for your support and help! 1078 He then set out a series of particular questions which need not be set out. On the same day, Yu Yang responded including to all of the original recipients in these terms: Hi all, You are so welcome. But I can not say yes to all of your request, the following is the reason: Most of the codes or lib are still in developing or debugging, which is not mature enough to migrate or even not finished or started. All the items we planned to finished by July. If we can share that with you now, it means that we can ship our DMR radios now, of course we can only dream so. Some important document is exist, but should be keep it as secret to protect it for the company, some of them are forbidden to even important engineers or managers. If you need this kinds of document, you'd better ask the leader of you department have a meeting with Mr. KOK, Sam and YT to decide what kind of documents could be open to you, what kind of way to share it. For the experience, some tools or skills, it is OK for us to share with you. Any kinds of problem, you can inform us to solve it together if we are not facing the urgent tasks, for us, we are glad to help you all and share or reuse everything, but it must be under some rules, I hope you can understand us. Best regards, YuYang 1079 This suggests that access to the DMR source code was not permitted even to senior engineers and managers. It also suggests that the fact that it was restricted in this fashion was very widely known inside the DMR team since Yu Yang's email was sent to a large number of DMR engineers. The nature of the restriction becomes more apparent from the second attempt. The Second Attempt 1080 The evidence about the second attempt is contradictory. Following some earlier email chains within the dPMR team, on 23 August 2011 at 4.00 pm Mr Wang emailed Ms Peiyi Huang in these terms: Hello PE: Upon validation, the RaPIS Library compiled by Shenjuan on CCSv3.3 can run on our platform. Please help to compile a RAF library that is based on C55 on CCSv3.3. Thank you for your support! Compiler settings: Memory model under build option set to large (-ml) mode. 1081 He was therefore asking for assistance in compiling an RAF library that worked on a C55 processor which, of course, was the processor the DMR team was working on. At 3.01 pm on 24 August 2011, Ms Peiyi Huang responded: 'Pls try this out…'. Although it is has now been deleted, it appears that the email had attached to it a file entitled raf_c55.lib. It is difficult to avoid the conclusion that Mr Wang had access to this file, at least for a period of time. He replied 4.56 pm on the same day thanking Ms Peiyi Huang for her assistance. 1082 Overnight Ms Peiyi Huang appears to have had a change of heart. At 8.45 am on 25 August 2011, she emailed Mr Wang in these terms: If time allows, can we have some talk on the RAF library using? I will usggest that if the UI framework of the DPMR is simpler, then it shall consider not using it as the UI framework for RAF is for more complex UI system. Pls let me know your thoughts. 1083 He replied at 9.32 am indicating that he thought it would be a good idea to discuss the use of the RAF library and that he was free anytime. At 10.36 am, she suggested that they speak at 1.40 pm. There is no direct record of that conversation. However, at 2.55 pm, Ms Peiyi Huang sent this email to Mr Wang: Hi Gabriel, After some discussion, I think the UI framework in the DPMR and DMR shall be different as DPMR shall be with simpler interaction. As such, pls take note that the CPA provision to DPMR shall not include the RAF portion upcoming. Pls spend some discussion with your team on how this can be buildup yourself. I believe it can be done with proper design. Thanks! Thks and rgds, PE 1084 I would tend to infer that a discussion had taken place and this email serves as some kind of record of the conclusion of that discussion. There is no reference of any requirement that Mr Wang delete the raf_c55.lib file he had already been sent. 1085 It appears that Mr Wang was resourceful and not deterred. On or around 30 August 2011, he called Ms Peiyi Huang's superior, Mr YT Kok, and had an initially promising discussion with him. This is known because he then sent an email to Mr YT Kok at 11.25 am on 30 August 2011 in these terms: Hello YT, Regarding my discussion with you on the application of RAF in dPMR earlier: 1) Combining dPMR's product planning and software requirements, we unanimously agreed that CPA's RAF is suitable for the dPMR software (conducive to the experience of dPMR reusing mature DMR/CPA, as well as the promotion and dissemination of CPA architecture and ideas); 2) PE is on leave and you do not have the RAF source code So, after PE returns, we will listen to PE's thoughts on the use of RAF in dPMR and discuss how to deal with the application of RAF in dPMR. Thank you! 1086 I am confident that Mr YT Kok knew just as well as Ms Peiyi Huang that the RAF library was not going to be shared with the dPMR team. Hence, point (1) represents an act of dissembling on his part. Point (2) is equally intriguing. Mr Wang had been in contact with Ms Peiyi Huang only five days beforehand and he already knew that she did not want to share the RAF library file. Point (2) is consistent in important ways with the statement made in the first attempt that even senior engineers and managers did not have access to the source code. 1087 A week later another conversation took place between Mr Wang and Mr YT Kok. The former recorded it in an email of 6 September 2011 sent to Mr YT Kok: Hello YT! We discussed the application of RAF to dPMR products earlier and the conclusions are as follows: 1) RAF will not be used in dPMR products because: (a) The relationship between RAF and Motorola is sensitive, so the spread and use of RAF should be as small as possible. (B) The use of RAF in dPMR products will generate RAF maintenance workload 2) The dPMR software team will develop the following on its own: an app management mechanism (similar to RAF), a display management mechanism (a) During the development of the app management mechanism, you and relevant personnel of the DMR team (such as Cao Cheng and Li Guannan) will provide technical guidance and support (such as by participating in the plan review) (b) the display management mechanism will be made as universal as possible so that it can be used as a general component of CPA in the future; During the development of the app management mechanism, you and relevant personnel of the DMR team (such as Cao Cheng and Li Guannan) will provide technical guidance and support (such as by participating in the plan review) We will next proceed in accordance with the above conclusions. Thank you! 1088 It does not appear, therefore, that the dPMR team obtained access to the RAF library. There is, it is true, the loose end that it was in fact sent to him on 24 August 2011. I am not able to account for this or to say when it was deleted. In any event, Motorola did not seek to rely on this aspect of this exchange. 1089 From these two efforts to obtain access to the raf_c55.lib file two important conclusions can be drawn. First, access to the source code was tightly regulated. Secondly, the fact that it was tightly regulated was known to a large number of people within the DMR team who were equally aware of why it was tightly regulated. 1090 The fact that the distribution of the code was limited so that even others who were involved in the repurposing of the Motorola source code did not have access to it makes open the inference that the purpose behind this conduct was to prevent copies of the code proliferating on Hytera's systems. This purpose is consistent with the practice of emailing copies of the library files between different engineers. It is consistent with the comment made by Mr GS Kok to Mr Chia recorded in row 38 of a task list (referred to above) that the important thing was not to get sued by Motorola. 1091 The evidence is also consistent with the proposition that the central repository of the code was Ms Peiyi Huang. It is her laptop which at one time had large swathes of Motorola's source code upon it. She is also involved in every distribution of code for which evidence remains available. 1092 Further, she had access to the SVN server. In the next Chapter I conclude that a directory \SVN existed on one of Hytera's servers. It was in this directory that the Hytera source code was stored. Hytera gave no discovery of such a directory either by its production or by a statement that it had once been in its possession but no longer was. That statement is consistent with Mr Luo's evidence that he believed that SVN was a reference to software. I reject that evidence in the next Chapter. It is not necessary to decide whether Hytera has failed to give proper discovery. Instead, for present purposes, it is enough to note that somebody, most likely Ms Peiyi Huang, deleted the SVN directory. 1093 This is because the forensic logs of her laptop shows that she was using the SVN directory even if no-one else was. In my view, Ms Peiyi Huang was the gatekeeper for the code. She maintained the development copies on the SVN directory but all access was through her email. Library files were used to make detection more difficult. 1094 What is important for the purpose of these reasons is the fact that this elaborate process was not designed to keep the DMR team in the dark. Far from it. The engineers working on the C55 must have been aware that there were parts of the code they were working on which were being developed from Motorola's code. When any coding touched on that topic, it was Ms Peiyi Huang who became involved. But the purpose of this security was not to deceive the DMR team who all knew what was happening. It was instead to reduce as much as possible the fallout if Motorola became aware that its code may have been exploited by reducing the evidentiary footprint to the maximum extent possible. As these reasons later show, this effort was to a large extent successful. Tenth Matter: the Evidence of Hytera's witnesses 1095 Hytera relied on the evidence of three witnesses to show that Hytera employees who were not ex-Motorolans were unaware that the ex-Motorolans were using Motorola's code: HCS(C) Mod III at [36]-[37]. First was Mr Wu Mei who said that he was unaware of any of Motorola's code being used: Wu at §17. However, Mr Wu was not on the DMR team and his unawareness is irrelevant. Professor Sun also gave evidence that he was shocked when he found out in 2017 that Motorola's code had been used: Sun-1 at §8. Again, however, Professor Sun was not in the DMR team by the time these events were playing out having been replaced by Mr GS Kok. Ms Xu Yan gave evidence that she did not understand the references to 'reuse' in the task lists as being a reference to the use of Motorola's code. I have rejected that evidence. Eleventh matter: The Alleged Deception of Other Hytera Employees 1096 The first deception was said to consist of the rebranding of Motorola documents as Hytera documents. There are, I accept, a number of instances in which Motorola documents were rebranded so as to appear as if they were Hytera documents. One example will suffice. There is a document produced in April 2008 entitled 'DMR Conference Testing for Radio Hardware Portable and Mobile'. It bears the Hytera logo and the words 'Shenzhen Science and Technology Centre'. However, it is clear that this document is the same as the Motorola conference testing document. The file name for the document still bears the word 'MOTO' and it includes the names of Motorola engineers: MCS(C) Mod II(C) at [39]. 1097 Hytera submitted that rebranding exercises of this kind showed that the ex-Motorolans were seeking to conceal what they were doing from other Hytera personnel: HCS(C) Mod III at [42]. The rebranding is consistent with that thesis. It is, however, also consistent with the thesis that to use Motorola's own documents to brief Hytera's staff on the development process would have carried with it a high litigation risk in the event that Motorola sued and the documents had to be discovered. 1098 There is evidence which I have referred to already which suggests that the ex-Motorolans were exercised by the risk of litigation. This is consistent with the second thesis. There is evidence which is inconsistent with the first thesis, for example, the task list. On balance, I do not accept Hytera's submission that by rebranding Motorola's documents the ex-Motorolans were seeking to deceive the other Hytera personnel. 1099 The second deception pointed to by Hytera concerned the laptop of Ms Peiyi Huang. Hytera submitted that Ms Peiyi Huang's deletion of files from her laptop, her eventual reformatting of that laptop and her failure to provide the laptop once these proceedings began constituted evidence that she was seeking to deceive Hytera. It therefore submitted that the victim of Ms Peiyi Huang's actions was Hytera. 1100 If Ms Peiyi Huang's intent was to keep from the other members of the DMR team the fact that Motorola's code was being exploited, there is the problem that the exploiting of the code was referred to in the task list and the further problem that Ms Peiyi Huang had herself sent a library file containing a large number of Motorola files to more than one non-ex-Motorolan. In that circumstance, I do not accept that her deletion of files from the laptop, her reformatting of the laptop or her failure to provide the laptop to management once discovery had been ordered, is consistent with an intention on her part to deceive the other members of the DMR team. Twelfth Matter: The Alleged Non-Arousal of the Suspicions of Management 1101 Hytera then submitted that the actions of the ex-Motorolans had not aroused the suspicions of management: HCS(C) Mod III at [43(a)]. There was indeed the evidence of Mr Wu, who was in charge of recruitment, and Professor Sun, who was replaced by Mr GS Kok. No evidence was led from Mr Chen, the President and Chief Executive Officer of Hytera, that his suspicions were not aroused. Given their positions and the timing, I accept that the suspicions of Mr Wu and Professor Sun were not aroused. I was taken to no evidence which suggested why their suspicions would have been aroused. 1102 In the absence of evidence, I do not find that the suspicions of Mr Chen were not aroused (noting that this is not the same as finding that the suspicions of Mr Chen were aroused). Conclusion 1103 Taking into account these matters I therefore make three findings. First, the fact that Motorola's code was being used as the basis for the creation of some of Hytera's source code was not concealed from the DMR team and was not a secret which the ex-Motorolans attempted to keep to themselves. In my view, all or certainly very many of the engineers were perfectly aware that Motorola's code was being used. I reject Hytera's submission that any effort was made to deceive them. 1104 Secondly, there is no evidence that the DMR team informed senior management of what was taking place. Motorola did not suggest a pathway by which this information might have reached Mr Chen. It is possible that Mr Chen and Mr GS Kok expressly discussed using Motorola's source code when Mr GS Kok was first employed. It is possible that members of the DMR team told other people within Hytera what was going on and that this information made its way to Mr Chen. For example, there appears to have been a containment breach when Mr Wang was provided with a copy of raf_c55.lib. But I am not prepared to infer anything about what he did with that file even in light of his somewhat canny correspondence with Mr YT Kok. 1105 However, both of these informational routes to Mr Chen are speculation and the evidence does not support a finding that either happened. On the basis of the evidence, I am not prepared to infer that Mr Chen was informed about what was happening via engineering employees on the DMR team or the dPMR team. That does not mean he did not know. For example, a conceptual possibility is that it was he, Mr Chen, who conceived of rescuing the Hytera DMR project by stealing Motorola's trade secrets. It may be that the whole reason that Ms GS Kok was retained was for that precise purpose. However, there is simply no evidence to that effect. There is therefore nothing upon which such an inference could be based. In that circumstance, the failure to call Mr Chen, at least in relation to this topic, does not appear to matter. 1106 Thirdly, contrary to Motorola's submissions, it is not the case that all of its code was to be used. It is quite apparent that the DMR team were generating a lot of their own code and were reusing some of Hytera's FPGA code. This conclusion is relevant to Motorola's refrain that the evidence supported a finding of wholesale copying. It does not. A more considered description of what was taking place would be that there was a discerning but significant use of Motorola's source code. THE REMOVAL OF THE FPGA AND THE REASONS FOR THAT REMOVAL 1107 It necessary to analyse the reasons why a decision was made to remove the FPGA and to perform the work which had been done (or was to be done) on it instead by means of software running on the C55 processor. This is so because Hytera submits that the reason the decision was made was because the ex-Motorolans lacked the necessary skills to continue the development of the FPGA. 1108 The hypothesis is as follows. The ex-Motorolans were engaged by Mr Chen to take over the DMR project from Professor Sun. That project used the FPGA chip. Once Mr GS Kok arrived (and after him Mr Chia and Mr YT Kok) they realised they could not deliver on what they had been retained to do because they lacked the necessary skills to utilise the FPGA. Since this was a defect on their side of the ledger they needed to conceal this deficiency from Hytera. The only way it could be concealed was if they were able to abandon the FPGA and to replace it instead with software running on the C55. To do this, they needed to concoct reasons for the abandonment of the FPGA. This they did but their real rationale for its abandonment was their lack of expertise with the FPGA. 1109 Once they had decided to proceed with the C55 instead of the FPGA it was the ex-Motorolans, not Hytera, who hit upon the reckless idea of using Motorola's source code. They needed to do this in order to meet the timelines under which they were working. Further, because the use of Motorola's code was just an aspect of the broader deception of Hytera about the reasons for the abandonment of the FPGA, the use of Motorola's code had to be concealed from other employees of Hytera lest the cat escape from the bag. 1110 In fact, says Hytera, there was nothing wrong with the FPGA at all and much work had already been done on it. Had the ex-Motorolans done the right thing by proceeding with the FPGA this would, no doubt, have required them to have confess their lack of expertise in FPGA but it would have meant that the DMR project would have got to market earlier because of the advanced state of development to which Professor Sun's team had got the FPGA. Viewed from this perspective, it was apparent that the true victim of the ex-Motorolans was not Motorola (who merely suffered the indignity of having its code exploited for Hytera's devices) but Hytera itself whose entry into the market was delayed by the conduct of the ex-Motorolans and who became, by those self-same actions, exposed to a damages suit by Motorola. 1111 The significance of this interpretation of the facts is that it provides fodder for Hytera's submission that the ex-Motorolans were acting without its authority in exploiting Motorola's source code. If so, this assists Hytera in relation to the question of additional damages and, also, to the question of whether Hytera ought reasonably to have known, had the conduct occurred in Australia, that it constituted an infringement of Motorola's copyright (by adaptation). 1112 One can admire the ingenuity of this submission weaving as it does known facts with questions of emphasis, however, I do not accept it. Parts of it I have already rejected. For example, in the previous Chapter, I have concluded that things were far from rosy in Hytera's DMR project at the end of 2007 and that the FPGA was a problem to be solved, not a benefit to be built upon. So too, I have rejected on the facts the idea that the ex-Motorolans set out to deceive their fellow DMR employees about what they were doing. 1113 It remains, however, to deal with Hytera's submission that the ex-Motorolans were motivated to remove the FPGA because of their lack of experience in it. First, it is necessary to identify the available evidence and its features. Evidence 1114 The decision to remove the FPGA was made in early July 2008. However, the origins of the decision may be seen in Mr GS Kok's initial email to Mr Chen where Mr GS Kok expressed himself shocked by the parts count for the Hytera devices. On 23 June 2008, Mr Chia sent an email to Mr GS Kok enclosing his report on 'my analysis of the FPGA'. Attached to the email was a PowerPoint presentation in which the FPGA was assessed. Because it was subsequently amended, no time need be spent on this version. The email was also copied to Eunice Chua, YT Kok and Kiat Hoe Wong each of whom were ex-Motorolans: HCS(C) Mod III at [39(b)]. Mr GS Kok replied on 25 June 2008 in these terms (which was also copied to the same persons): Sam, Interesting! I understand where you are coming from and this is going to be a tough decission to make. either way will means a lot of work for the team, but the important one is protect the company from impending law suits! I need a cost estimation of how much additional hardware is needed to make the software version works plus the resource effort, man months, to re-write softwares to look different from Motorola. I don't think we can look for a cheaper FPGA. I need you to work with Yan Fan to see what FPGA does she really need for the hardware to support Harmonized TDMA? 1115 Because this email was passing only between the ex-Motorolans there is some reason to think that if the ex-Motorolans, as Hytera suggests, lacked expertise in the FPGA that this might have been expressed in the email. It is not. 1116 Mr Chia then responded with an amended FPGA analysis on 25 June 2008 the covering email of which says: Updated spreadsheet with the effort on modifying the codes. I also listed out the likely algorithms to be re-used. As for the Harmonized TDMA, YangFan thinks that all can be done in the DSP as well and thus do not need the FPGA. I will look into the protocol as well. Will come by and discuss with you. 1117 Again, the absence of any reference to the alleged motive is notable. On the other hand, there is some support for Hytera's contention in the amended FPGA analysis document which Mr Chia then enclosed. It set out pros and cons of the FPGA. These were as follows: Pros • About 70% to 80% of the work has been completed. • Contains a L1 timer thus offloads a timing critical/MIPS intensive functionality from the C55. • 4FSK Physical layer modulation and demodulation realization has been completed. Cons • IC is expensive. • Dwindling resources in the FPGA team. • Estimated to have a lot of performance issues which had not been ironed out by original authors. 1118 The first and third of the cons aligns with the conclusions I have already drawn about it in Chapter VIII. The second suggests 'dwindling' resources in the FPGA team. A little later in the presentation under the heading 'If FPGA is removed' Mr Chia says this about the FPGA team: Lack of expertise to get a high quality FPGA implementation. Currently only Yang Fan has signal processing knowledge. The other 2 members in the team is purely a FPGA designer but not familiar with communications. Most of the team has left and followed Dr.Sun back to Harbin. 1119 There is a contradiction between the content of this observation and the heading 'If FPGA is removed' in the sense that the observation appears to be discussing a problem if the FPGA is removed. I am unable to resolve that inconsistency which is, perhaps, best explained on the basis of erratic drafting. In any event, this does not matter because what it does do is explain the FPGA problem which existed, at least to some extent. The team in Shenzhen lacked the expertise to do a high quality FPGA implementation. It appears there were members on the team with FPGA experience, Yang Fan and two others, one of whom was not familiar with communications. The rest of the team had followed Professor Sun back to Harbin. 1120 Hytera submitted that Mr GS Kok (and Mr Chia and Mr YT Kok) had a motive to abandon the FPGA because they, the ex-Motorolans, lacked expertise in it. It is open to infer from this presentation that they had on hand only three FPGA subject matter experts and that the ex-Motorolans regarded these three as a 'dwindling' resource. I accept that this is evidence that Mr GS Kok's team in Shenzhen to some extent lacked FPGA resources at this time. 1121 There is evidence which tends in the opposite direction. Under cross-examination, Professor Sun gave evidence that when he left for Harbin he took only a handful of his engineers and that he left his best FPGA engineers with the ex-Motorolans in Shenzhen. This is directly contradicted by the amended FPGA Analysis presentation which says that most of the FPGA team had followed Professor Sun to Harbin. Professor Sun also said that he had left at least 10 FPGA engineers in Shenzhen. Again, this is contradicted by the amended FPGA Analysis presentation which suggests that there were probably only three FPGA engineers left in Shenzhen. 1122 There are some reasons to think that the amended FPGA Analysis presentation is reliable. It was created contemporaneously with the events in question. It is difficult to conceive why Mr Chia would have lied in this document and said that there were dwindling FPGA resources if, in fact, that was not the case. In particular, such a lie by Mr Chia does not comport with Hytera's contention that the ex-Motorolans were inspired by a desire to conceal their relative inexperience with the FPGA. If there remained a surfeit of FPGA engineers in Shenzhen, as Professor Sun's evidence would imply, then the ex-Motorolans did not have a problem (on this hypothesis) for they had at least 10 FPGA engineers on hand. Against this, it might be said that this surplus of FPGA engineers would not have solved the suggested inexperience of the ex-Motorolans with the FPGA. However, as I note below at [1140], the evidence does not support the proposition that they lacked experience with the FPGA. 1123 On the other hand, I am unable to conceive of a reason why Professor Sun would be making up his evidence either. His evidence was contrary to Hytera's interests because, as I have just explained, it does not fit with its submission that the ex-Motorolans were motivated by a desire to conceal their inexperience with the FPGA. On that hypothesis, a shortage of FPGA engineers would have exacerbated the supposed shortcomings of the ex-Motorolans and made more necessary their decision to dispense with the FPGA. 1124 Earlier in these reasons I have already concluded that Professor Sun was an honest witness although he tended to see the state of development of his team's prototype through rose tinted glasses. The events in question had happened about 12 years before Professor Sun gave his evidence. In this case, I think it safer to rely upon what the contemporaneous documents show than on Professor Sun's evidence. To be clear, I do not think Professor Sun was giving false evidence about this. The only explanation is that the lapse of time has clouded the correctness of his recollection. I conclude that the ex-Motorolans were, as the amended FPGA Analysis presentation suggests, experiencing dwindling FPGA resources in Shenzhen. 1125 Even that conclusion, however, leaves unanswered questions. Having accepted that there were dwindling FPGA resources in Shenzhen, it would appear to follow that there were FPGA engineers on hand in Harbin with Professor Sun. In my mind, this raises a question: if a lack of FPGA expertise in Shenzhen was a problem, was it not readily soluble by recalling Professor Sun's FPGA engineers from Harbin to Shenzhen? The posing of this question opens up an ambiguity in the word 'dwindling' in the presentation. 1126 It is possible to read the reference to 'dwindling' FPGA resources as a reference simply to the geographical reality that the FPGA engineers were elsewhere. On this reading, the obstacle disclosed is, I think, relatively modest in the scheme of things. Hytera had brought a significant number of Motorola employees from Malaysia to live in China, including providing them with accommodation and paying school fees. In that context I do not think that it would have been particularly difficult to relocate a sufficient number of FPGA engineers, if they had been needed, back to Shenzhen. 1127 Consequently, if this is the problem being referred to, it seems to me to be a minor one. 1128 Another possible reading of the 'dwindling' remark is that there existed some serious impediment to the involvement of Professor Sun's FPGA team in Mr GS Kok's DMR project. Various possibilities may be imagined although each is conjectural. For example, since Mr GS Kok's team was involved in the out and out exploitation of Motorola's trade secrets, it might have been wise not to expand the number of people actually involved. On the other hand, perhaps there was bad blood between Mr GS Kok's team and Professor Sun's team. Professor Sun's prototype had been found wanting, a new team was brought in and Professor Sun and his team were relocated to Harbin. The absence of evidence does not permit a clear understanding of why Professor Sun and his team went to Harbin when they were replaced by Mr GS Kok and his team. It must remain a mystery. 1129 Consequently, I conclude that the word 'dwindling' in the FPGA Analysis presentation did not point to the existence of an insuperable impediment to bringing back to Shenzhen, if necessary, sufficient FPGA engineers to work on the project. There is no other evidence of such an insuperable impediment; in particular, Professor Sun gave no such evidence. 1130 Other parts of the amended FPGA Analysis presentation are also relevant to this issue. On p 8, Mr Chia listed possible solutions: • Use a cheaper FPGA (less gates) which supports less functionality, L1 Timer and some PHY processing if possible. • Remove FPGA but realize a lot of the critical measurable algorithm in the C55 on our own. Need to change performance of the reuse algorithms. 1131 Recalling that this was a document which passed only between the ex-Motorolans it is surprising, perhaps, if their motive was to remove the FPGA due to their lack of expertise, that one of the possible solutions was in fact to use a cheaper FPGA. It is also inconsistent with the idea that the dwindling FPGA resources in Shenzhen constituted an insurmountable obstacle to proceeding with the FPGA. This statement had appeared in the initial version of the presentation and it is evident that Mr GS Kok's statement that there was no need to proceed with a cheaper FPGA, but rather 'work with Yan Fan to see what FPGA does she really need for the hardware to support Harmonized TDMA', was penned in response to this possible solution. To my mind, this shows that Mr GS Kok was not opposed to the use of an FPGA but was looking to find out the kind of FPGA which would be needed to support TDMA. 1132 There is no direct evidence about how the decision to remove the FPGA was made. However, it is clear that it had been made by 2 July 2008. On that day Mr Chia reported to a number of persons including Mr GS Kok, Mr YT Kok and others that he had made the announcement that the FPGA should be removed. The announcement was made to the protocol stack and FPGA teams as the email makes clear: I have made the announcement to the team on the reason for the removal of the FPGA. This only covers the PS and FPGA team. Here is the presentation slide incase you want to use some of these material to announce to the entire team. BTW: I have talked to 2 of the FPGA engineers and they are keen to still do FPGA work and thus is looking to go to the TETRA team who needs FPGA engineers. 1133 It is also clear that the remaining FPGA engineers would go to the TETRA team. I have considered whether it would be permissible to reason from this that there were further FPGA resources within the TETRA team. However, Hytera has not been heard on such a proposition and it would not be procedurally fair to reason in that fashion. 1134 The presentation slides were then attached. They are at C14.020. As I have already mentioned above, examination of this document reveals it to have been a redraft of the earlier FPGA Analysis document. However, it now contains a section headed 'Reasons for FPGA removal' at pp 3-4: • It is expensive. In order to be competitive to Motorola, the cost of the radio needs to be reduced to be as low as Motorola. Price of FPGA IC = RMB38.5 • Current Estimated HYT DMR radio cost: ~RMB900 • Target HYT DMR radio cost: RMB478 • Motorola Radio cost: US$75 target (RMB525), current cost reduction can get US$85 (RMB595) by this year. This is assuming exchange rate of 1USD = 7RMB • It takes up valuable board space. Less schematic complexity and thus may reduce the number of layers in the board. • There are some algorithm implementation issues which will result in the following: • The TDMA frame synchronization will not work under fading and range conditions. Example; Moto radio can reach a range of 6km but the HYT radio can only reach 5km. If a user is traveling at 10kmph, his transmission will not be received by others). • Analog audio quality will not be good especially for low level signals. Example is when a user talks softly and it cannot be heard by the other party. This is because the modulation limiter is doing a hard clipping on the samples. • Radio will have a situation where it can falsely unmute to noise. This is because there is no Carrier Detection algorithm. • Is expected to have a high current drain consumption. This reduces battery life. • FPGA IC + Supervisory components = RMB40, • MOT pays OMAP1710 ~US$8.50 (RMB59.5). • HYT pays OMAP 5912 US$13.5 (RMB94.5) • Feron is expected be US$10.50 (RMB73.5). 1135 The detail of this may be noted. It appears to make a compelling case for the removal of the FPGA. The cost estimates of the devices in the first bullet point indicate that the proposal was to produce a radio which was less expensive than the Motorola device. Under the current development arc, the Hytera device would be nearly twice the cost of the Motorola device. Removing the FPGA would free up space on the circuit board and result in decreased schematic complexity. The problems referred to in the third bullet point, on the other hand, were not inherent in the FPGA. Rather, they were problems with the FPGA code as it currently stood. The reference in the fourth bullet point to battery drain mirrored comments which had been made in 2007 by others. Under the table of comparisons, there appears a cost analysis of the FPGA. The Hytera device at this stage already had an OMAP in it so the FPGA cost was a cost on top of that. The price saving was therefore the cost of the FPGA. 1136 So, this is the documentary record of the decision making process. Inferences from the Evidence 1137 Should one infer that the reason the ex-Motorolans decided to remove the FPGA was because they lacked expertise in it? I think the answer is that it should not be inferred. There are four reasons for this. 1138 First, if that was their motivation it requires one to conclude that in the emails which passed only between the ex-Motorolans they were astute never to refer to their actual motivation. Further, given the complexity of the comparative analysis in the final presentation, one would also need to conclude that it was all for show. Both of these are possible at least conceptually. 1139 Secondly, it has not been shown that the comparative analysis in the decision presentation is wrong. To the contrary, as I have explained in the previous Chapter, there were many problems with the FPGA. Consequently, I would not only have to accept that the nominated reasons for removal were an elaborate façade but also that they were an elaborate façade which was correct. 1140 Thirdly, I accept that the ex-Motorolans were not subject matter experts with the FPGA. If they had been subject matter experts, Mr Chia would not have said that they only had three FPGA engineers. However, I do not accept that they had no experience with the FPGA at all. The evidence does not support such a finding and common sense is against it. These were highly experienced electronic communication engineers. 1141 Fourthly, for reasons I have already given, I read the word 'dwindling' in the FPGA Analysis document as referring to the presence of a problem which could be overcome if necessary, and not to an insuperable obstacle. In the absence of any explanation for why the ample FPGA resources recently dispatched to Harbin could not be recalled, I fail to see why their inexperience with FPGA (in the sense that they were not subject matter experts) would have provided them with the motivation to embark on the escapade of which Hytera now accuses them. 1142 Taking each of these matters into account, I do not think the ex-Motorolans' motivation to get rid of the FPGA had anything to do with their suggested lack of expertise with the FPGA. They got rid of it because it was an additional cost, the code which had been developed for it was in a poor state and it presented a battery drain problem. 1143 It is now useful to turn to the relevant principles to be applied and to the manner in which Motorola advances its case. X COPYRIGHT INFRINGEMENT Introduction 1144 Motorola launched its DMR products in the first quarter of 2007. They can be classed as subscriber units, including portable DMRs (i.e. handheld) and mobile DMRs (i.e. those fitted inside vehicles), and base stations. Each type of device came installed with its own firmware. As might be expected, the firmware for each kind of device differed. The host firmware for the portable devices was known as the 'Portable Firmware', and that for the mobile devices as the 'Mobile Firmware'. 1145 Neither sets of firmware operated the DSP within these devices or the base stations. The DSP is that part of a device which implements and operates the complex requirements of the 2005 DMR Standard including synchronising and transmitting on a timeslot. Thus each mobile and portable device and each base station was also installed with what was known as the 'DSP Firmware'. 1146 Motorola's firmware is a convenient place to start a consideration of the allegations made because in its case, it is at least possible to link in the mind's eye some physical devices with the name of some computer code. However, as will shortly be seen, Motorola's firmware is not the most convenient metric by which to the judge the issues in the case. 1147 All three sets of firmware installed on Motorola's portable and mobile devices and base stations were in machine or object code which had been compiled from source code. Object code is written instructions which can be executed by the processors within the devices. Object code of this kind is generally not written by humans and consists of commands and operations of the very basic kind with which processors operate. It consists of binary code which generally are either instruction codes for the processor to execute or data upon which the processor carries out operations. For convenience to the humans who occasionally have to peer under the bonnet, these binary codes are usually represented in hexadecimal format. However, at the coal face of the processor, there are only 1's and 0's. 1148 By contrast, the source code from which the object code is compiled is written in a high level language comprehensible to humans. The process of compilation involves taking source code accessible to humans and converting it into object code accessible to processors. Compilation is itself carried out by software running on computers. It is not a simple matter of translation because the higher level concepts in the source code very rarely have any analogue in the low level language of the processor. Rather the compiler constructs the object code so that it carries out the intentions expressed in the higher level language of the source code. Rather than translation, a better analogy would be to consider the relationship between the plans drawn by an architect for an office tower and the eventual stream of instructions given to the tradespersons who then construct it. One gives rise to the other but in no real sense is one a translation of the other. 1149 In this case, Motorola's source code for all three sets of firmware was mostly written in a widely used high level language known as C++. 1150 Motorola does not allege that the copyright in its object code has been infringed. Rather, it alleges that the copyright in the source code from which that object code was compiled has been infringed. 1151 At a very high level of generality, Motorola alleges that this source code was copied by Hytera when the latter's engineers were writing the source code for the firmware for Hytera's own mobile and portable devices and base stations. Some of that source code was written in C++ and some in a related language C. Like Motorola, Hytera then compiled from that source code the object code which was then installed as the firmware on its devices. 1152 Motorola's copyright infringement case has two elements. First, it alleges that it was an infringement of its copyright in its source code for Hytera to import its devices containing Hytera's firmware into Australia. Secondly, it alleges that it was an infringement of its copyright in its source code for Hytera to make available for download from a website the firmware for its devices. Largely, these two cases raise the same issues, although in the case of importation, it is also necessary for Motorola to establish that Hytera knew that the importation of the devices involved an infringement (loose language which will do for now). 1153 So there are three links in the chain from Motorola's perspective. First, the copying by Hytera of Motorola's source code when Hytera produced the source code for its own devices. This occurred in China. Secondly, the compilation of Hytera's source code into object code and the installation of that code on Hytera's devices in the form of firmware. This too happened in China. Thirdly, the importation into Australia of those devices or the supply of the same firmware in Australia from a website. 1154 Motorola does not allege that its copyright was infringed by either of the first two stages. Whilst an infringement of Motorola's copyright may have occurred, it was not an infringement of its Australian copyright. By contrast, the third step, if established, does involve an infringement of its Australian copyright. From where does Motorola's Australian copyright derive? Motorola's source code was composed in the US by a variety of its individual employees which has resulted in it being the owner of the copyright in the source code in the US. The Copyright Act 1968 (Cth) ('Copyright Act') contains provisions which confer on the owner of a copyright in some nations (of which the US is one) an Australian copyright in respect of the same work. These provisions are not in issue in this case and it is not necessary to traverse them. The point for present purposes is that Motorola owns the Australian copyright in the source codes constituting the 11 works in suit. 1155 To this point it has been convenient to refer to Motorola's source code for the firmware in general terms. It is now useful to be more specific. In the practical way in which this trial played out, it is productive of confusion to begin at the level of the source code for the firmware. There are several reasons for this. 1156 The first source of confusion is that the parties used the expression 'firmware' when discussing Hytera's devices to designate the object code which had been compiled from its source code whereas they decided to use 'firmware' when referring to Motorola's devices to designate its source code. Both Motorola and Hytera's devices had firmware of this kind which was compiled from antecedent source code. This litigation is therefore concerned with Motorola's allegation that its firmware source code has, in various ways, been infringed by the importation into Australia by Hytera of devices installed with Hytera's own firmware and by making that firmware available for download in Australia from a website. 1157 Having regard to the earlier observations about the relationship between object code and the source code from which it is compiled, a concern may be raised at the outset as to how, in general, object code can ever involve a copying of source code in a different language since there will be a lack of objective similarity. To continue for a moment the analogy between architects' plans and the instructions given to the tradespersons who construct a building, it is not self-evident that copying the latter would involve an infringement of the copyright in the former. As will be seen, the Copyright Act provides one answer to this by deeming the object code to be a reproduction of the source code. There is also a possibility that object code compiled from source code is an adaptation of that source code. The allegations in this case are, however, more complicated. The allegation is that one set of source codes has been copied into a second set of source codes and then compiled into a third set of object codes. I will return to this topic in more detail in the next section of this Chapter. 1158 The second source of confusion is that Motorola puts its infringement case at three levels of generality. At the first or highest level is a case alleging infringement of the copyright in its firmware source code, that is to say, the Portable Firmware source code, the Mobile Firmware source code and the DSP Firmware source code. At this level, the three sets of firmware source code are viewed as entire programs and each is alleged to be a single literary work. 1159 At the second or intermediate level, Motorola alleges that within the Mobile and Portable Firmware source codes, there was to be found another literary work known as the 'Darwin Ergonomics Platform'. It is alleged that the copyright in this platform had also been infringed by Hytera's firmware (I use the expression 'infringed by Hytera's firmware' as a convenient, although not altogether accurate, shorthand for Motorola's two infringement cases). Also within this second or intermediate level, Motorola alleges that the DSP Firmware source code includes within it two further literary works: the 'framerLib Library' and the 'HAL Serial Buffer'. 1160 Conceptually, therefore, the structure of Motorola's case resembles a suit in which the author of a novel alleges that the whole novel has been copied and simultaneously alleges that Chapter 3 has been copied as well. 1161 At the third level, Motorola alleged that there were still further literary works. The Darwin Ergonomics Platform is itself said to include three programs known as the Ergonomic Manager Task ('EMT'), User Indication Task ('UIT') and the User Input Translation Task ('Xlate'). Further, within the framerLib Library are said to be included two further literary works: the 'Framer' and the 'L1 Timer'. Continuing the novel analogy, these may be seen as allegations that paragraphs have been copied. 1162 Since the HAL Serial Buffer is not said to have any further components, it is conceptually easier to include it in the third layer (although as a constituent element of the DSP Firmware it has some claim to be included in the second layer). 1163 Motorola's allegations are therefore hierarchical. That hierarchy may be illustrated in this way: Level 1 Mobile Firmware Portable Firmware DSP Firmware Level 2 Darwin Ergonomics Platform Darwin Ergonomics Platform framerLib Library Level 3 EMT EMT Framer Xlate Xlate L1 Timer UIT UIT HAL Serial Buffer 1164 It is convenient to think of Motorola's case structured in this hierarchical way because it emphasises that the programs in the lowest or third level are smaller than those in the second level which are in turn smaller than those in the first level. An added complexity is that there are some loose files in Level 1 which are alleged to have been copied but which are not part of Levels 2 and 3. 1165 Motorola must establish not only that the Hytera firmware involves a reproduction of a part of the Motorola source code, but also that the part which has been copied is a substantial part of the literary works alleged. As is well known in this area, the concept of 'substantial' has both qualitative and quantitative elements. Thus, because the works in the third layer are smaller, Motorola may bear an easier burden in showing that a substantial part has been copied than it bears in relation to the first layer. A single copied sentence may not constitute a substantial part of a novel but it is possible that it constitutes a substantial part of a paragraph. 1166 This brings one to Motorola's submissions about the substantial parts which it alleges have been taken from its source code. Motorola's written submissions about what had been copied made no attempt to connect themselves to the case which it had particularised on that topic. Further, whilst Hytera made fleeting references to Motorola's particulars, it too skirted any direct encounter with them. In fact, the particulars provided are not readily comprehensible to persons who have not been given access to the large quantity of Hytera and Motorola source code referred to in them. As the case was conducted, it was the experts who considered some of the various tracts of source code identified in the particulars. They expressed particular opinions about it and, often enough, set parts of it out. Neither party complained that the other had stepped outside the particulars. 1167 Motorola made distinct submissions about the 'nature and extent of similarities between the Particularised Hytera Code and the Motorola Works' in MCS(C) Mod II(E). These were directed at the question of whether the accused Hytera source codes were objectively similar to the Motorola source codes. As the case was finally run, Hytera conceded that if objective similarity were established then the Hytera source codes had been copied from the Motorola source codes. These submissions were at [44]-[88]. Motorola also made submissions at [89]-[150] on whether what had been copied constituted a substantial part of the literary works on which it relies (which Hytera did not concede). 1168 Those submissions were divided into three parts. In the first part, at [97]-[123] it submitted that a substantial part of each of the: Darwin Ergonomics Platform; EMT; UIT; and Xlate had been copied into the Hytera source code. 1169 In the second part, at [124]-[128] it submitted that a substantial part of the: framerLib Library; Framer; and L1 Timer had been copied into the Hytera source code. 1170 In the third part, at [129]-[134] it submitted that a substantial part of the HAL Serial Buffer had been copied into the Hytera source code. 1171 In the fourth part, at [135]-[140] it submitted that a substantial part of the Mobile and Portable Firmware source codes had been copied into the Hytera source code. 1172 In the fifth part, at [141]-[150] it submitted that a substantial part of the DSP Firmware source code had been copied into the Hytera source code. ADMISSIONS BY HYTERA AND THE WAY IT PUTS ITS DEFENCE 1173 Hytera does not dispute that copyright subsists in the pleaded Motorola works (see above at [1158]-[1161]) and that Motorola is the owner of that copyright. It put its case this way: (a) Motorola has not proven that there is an objective similarity between the particularised parts of its source code and the impugned parts of the Hytera source code. However, if objective similarity is established, then Hytera accepts that it is not the consequence of random coincidence and that the Court may proceed on the basis that the objectively similar portions of the Hytera source code relied upon by Motorola were copied from the corresponding portions of the Motorola works. (b) If Motorola surmounts that problem, Hytera next submits that Motorola has failed to show that the portions of its source code which were copied into the Hytera source code were original. Here the point was that the Motorola works were the result of development over a long period of time. The version of the source code which Motorola relied upon (Version R01.00.01) at trial was but the most recent revision of a family of programs which over the years had been incrementally tinkered with. Whilst Hytera accepted that each of the Motorola works was a literary work in which copyright subsisted, it submitted that Motorola had to demonstrate that each part of the source code which it alleged had been copied by Hytera was original, in the sense of not having been copied from elsewhere and, in particular, not copied from earlier iterations of the same source code. (c) If Motorola overcomes that difficulty, Hytera then submits that Motorola has failed to demonstrate that the portions of its source code which have been copied into the Hytera source code are themselves a substantial part of the relevant Motorola work from which the copying has taken place. (d) Finally, in relation only to the importation case, Hytera submits that Motorola has failed to make good the knowledge element that that case has as one of its necessary elements. It accepts that if one gets to this part of the case, it will essentially have been found that the ex-Motorolans deliberately copied a substantial part of the Motorola works into the Hytera source code. However, it says that they did so without Hytera's authority and therefore that the knowledge element is lacking. Legal Mechanics of Motorola's Importation and Downloading Cases INTRODUCTION 1174 Both Motorola's source code and Hytera's object code are, subject to minor debates to which I will return, 'computer programs' within the definition in s 10 of the Copyright Act: computer program means a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. 1175 Section 10 also states that a computer program is taken by the Act to be included in the concept of a 'literary work': literary work includes: (a) a table, or compilation, expressed in words, figures or symbols; and (b) a computer program or compilation of computer programs. 1176 It is not in dispute that Motorola owns the Australian copyright in its source code. Consequently, Motorola has the rights in relation to that source code which are conferred by s 31(1)(a): 31 Nature of copyright in original works (1) For the purposes of this Act, unless the contrary intention appears, copyright, in relation to a work, is the exclusive right: (a) in the case of a literary, dramatic or musical work, to do all or any of the following acts: (i) to reproduce the work in a material form; (ii) to publish the work; (iii) to perform the work in public; (iv) to communicate the work to the public; (vi) to make an adaptation of the work; (vii) to do, in relation to a work that is an adaptation of the first‑mentioned work, any of the acts specified in relation to the first‑mentioned work in subparagraphs (i) to (iv), inclusive; … 1177 That provision must be read with s 14(1) which provides: 14 Acts done in relation to substantial part of work or other subject‑matter deemed to be done in relation to the whole (1) In this Act, unless the contrary intention appears: (a) a reference to the doing of an act in relation to a work or other subject‑matter shall be read as including a reference to the doing of that act in relation to a substantial part of the work or other subject‑matter; and (b) a reference to a reproduction, adaptation or copy of a work shall be read as including a reference to a reproduction, adaptation or copy of a substantial part of the work, as the case may be. … 1178 The effect of s 14 is to put a substantial part of Motorola's source code on the same footing as if it were all of Motorola's source code. 1179 At a high level of abstraction, Motorola puts its infringement case on three bases. First, it alleges that the Hytera object code was a reproduction of a substantial part of the Motorola source code. Secondly, it alleges that the Hytera object code was an adaptation of a substantial part of the Motorola source code. Thirdly, it alleges that Hytera communicated to the public a substantial part of the Motorola source code by making the Hytera object code available for download and copying in Australia and that persons in Australia had in fact done so. Reproduction and Adaptation 1180 The rights to reproduce, communicate and adapt a substantial part of Motorola's source code are the exclusive rights conferred on Motorola, respectively, by ss 31(1)(a)(i), (iv) and (vi), combined with s 14. It is an infringement of those rights to do any of the acts described in them without the licence of Motorola. Section 36(1) provides: 36 Infringement by doing acts comprised in the copyright (1) Subject to this Act, the copyright in a literary, dramatic, musical or artistic work is infringed by a person who, not being the owner of the copyright, and without the licence of the owner of the copyright, does in Australia, or authorizes the doing in Australia of, any act comprised in the copyright. 1181 The facts which Motorola alleges constituted the reproduction and adaptation of a substantial part of its source code are acts which are all alleged to have occurred in China. It was in China that Motorola alleges that Hytera's DMR engineers copied tracts of Motorola's source code into Hytera's own source code, and it was in China that the evidence shows that Hytera compiled that source code into object code. It was not disputed that the installation of Hytera's object code into its DMR devices in the form of firmware also took place in China. 1182 Those acts could not constitute an infringement of Motorola's Australian copyright. The rights of reproduction and adaptation conferred by ss 31(1)(a)(i) and (vi) are rights to perform those acts in Australia and, by s 4, all external territories. Consequently, Hytera could not infringe them by carrying out acts of reproduction and adaptation in China. It may well have infringed Motorola's Chinese copyright in its source code in doing so, but that is not an issue in the present proceeding. 1183 On the face of it, therefore, the infringement provision, s 36(1), is not engaged. Motorola's answer to this is to rely upon the importation provision in s 37(1): 37 Infringement by importation for sale or hire (1) Subject to Division 3, the copyright in a literary, dramatic, musical or artistic work is infringed by a person who, without the licence of the owner of the copyright, imports an article into Australia for the purpose of: (a) selling, letting for hire, or by way of trade offering or exposing for sale or hire, the article; (b) distributing the article: (i) for the purpose of trade; or (ii) for any other purpose to an extent that will affect prejudicially the owner of the copyright; or (c) by way of trade exhibiting the article in public; if the importer knew, or ought reasonably to have known, that the making of the article would, if the article had been made in Australia by the importer, have constituted an infringement of the copyright. 1184 This provision erects two inquiries. The first is hypothetical: if Hytera had manufactured its DMR devices in Australia including, relevantly, installing its object code on the devices in the form of firmware, would this have constituted an infringement? The second, which arises only if the first is answered in the affirmative, is whether Hytera knew this or ought reasonably to have known this. 1185 So far as the first question is concerned, Motorola relies on its exclusive rights to reproduce or make an adaptation of a substantial part of its source code conferred by ss 31(1)(a)(i) and (vi) and s 14. Communication 1186 Motorola's case in relation to communication involves no territorial complexities for the acts of communication in question are not disputed to have taken place in Australia. 1187 It is useful to consider Motorola's reproduction, adaptation and communication cases separately as they raise different issues. REPRODUCTION 1188 Seen through the prism of the importation provision, Motorola has the exclusive right to reproduce a substantial part of its source code. The word 'reproduce' is not defined in the Copyright Act but it is not in dispute that for there to be a reproduction there must be both: (a) objective similarity between a substantial part of the original work and the alleged reproduction; and (b) a causal connection between the works such that the original work must have been copied. Hytera accepts that if objective similarity is made out then copying is conceded. 1189 Most of Motorola's source code is written in a high level computing language known as C++ whereas Hytera's object code is written in machine code. As a matter of fact, it is not possible for Hytera's object code to be objectively similar to Motorola's source code because they are entirely different. Not only are they textually alien to each other but the conceptual frameworks upon which each rests are chalk and cheese. In that regard, reference may be made to the example given above about the difference between an architect's plans for an office tower and the complete set of instructions given to the various tradespersons who actually put the office tower together. The latter is clearly a function of the former, no doubt. But in no universe of discourse can a large number of such low level instructions be seen to be a reproduction of the architect's plans. 1190 It follows that, unaided by statutory intervention, Hytera's object code cannot involve a reproduction of Motorola's source code. This problem was recognised by the Copyright Law Review Committee ('the Committee') in its 1994 report entitled 'Computer Software Protection'. As the Committee noted at that time (at §6.71), the approach which had been taken to the problem in the industry was to treat the object code which was compiled from source code as an adaptation of the source code. It also observed that there was a real difficulty in this approach (at §6.72) which lay in the terms of s 31(1)(a)(vii) (set out above). The import of that provision is that once a work is adapted by its owner, the owner of the copyright in the work and its adaptation has no entitlement to prevent a further adaptation of that adaptation. This follows because the inclusion in s 31(1)(a)(vii) of sub-paras (i) to (iv) does not include sub-para (vi), and it is sub-para (vi) which is the right to make an adaptation of the work. 1191 In the context of computer programs, this curiosity therefore entailed that if object code was treated as an adaptation of source code, then the original author of the source code could not prevent another person from making a further adaptation of the object code. This was thought to be unsatisfactory. 1192 The Committee therefore recommended that it would be appropriate to put computer programs on the same footing as some of the other kinds of activity which, apart from the Copyright Act, would be treated as adaptations: §§6.74-76. The best known of these examples concerns the relationship between a book and a film. Apart from the specific provisions of s 21 (to which I will shortly turn), if the owner of the copyright in a book made a film from that book, this would be an adaptation. As such, it too would suffer from the same problem just described, that is to say, the owner of the copyright in the book and the film made from it, would be unable to prevent any further adaptation of the film. To overcome that problem, films made from books were deemed to be reproductions rather than adaptations. This lifted them out of s 31(1)(a)(vi) and put them in s 31(1)(a)(i) so that the adaptation problem was eliminated. A similar approach was taken to artistic works in two dimensions. The rendering of a two-dimensional artistic work into three dimensions would, apart from s 21, be an adaptation and therefore liable to be further adapted outside the control of the copyright owner in the two-dimensional artistic work. These works (and three-dimensional works rendered into two dimensions) were also lifted out of s 31(1)(a)(vi) and were deemed to be reproductions by s 21. 1193 The Committee therefore recommended amendments to bring about a similar alteration to the position of authors of computer code by deeming compilations and decompilations of source code and object code respectively to be reproductions. This was done for the explicit purpose of extending the rights of the owner of the copyright in the initial code. This recommendation was taken up by Parliament which, by means of the Copyright Amendment (Digital Agenda) Act 2000 (Cth), inserted s 21(5) into the Copyright Act. The Explanatory Memorandum accompanying its introduction recited the Committee's report (at [36]) and indicated that the purpose of the amendment was to ensure that object code compiled from source code was taken to be a reproduction. 1194 Section 21 now provides: 21 Reproduction and copying of works and other subject‑matter (1) For the purposes of this Act, a literary, dramatic or musical work shall be deemed to have been reproduced in a material form if a sound recording or cinematograph film is made of the work, and any record embodying such a recording and any copy of such a film shall be deemed to be a reproduction of the work. (1A) For the purposes of this Act, a work is taken to have been reproduced if it is converted into or from a digital or other electronic machine‑readable form, and any article embodying the work in such a form is taken to be a reproduction of the work. Note: The reference to the conversion of a work into a digital or other electronic machine‑readable form includes the first digitisation of the work. (2) Subsections (1) and (1A) apply in relation to an adaptation of a work in the same way as they apply in relation to a work. (3) For the purposes of this Act, an artistic work shall be deemed to have been reproduced: (a) in the case of a work in a two‑dimensional form—if a version of the work is produced in a three‑dimensional form; or (b) in the case of a work in a three‑dimensional form—if a version of the work is produced in a two‑dimensional form; and the version of the work so produced shall be deemed to be a reproduction of the work. (4) The last preceding subsection has effect subject to Division 7 of Part III. (5) For the purposes of this Act, a computer program is taken to have been reproduced if: (a) an object code version of the program is derived from the program in source code by any process, including compilation; or (b) a source code version of the program is derived from the program in object code by any process, including decompilation; and any such version is taken to be a reproduction of the program. (6) For the purposes of this Act, a sound recording or cinematograph film is taken to have been copied if it is converted into or from a digital or other electronic machine‑readable form, and any article embodying the recording or film in such a form is taken to be a copy of the recording or film. Note: The reference to the conversion of a sound recording or cinematograph film into a digital or other electronic machine‑readable form includes the first digitisation of the recording or film. 1195 Motorola's reproduction case turns on s 21(5). Its argument is as follows: (a) Hytera's source code reproduces a substantial part of Motorola's source code; (b) Hytera's object code is compiled from Hytera's source code; (c) by s 21(5), Hytera's object code is taken to be a reproduction of Hytera's source code; (d) a reproduction of something which reproduces one or more substantial parts of Motorola's source code itself reproduces one or more substantial parts of Motorola's source code; and (e) since Hytera's object code is taken to be a reproduction of Hytera's source code (proposition (c)) and since Hytera's source code reproduces one or more substantial parts of Motorola's source code (proposition (a)), it follows from proposition (d) that Hytera's object code reproduces one or more substantial parts of Motorola's source code. 1196 As I will shortly explain, I do not accept that this syllogism solves the factual problem that Hytera's object code cannot be objectively similar to Motorola's source code. That factual hurdle can only be overcome by a deeming provision and Motorola does not seek to apply the only available deeming provision, s 21(5), to its own source code. Even if this problem did not exist, the use to which Motorola seeks to put the deeming in s 21(5) is not authorised by the terms of the provision. 1197 Hytera denies that s 21(5) operates as Motorola suggests. It says that s 21(5) has no work to do in this case unless it be suggested that Hytera compiled its object code from Motorola's source code. In such a case, Hytera agrees that s 21(5) would operate to deem Hytera's object code to be a reproduction of Motorola's source code. As such, the reproduction would answer directly the statutory act described in s 31(1)(a)(i) ('to reproduce the work in a material form') and infringement would ensue. However, so submitted Hytera, where it made its own intermediate source code, the effect of s 21(5) was simply to deem the object code compiled from it to be a reproduction of that intermediate source code, and not Motorola's source code. As such, substituting that reproduction into s 31(1)(a)(i) led nowhere since no one was alleging that Hytera had infringed the copyright in its own source code. Section 21(5) Is Not Sufficient 1198 For present purposes, the important point is that s 21(5) was enacted precisely because object code cannot be objectively similar to, and therefore cannot involve a reproduction of, source code. 1199 Motorola faces the same problem which led to the introduction of s 21(5). That is the fact, as I have already observed, that it is in the nature of object code that it will never involve a reproduction of any source code. Motorola's basal contention that Hytera's object code reproduces a substantial part of its source code confronts this hurdle at the outset. This is a factual problem derived from the real world. The only way through it is to establish by some legal means a relationship between the Hytera object code and the Motorola source code. However, s 21(5) establishes only one such relationship and that is between the object code and the source code from which it has been compiled. Without a provision such as s 21(5) operating directly on the relationship between the Hytera object code and the Motorola source code, the factual reality remains that the Hytera object code cannot involve a reproduction of the Motorola source code because it is not objectively similar. 1200 The deficiency in Motorola's argument lies in the absence of any explanation of how that problem is to be solved. Regardless of how far the deeming in s 21(5) is to be taken, Motorola does not contend that s 21(5) operates on its source code. As such, the fundamental impossibility of object code being objectively similar to source code remains. How Far Does the Deeming in s 21(5) Go? 1201 Even if that problem did not exist, Motorola's deployment of s 21(5) is beyond its terms. The difference between Hytera and Motorola on this issue lies in the effect that the deeming brought about by s 21(5) has. Hytera's position assumes (although I have made more explicit), that the deemed reproduction has to have some connection with an occurrence of reproduction within the machinery of the statute. Motorola, on the other hand, does not seek to use the deemed reproduction wrought by s 21(5) to answer some question posed by the statute turning on the concept of reproduction. Rather, it seeks to use it as a factual proposition: because the Hytera object code reproduces the Hytera source code (as a result of the deeming in s 21(5)) and because the Hytera source code reproduces a substantial part of the Motorola source code, the Hytera object code reproduces a substantial part of the Motorola source code. 1202 There is no doubt that s 21(5) is a deeming provision but it may also be described as creating a statutory fiction. It deems one thing – object code compiled from particular source code – to be something which it is not – a reproduction of that source code. 1203 Of course, not every deeming provision involves a statutory fiction. A provision which says that a person over the age of 18 is deemed to be an adult generally involves no fiction at all and is better thought of as declaratory of a conclusion. In what follows, care should be taken to distinguish these two different kinds of deeming provisions. 1204 It is established that statutory fictions are to be construed strictly and only for the purposes for which they are resorted to: see, for example, Commissioner of Taxation v Comber (1986) 10 FCR 88 at 96 ('Comber'). Or, to put it another way, the fiction must be confined to its purpose and not permitted to serve purposes for which it was not intended. The Full Court has rejected attempts to use statutory fictions erected for one explicit legal purpose as factual propositions for another. Comber is an example. Simplifying the facts in that case somewhat, the then s 109 of the Income Tax Assessment Act 1936 (Cth) deemed a payment made by a company on the retirement of a director to be paid by the company out of profits as a 'dividend paid by the company'. It did not say that the dividend was taken to have been paid to the person receiving it as a dividend as if they were a shareholder. The company paid a lump sum to a former director on his retirement. The issue was whether the lump sum was to be taxed in his hands as income because it was a dividend or as a capital lump sum paid on retirement. 1205 The effect and the purpose of the deeming was to prevent the payment being deductible in the hands of the company. This followed from the received wisdom that the payment of a dividend is not deductible in the hands of the company paying it. 1206 The Commissioner sought to assess the former director who received the payment on the basis that he had received the payment as a dividend. The Full Court rejected this attempt and concluded that the payment was in the nature of a capital sum in the director's hands. The Full Court declined to allow the deeming provision to be used beyond the purpose for which it existed which was to prevent the company claiming a deduction. In his reasons, Fisher J explained the approach to statutory fictions this way: I find the Commissioner's construction unacceptable. In my opinion deeming provisions are required by their nature to be construed strictly and only for the purpose for which they are resorted to: Re Levy; Ex parte Walton (1881) 17 Ch D 746 per James LJ at 756. It is improper in my view to extend by implication the express application of such a statutory fiction. It is even more improper so to do if such an extension is unnecessary, the express provision being capable by itself of sensible and rational application. This is precisely the position in the section in question. The private company, having been denied a deduction in respect of the amount of the excess distribution, should fairly be entitled to have that amount taken into account as an after tax distribution in determining whether it has made a sufficient distribution of its profits. 1207 Both Bowen CJ and Lockhart J rejected the use of the deeming provision to characterise the nature of the receipt in the hands of the taxpayer. At p 90, Bowen CJ pointed out that to deem the payment made as having been paid as dividend by the company said nothing as to what the payment was in the hands of the recipient. And at p 99, Lockhart J put it this way: A distribution of the kind referred to in s 108 or s 109 is deemed to be a dividend paid by the company. It is true that neither section in terms says that the dividend is deemed to be paid by the company to the shareholder, director or other person although that consequence is necessarily recognised in s 108(2) in relation to the deemed dividend for which s 108(1) makes provision. Also, for every payment there must be a payer and a payee. In my opinion the deeming provision operates to deem the payment to be a dividend paid by the company and a dividend received by the recipient. Of course, it does not follow that the character of the payment in the hands of the recipient is clothed with the nature of income. All the deeming provision does is to deem a payment to have been made. It says nothing to characterise the receipt in the hands of the recipient. 1208 In Australian Competition and Consumer Commission v PT Garuda Indonesia Ltd (Remedies) [2019] FCA 786; 370 ALR 637 ('Garuda'), s 45A(1) of the then Trade Practices Act 1974 (Cth) (now the Competition and Consumer Act 2010 (Cth)) deemed, inter alia, price fixing agreements to have the purpose of substantially lessening competition 'for the purposes of s 45(2)': at [101]. Section 45(2) prohibited entry into agreements having the purpose or effect of substantially lessening competition. It was not in dispute that s 45A(1) had been enlivened. The Commission submitted that in imposing a civil penalty on Garuda, the Court should proceed on the basis that as a matter of fact, competition had been substantially lessened by the impugned conduct. The Court rejected this use of the deeming finding that 'the deeming brought about by s 45A occurs only for the purposes of s 45(2) and is not to be seen as informing any factual state of affairs': Garuda at [103]; see also Howard v Commissioner of Taxation [2012] FCAFC 149; 206 FCR 329 at [48]; Muller v Dalgety & Co Ltd (1909) 9 CLR 693 at 696 per Griffith CJ. 1209 In this case, s 21(5) makes clear that the purpose for which the statutory fiction in it has been enacted is '[f]or the purposes of this Act'. Where the Act in terms deals with a work which is source code, s 21(5)(a) deems object code compiled from that source code to be a reproduction of it. 1210 One obvious way the Act deals with source code is, as I have mentioned, in s 31(1)(a)(i) itself. The rights comprising the copyright in a literary work (including a computer program) include the right 'to reproduce the work in a material form'. The effect of s 21(5) is therefore to confer on the owner of the copyright in source code the exclusive right to compile it into object code since the object code is taken to be a reproduction of the source code. The statutory fiction wrought by s 21(5) feeds directly into the word 'reproduce' in s 31(1)(a)(i). 1211 Where a person compiles another person's source code to create object code, the same effect may be seen. The compilation of the object code from the other's source code is taken by s 21(5) to be a reproduction of that source code. Thus the act of compiling the object code from another's source code constitutes an infringement under s 36(1) since the act of compilation into object code is the doing of an act comprised within the copyright in s 31(1)(a)(i). 1212 In this case, Motorola seeks to use the deeming in s 21(5) to demonstrate as a fact that Hytera's object code is a reproduction of the Hytera source code. Since it is a fact, Motorola argues that the additional fact that the Hytera source code reproduces a substantial part of the Motorola source code entails, as a fact, that the Hytera object code reproduces one or more substantial parts of the Motorola source code. At no point in this contention does the statutory fiction in s 21(5) get used, as the opening words of the provision require, '[f]or the purposes of this Act'. The statutory pegs on which Motorola's importation infringement case turns are, as I have explained above, s 31(1)(a)(i) combined with ss 14 and 36. These are used to conclude that a reproduction by Hytera of one or more substantial parts of the Motorola source code constitutes an infringement of the copyright in Motorola's source code. Only s 31(1)(a)(i) in that argument uses the term 'reproduce'. It is apparent at that juncture in its argument that Motorola does not rely on s 21(5). This is because s 31(1)(a)(i) refers to a right of Motorola's to reproduce the Motorola source code in a material form. The application of s 21(5) to that right leads to the orthodox conclusion that Motorola also has the exclusive right to compile object code from its own source code. An infringement of that right under s 36(1) would require an allegation that Hytera had compiled its object code from Motorola's source code. If such an allegation were made (and proved), it would follow that the deeming provision was enlivened and infringement would be established. 1213 What Motorola therefore seeks to use s 21(5) for, is its factual contention that the Hytera object code reproduces a substantial part of Motorola's source code. In my view, that purpose is not one of the 'purposes of the Act' to which the opening words of s 21(5) delimit its use. 1214 For those two cumulative reasons I reject Motorola's approach to s 21(5). Motorola points to no legal mechanism by which the impossibility of its source code being reproduced in Hytera's object code may be overcome. The only available provision which establishes a relationship between object code and source code, s 21(5), applies to Hytera's object code and source code, not Hytera's object code and Motorola's source code. Further, even if that were not a problem, Motorola seeks to use the deeming in s 21(5) as a factual integer in its argument which involves a use beyond the purposes the provision prescribes. 1215 For completeness, Motorola did not allege that the Hytera source code which had been copied from the Motorola source code was Motorola's source code. Instead it was explicit in referring to a chain of copying involving two steps, copying and compilation. Had it been alleged that what was compiled by Hytera was in fact Motorola's source code, the above problem would be avoided because s 21(5) would then operate directly on the Motorola source code. 1216 There are, however, conceptual pitfalls with such an allegation which may explain why it was not pursued. The first of these is that such a case locates the act of infringement in the act of compilation. It therefore would require Motorola to use the Hytera source code not as the target of an infringement allegation but instead as an instantiation of Motorola's own source code. As the suit was constructed, Motorola identified the source code on which it sued as being in particular directories on a particular computer. It was not alleged that Motorola's source code included the source code from which Hytera had compiled its object code. A suit of the kind under discussion, on the other hand, would need precisely that allegation to work. 1217 Secondly, if such an allegation were made it would involve the proposition, controversial perhaps, that an unauthorised reproduction of a work belongs in law to the owner of the work. 1218 Thirdly, the assertion of an entitlement to sue on Hytera's own source code may well involve questions of waiver. For example, could Motorola allege simultaneously that it owned Hytera's source code and, in the same breath, say that Hytera had infringed its copyright by copying Motorola's source code into its own source code? 1219 In any event, it is not necessary to pursue these potentially quite difficult matters further. Motorola did not make such an allegation and could not make such an allegation due to the way in which it particularised the source code on which it sued. ADAPTATION 1220 In the alternative, Motorola alleges that the Hytera object code was an adaptation of the Motorola source code: 3FASOC at §31D(b). Section 10 defines an adaptation in relation to a computer program in these terms: adaptation means: … (ba) in relation to a literary work being a computer program—a version of the work (whether or not in the language, code or notation in which the work was originally expressed) not being a reproduction of the work; 1221 For the reasons I have given, the Hytera object code is not a reproduction of the Motorola source code. Insofar as computer programs are concerned, for an adaptation to be present only copying is required. Unlike the concept of reproduction which requires objective similarity, the adaptation right is unconcerned with the computer language in which the accused object code is expressed. In Data Access Corporation v Powerflex Services Pty Ltd [1999] HCA 49; 202 CLR 1 at [109] ('Data Access'), the High Court said that by including the definition: Parliament was concerned to ensure that the different languages in which a computer program may be expressed did not provide a means by which copying could occur and infringement be avoided on the ground that the expression in the new language was not a "reproduction". 1222 Thus the fact that Hytera's object code is in machine code whilst Motorola's source code is in C++ does not provide a shield against an allegation that an adaptation has been made. There remains the question of whether Hytera's object code may be said to be a 'version' of Motorola's source code. Motorola made no submissions about the meaning of the word 'version' and Hytera did not refer to the requirement. In Data Access, the Full Court had concluded that 'version' meant a 'particular form or variant of anything': at [105]. Apart from indicating that the form or variant had to be one which involved copying, the High Court did not demur from this view. 1223 The question therefore is whether the Hytera object code may be seen as a form or variant of the Motorola source code. If one arrives at the conclusion, as Motorola suggests the Court should, that the Hytera object code contains a copy in machine language of a substantial part of the Motorola source code then, in my view, it would be a form or variant of that code. The fact that it may contain code which was not copied from Motorola's source code does not detract from it being a version of that source code. CONNECTION WITH IMPORTATION 1224 Assuming that Motorola's allegation that a substantial part of its source code has been copied into Hytera's object code via Hytera's source code is correct, I do not accept that Hytera would have infringed Motorola's reproduction right in s 31(1)(a)(i) if it had manufactured the devices in Australia including by installing the object code on the devices. On the other hand, I do accept that it would have infringed Motorola's adaptation right in s 31(1)(a)(vi) in doing so. Therefore, in principle, I accept that Motorola's importation infringement case can work. On its face it gives rise to two issues and there are, in addition, a number of liminal issues which are raised by Hytera in its defence. I return to the issues raised in Hytera's defence in the next section. For present purposes, it may be noted that if those issues are resolved against Hytera, Motorola will still need to demonstrate on the facts that: (a) a substantial part of the Motorola source code was copied into the Hytera source code which was then compiled into the Hytera object code; and (b) Hytera knew or ought reasonably to have known that the installation of its object code on its devices, if done in Australia, would have involved an infringement of Motorola's copyright in its source code. COMMUNICATION OF THE OBJECT CODE AND THE MAKING OF COPIES OF THE OBJECT CODE 1225 It appears to have been the case that Hytera made versions of its object code available for download in Australia to permit dealers (and perhaps others) to download firmware for their devices. Versions of the firmware were downloaded. That involved the communication of the object code by Hytera to the person who downloaded it and the making of copies of that object code in a material form. Leaving aside the precise facts by which these allegations are pursued, the mechanics are straightforward in light of the above conclusions. Motorola not only had the exclusive right to make an adaptation of its source code but also, by s 31(1)(a)(vii), the right to reproduce that adaptation and communicate it to the public. Consequently, by making the Hytera object code available for download in Australia and by transferring it electronically to persons who sought to download it in Australia, Hytera communicated the adaptation within the definition of 'communicate' under s 10: communicate means make available online or electronically transmit (whether over a path, or a combination of paths, provided by a material substance or otherwise) a work or other subject‑matter, including a performance or live performance within the meaning of this Act. 1226 Motorola pursued that case against Hytera. It also said that the Second Respondent, Hytera's Australian subsidiary, had itself made copies of the object code. Again, this involves an infringement of the rights in ss 31(1)(a)(vi) and (i) referring back to s 31(1)(a)(vii). Motorola also pursued a case based on authorisation under s 36(1). Again, at the mechanical level these are no different. CONCLUSION ON OVERALL MECHANICS OF MOTOROLA'S INFRINGEMENT CASE 1227 I am satisfied that Motorola's infringement case is, in principle, capable of working. Substantial Part 1228 Motorola alleges that a substantial part of each of its 11 works has been copied by Hytera into the Hytera source code from which it then compiled the object code installed as the firmware in its devices. As I have explained in the previous section, if this allegation is made good, it will establish that the Hytera object code is an adaptation of a substantial part of the Motorola source code. PRINCIPLES 1229 Before turning to the relationship between the Hytera and Motorola source codes, it is useful to say something about what constitutes a substantial part of a computer program. First, in deciding whether computer code copied from part of a computer program is a substantial part of that computer program, it is the quality of the work taken, not the quantity, which is critical: JR Consulting & Drafting Pty Ltd v Cummings [2016] FCAFC 20; 116 IPR 440 at [267] ('JR Consulting'). Secondly, in carrying out that assessment, the essential or material features of the computer program should be ascertained by considering the originality of the part allegedly taken: Data Access at [84]. Thirdly, the analysis will include a comparison of the codes (JR Consulting at [269]) as well as a consideration of the code's structure: Data Access at [85]. Functionality is not protected. 1230 In considering whether the part taken is a substantial part of the computer program, it is necessary to conclude that the part taken is original. If the author would not have copyright in the part taken standing alone, then the part copied will not be a substantial part: IceTV Pty Ltd v Nine Network Australia Pty Ltd [2009] HCA 14; 239 CLR 458 at [37] ('IceTV'). This entails that if the part copied did not originate with the author then it cannot be a substantial part: IceTV at [37]. But what if the author copied the part in question from an earlier work of their own? IceTV does not address that question directly and it is that question that presently arises. 1231 As I explain later in these reasons, Motorola's 11 works are the result of the revision of pre-existing software. That process of revision has resulted in code which contains parts which are new but, also, parts which are reused from the earlier code. Picking up on the question posed at the end of the last paragraph, Hytera submits that, in that circumstance, Motorola must prove that the parts which Hytera has allegedly taken from the Motorola source code were original in the version upon which it sues and are not merely reproductions of already existing code. 1232 I do not accept this submission for a number of reasons. The 11 works are the result of a substantial process of revision and refinement of the earlier code. As such, each of the 11 works is an original work in its own right: JR Consulting at [278]–[279]. Hytera submits that that conclusion in JR Consulting was concerned with the question of subsistence and not substantial part in the context of infringement: HCS(C) Mod II at [141]. Although there was a question of infringement in that case, it did not involve the issue which now arises. What was taken in JR Consulting was the entire suit of the software, not a part of it. The question of whether a non-substantial part of that software had been taken because it originated in an earlier version was not in contest. One reason for this is that the plaintiff sued on each version of the software so that the argument would have been futile. 1233 I therefore accept that JR Consulting does not directly answer Hytera's submission set out above at [1231]. The correctness of the submission must therefore be considered on its own terms. 1234 Where a work has been created, in part, from a pre-existing work there are, in my view, two situations may be usefully distinguished from each other: (a) a work which reproduces extracts from another work; and (b) a work which builds on earlier versions of itself. 1235 Anthologies are a well-known example of the former. The copying of such an anthology will, as Mummery LJ (with whom Rix LJ agreed) observed, 'usually be word-for-word copying of the pieces anthologised, but that verbatim copying of the anthologised pieces is irrelevant to infringement of copyright in the anthology as such being an original work (a literary compilation)': Baigent v Random House Group Ltd [2007] EWCA Civ 247; 72 IPR 195 at [142]; see also the position of Hazlitt's Selected Essays, referred to in Cambridge University Press v University Tutorial Press (1928) 45 RPC 335 at 343-344, and the transcripts of the various proceedings against Oscar Wilde which appeared in the plaintiff's 1948 book, 'The Trials of Oscar Wilde', in Warwick Film Productions Ltd v Eisinger [1969] 1 Ch 508 at 525, 533-534. These three cases were each cited in IceTV at [37] at fn 70 as authority for the proposition that 'where the part reproduced did not originate with the author, so that the author would not have had copyright in the part standing alone, the part reproduced will not be a substantial part'. There was no issue in IceTV as to whether the slivers of program information in that case were not to be thought original because they had been copied from elsewhere. I do not read the statement in IceTV at [37] as saying something in either direction about the position of works which have been derived from earlier versions of themselves by a process of gradual development. The cases referred to are not such cases and there was no issue in IceTV about that question. 1236 By contrast, examples of the works which involve development from earlier versions of themselves include the relationship between a final version of a play and earlier drafts, and the successive editions of a legal text where each edition involves careful revision, reviewing and settling of the text: see Ricketson S, The Law of Intellectual Property: Copyright, Designs and Confidential Information at [7.103]-[7.104], cited with approval in JR Consulting at [277]-[279]. 1237 In the latter case, whilst the text may in some portions remain unchanged, this does not mean it was not reviewed. In the course of its production, the fact that part of the text remains unchanged will reflect the work of the author in checking to see that the law has not changed. Thus the fact that no alteration occurs does not mean that no effort was expended. Consequently, leaving to one side the precise status of effort in the context of origination as that concept is used in infringement, it has been accepted that such a work, as a whole, is original even though it may contain tracts of text identical to the previous edition. 1238 It was that principle which was applied by the Full Court in JR Consulting to conclude that successive editions of software were each original works in their own right. 1239 In my view, the implications flowing from the reasoning in JR Consulting do dispose of Hytera's submission although, I would accept, those implications are not part of the ratio decidendi. The conclusion reached by the Full Court was that the fresh edition was an original work in its own right. By that statement I do not apprehend that the Full Court was saying that a software revision stood in the same position as an anthology of poems. In particular, there is no support in its reasons for the idea that what was original about each new version of the software was the careful choices which had been made about the selection and ordering of the pre-existing code: cf. Hazlitt's Selected Essays. 1240 The Full Court's conclusion seems to me to have been wider and to have included the idea that the review and revision of the code, whether resulting in new code or in parts of the code being left unchanged, was an act of origination under the Copyright Act and that the product of that act of origination was itself an original work. I respectfully agree with this analysis. In the case of successive editions of a work where each involves revision and refinement, what is taking place is different to the collecting of materials which are selected precisely because they are not original. The parts of such a successive edition which are textually identical to the previous edition are original in the requisite sense and, provided they are large enough to constitute a literary work (i.e. they are not fragmentary) are, in the requisite sense, original. 1241 In the case of a legal text, for example, the fact that the text of the 3rd edition in a particular paragraph is the same as a paragraph in the 2nd edition does not mean that they stand for the same thing, nor is the effort of the editors which has gone into them the same. One is a statement about the law which was obtained at the time of the 2nd edition, the other is about the state of the law as it stood at the time of the 3rd edition. Whilst textually identical, it is erroneous to consider their originality divorced from their temporal context. 1242 In a similar vein, the fact that the final edition of a play shares 80% of its text with the draft which preceded it does not entail, for infringement purposes, that that 80% is not original. The changes which are made to the 20% do not happen in isolation but must be considered against the compositional harmony and coherence of the whole play. Actual work is involved in the decision to leave parts unchanged. So viewed, it is not correct to regard those parts which have not been altered as unoriginal for infringement purposes. As Professor Ricketson points out (supra), this is the accepted position in relation to such works. 1243 In my opinion, a similar approach ought to be taken to computer programs. Like a play, the program as a whole must continue to work coherently. Changes in one part of the code necessitate checking that, with those modifications, the code as a whole continues to work. 1244 Any other conclusion in relation to successive versions of software leads to the chaotic situation which Hytera's submission in this case necessarily entails. It argued that Motorola was required to show that each part of the source code it sued on originated in the version upon which it sued. It is true that Motorola could have met this challenge by adding to the list of works upon which it sued every iteration of its software so that Hytera's challenge ultimately led nowhere. 1245 There are two reasons why such an outcome ought not to be tolerated. The first is practical: it would turn every suit for infringement of a computer program into a suit for infringement of every iteration of that software back to its earliest origins. In the case of programs with a long history, for example Windows, this may reach back many decades and involve a very large number of iterations. The same approach to plays or novels would require every draft to be sued on. 1246 The second problem concerns the implications of that practical problem: if it becomes necessary to consider each incremental adjustment to the computer code, the question of whether each alteration was itself too insubstantial to constitute an original work would arise. Taken to its logical extremity in the case of computer code, one might well end up with the conclusion that no infringement could be established except in the case of the first version. The accretion of a large number of alterations, each insubstantial in itself, would lead to a program substantially different to the original. JR Consulting would require the conclusion that copyright inhered in that work, but no infringement of that copyright could be established except to the extent that the original release was present in the final version. Each of the successive updates would, on this hypothesis, be insufficient to count as original. 1247 An intermediate form of that problem would exist where some of the updates were substantial enough to constitute original works in their own right but some were not. In that situation, whilst copyright would inhere in the work as a whole, an infringement suit would fail in relation to the latter elements. 1248 This problem was the bubbling cauldron into which the Full Court peered in JR Consulting at [275]. I do not accept, as Hytera submitted, that to proceed otherwise would be to grant a perpetual monopoly on those parts of the code which remained unchanged. Here the thinking was that since each piece of reproduced code in the revised software attracted a fresh copyright, the monopoly might never end. I do not accept this submission for two reasons. First, the present question about originality takes place in the context of infringement: is the part taken original? Hytera's submission about the duration of the monopoly concerns the question of originality in the context of subsistence. JR Consulting answers the subsistence question and therefore the question of the duration of the monopoly. The duration of the monopoly does not arise again under the guise of the question of originality in the infringement context. Secondly, the answer to the submission is the one already given: there can be no objection to this where each revision constitutes a fresh work. 1249 Contrary to Hytera's submission, a line of reasoning which leads to computer software litigation, already difficult and challenging at the best of times, being conducted as Hytera suggests is one which would require before its adoption only the most anxious hesitation. It is an approach which would dramatically increase the cost and delay involved in litigation of this kind as well as serving as a drain on the public resources of the courts. Anyone who examines the particulars of copyright infringement in this case will understand just how complex this litigation is even where it is based on just three suites of software. As those particulars make clear, the 11 works are made up of multiple components spread across thousands of files in hundreds of directories. To add into that picture, the ancestors of each file would produce an object of deep complexity. One might tolerate such an outcome if there were some discernible public good served by it, however, I am unable to discern any such a benefit. 1250 For the reasons I have given, therefore, I do not think that the law is as Hytera submits. Where successive updates of software are released and originality is conceded for the purposes of subsistence, an argument for infringement purposes that a substantial part of a particular version of the software has been taken, is not defeated by showing that the part in question derives from antecedent code. THE DEVELOPMENT OF MOTOROLA'S FIRMWARE 1251 Motorola led a great deal of evidence about the manner in which the 11 works were made. That evidence was directed to meeting Hytera's initial non-admission that copyright subsisted in the 11 works. At trial, Hytera abandoned that contention. On the question of subsistence, that abandonment was inevitable and was directly required by JR Consulting. It was at that point that Hytera then submitted that it had not been shown that a substantial part of the 11 works had been taken because it had not been shown that they had not been copied from earlier iterations. 1252 Part of my reasoning above has turned on the proposition that the 11 works were the result of revision and review of earlier works. I did not apprehend that this proposition was contested by Hytera. Its point was the narrower one that the process of review and revision involved reproduction of tracts of pre-existing code. 1253 In fact, the 11 works are not merely the result of review and revision of earlier code. The 11 works in suit were part of the Matrix DMR project which began in 2003. Motorola had not manufactured DMRs before then and the Matrix program was designed to provide an advance over its existing analogue models. The 2005 DMR Standard was published two years before Motorola's devices came to market in early 2007. As such, the three sets of firmware (the Mobile Firmware, the Portable Firmware and the DSP Firmware) were an attempt to create an entirely new product range. As the reasoning above in relation to the patents in suit demonstrates, the creation of a system which gave effect to the kind of two timeslot TDMA system that the 2005 DMR Standard required was no simple undertaking. The difficulties it presented are significantly underscored, in my opinion, by the failure of the Hytera DMR program to surmount them. 1254 On the other hand, it may readily be accepted that much of what was contained in the software developed under the Matrix program was not brand new. Motorola had made radios before and it is evident that it did not begin its development of the firmware from scratch. For example, it had had to deal with the interface between the user and the device before so this was not a new problem. The Darwin Ergonomics Platform was not new when it was introduced into the DMR devices since it had been used in analogue devices. But neither was it the same. It had to be adapted to work in a new operating environment. It was not simply a case of copying the platform over without any changes. Indeed, the process of development took nearly four years. Hundreds of computer engineers worked on it. 1255 In that circumstance, I do not hesitate to conclude that the 11 works are themselves substantial original works. Whilst it is true that earlier code was reused, a better description would be to say that it was adapted to the new devices. As such, it clearly meets the requirement for careful revision and review flowing from JR Consulting. No doubt, this why Hytera did not ultimately contest the originality of the 11 works from the standpoint of subsistence. Objective Similarity and Substantial Part (General Observations) OVERVIEW 1256 Motorola is required to prove that the parts of the 11 works which it says have been taken by Hytera are: (a) objectively similar to identified portions of the Hytera source code; and (b) a substantial part of the relevant Motorola work. For the reasons already given, because Motorola relies on the adaptation right, it must also demonstrate that the Hytera object code (i.e. firmware) was compiled from the Hytera source code. Although there is no doubt that the Hytera object code was compiled from the Hytera source code, there is a dispute as to whether all of the Hytera source code found its way into the object code. Hytera submitted, based on the evidence of Mr Craig Brown, that some of the Hytera source code was discarded by the pre-processor prior to compilation and was not reflected in any actual object code. However, two issues arise from it. First, is it factually correct? Secondly, if it is, does it impact on the question of whether the Hytera object code is an adaptation of the Motorola source code? 1257 Not all of Hytera's source code is available. The parts of Hytera's source code which are available were made available through four successive tranches of discovery. Subject to the question of some files known as library files, this means that Motorola's infringement case is necessarily limited to the Hytera source code which is available. MOTOROLA'S PARTICULARISED CASE Identification of the 11 Works in Suit 1258 Motorola particularised its copyright infringement case in a document entitled 'Second Further Amended Particulars of Copyright Claim'. Annexed to that document was Confidential Annexure 1 which identified the 11 works in suit by reference to files located in particular directories on a particular standalone computer. Thus, to take the simplest example, the Darwin Ergonomics Platform was defined in this way: Motorola Work Directory Files 'Darwin' ergonomics platform epg_platform\code\source\ All files ltd_apps\code\applications\rs\common\core\ All files ltd_apps\code\applications\rs\mobile\core\ All files ltd_apps\code\applications\rs\portable\core\ All files 1259 In a formal sense, the reference to 'All files' sufficiently identifies the files in question although it does not do so in a practical sense. Since the Court does not have the standalone computer and neither party took me to a list of the files on it, the particulars do not in fact identify the 11 works. Consequently, in a practical sense, the particulars are not useful. In fact, it is only through the lens of the expert evidence that the meaning of the particulars can be discerned and, as will be seen, even that is not altogether satisfactory. To continue with the example of the Darwin Ergonomics Platform, the evidence of Mr Hayes (for Motorola) shows that there were in fact 289 such files (there is some question as to whether it was 279 or 289 files but this wrinkle may be passed over). Identification of the Parts Reproduced 1260 Motorola then particularised the way in which each of the 11 works 'identified' in Confidential Annexure 1 had been copied by Hytera in Confidential Annexure 2. Whilst Confidential Annexure 1 is structured by reference to the 11 works in suit, this is not true of Confidential Annexure 2. Instead, Confidential Annexure 2 identifies the copying allegedly carried out by Hytera of files within, on the one hand, the Portable and Mobile Firmware source code (in Table 2(a)) and, on the other, the DSP Firmware source code (in Table 2(b)). These are the three overarching works. 1261 However, the other eight subordinate works are all present within these three works. Those readers of Confidential Annexure 2 anxious to understand how Motorola alleges that Hytera copied a substantial part of the other eight subordinate works will, therefore, find themselves disappointed. The eight subordinate works are the Darwin Ergonomics Platform, EMT, Xlate, UIT, framerLib Library, L1 Timer, Framer, and the HAL Serial Buffer. The hierarchical arrangement of these works is illustrated above at [1163] but it is convenient to reproduce that illustration at this point (recalling that the HAL Serial Buffer is not part of the framerLib Library and is included under it only for schematic simplicity): Level 1 Mobile Firmware Portable Firmware DSP Firmware Level 2 Darwin Ergonomics Platform Darwin Ergonomics Platform framerLib Library Level 3 EMT EMT Framer Xlate Xlate L1 Timer UIT UIT HAL Serial Buffer 1262 Whilst it is true that Darwin Ergonomics Platform, EMT, Xlate and UIT are constituent elements of the Portable and Mobile Firmware source codes, and the framerLib Library, L1 Timer, Framer, and HAL Serial Buffer are constituent elements of the DSP Firmware source code, knowledge of this fact does not alleviate the inability of a reader of Confidential Annexures 1 and 2 to grasp how Motorola puts its case that a substantial part of each the eight subordinate works has been copied by Hytera. The reader cannot know what many parts of the works are because Confidential Annexure 1 frequently identifies the files as being all the files in a directory (and thereby does not identify them for the reasons already given). And even if the reader can surmount that handicap, Confidential Annexure 2 is not structured by reference to the eight subordinate works. In short, the formal presentation of Motorola's case is impenetrable. This has hampered me in understanding how Motorola puts its case. As will be seen, it has also hampered Motorola in understanding its own case. For example, although Motorola's submissions were clear that the HAL Serial Buffer was part of the DSP Firmware and not the Mobile and Portable Firmware, its own evidence showed that this is wrong and that it is actually part of all three. 1263 In form, Tables 2(a) and 2(b) of Confidential Annexure 2 are of the same layout. Both tables identify a particular Motorola file, state which directory it is located in (on the standalone computer), nominate the particular Hytera file or files which are said to copy that Motorola file and identify by line number both the lines of Motorola source code which have been copied and the lines of Hytera source code said to do the copying. For example, cell 1 in Table 2(a) is as follows: Motorola file Locations of Motorola file Hytera file Motorola lines Hytera lines event_codes.h samurai\code\source\rfhal\framerLib\framer\release\ Subscriber: main\CPArelease\library\rfhal\EventCode.h 1-270 (whole file) 1-240 (whole file) samurai\code\source\rfhal\framerLib\l1timer\ Repeater: library\CPArelease\ Latest\library\rfhal\ EventCode.h 1264 The problem with this from the standpoint of the eight subordinate works may be illustrated by considering the position of the Darwin Ergonomics Platform identified in cell 1 of Confidential Annexure 1. In order to determine which parts of the Darwin Ergonomics Platform are alleged to have been taken, one needs to start with Confidential Annexure 1. The first cell tells one that the platform consists of all of the files in four directories but not what those files are. Hence, it is not possible to determine from Table 2(a) of Confidential Annexure 2 which parts of the Darwin Ergonomics Platform are alleged to have been taken unless one takes two steps: (a) find in the evidence some list of what the files in Confidential Annexure 1 are; and (b) compare that list of file names with the file names listed in Table 2(a). 1265 The same problem afflicts the other seven subordinate works. 1266 Thus, other than in relation to the three overarching works – the mobile, portable and DSP source codes – the particulars provided by Motorola offer little assistance in identifying how its case actually works in relation to each of the subordinate works. And in relation to the mobile, portable and DSP Firmware, a more serious problem exists which Motorola's submissions do not alleviate. Although the table above and Motorola's submissions proceed on the assumption that its case of the three sets of firmware is based entirely on the constituent works, this is not what the evidence shows or, when they are unravelled, what Motorola's particulars show. In fact, Motorola's formal case includes many files which are said to be part of the three sets of firmware which are not parts of the subordinate works. As will be seen, as these reasons march further into the mire, Motorola's submissions do not grapple with this. It is likely that this problem has its origins in an anterior failure in its submisisons to grasp (or at least to explain) how the structure of its own expert evidence related to the successive waves of discovery given by Hytera. Without understanding this, it is not possible to understand Motorola's expert evidence. It is therefore necessary to start with the question of discovery. THE PROCESS OF DISCOVERY AND ITS RELATIONSHIP WITH THE EXPERT EVIDENCE 1267 Although the discovery process was itself drawn out, it is convenient to summarise what occurred by saying that it was given in four tranches. There was an initial round of discovery which resulted in an earlier form of Motorola's particulars ('the First Tranche'). Three laptops were then unearthed by Hytera, one of which contained further materials which were then discovered ('the Second Tranche'). This contained additional Hytera source code and two 'library' files. These library files contained object code not source code. There was then further discovery of two more sets of library files ('the Third Tranche') which also contained object code rather than source code. Following that, there was discovery of the source code files for one of these libraries ('the Fourth Tranche'). The final version of the particulars reflected what had happened by the end of the Fourth Tranche. 1268 Motorola's evidence in chief on this topic came principally from Professor Wicker. He was provided with printouts of Hytera source code and access to Motorola's source code via a secure laptop which, I infer, did not include the files which were discovered in the Second Tranche of discovery. Professor Wicker unravelled the complexities of, what I infer would be an earlier version of Confidential Annexures 1 and 2, and produced a helpful document, SBW-38, in which he tabulated some (but not all) of the lines of Motorola's source code which were alleged to have been taken next to the lines of Hytera's source code which were said to do the taking. To an extent he broke this analysis down into the works in suit although this was not complete. For example, SBW-38 was broken into separate parts dealing with the: (1) EMT Component of the Darwin Ergonomics Platform; (2) Darwin Ergonomics Platform; (3) Mobile Firmware and Portable Firmware; (4) L1 Timer; (5) Framer; (6) FramerLib library; (7) HAL Serial Buffer; and (8) DSP Firmware (though this part merely directed the reader to earlier parts of the document where the DSP Firmware had overlapping source code with other components). 1269 He did not devote separate sections to the two works Xlate and UIT. However, in his treatment of the Darwin Ergonomics Platform it is reasonably clear that sections 2.1-2.6 relate to Xlate and sections 2.7-2.9 to UIT. It seems to be common ground, and consistent with my understanding of the evidence, that the EMT component is part of the Darwin Ergonomics Platform, so SBW-38 might have been a little clearer if Xlate and UIT had been treated the same way as the EMT and the Darwin Ergonomics Platform were treated i.e. separately by cross-reference. 1270 Professor Wicker also delivered his side by side analysis with a more detailed commentary on why he thought that a substantial part of the each of the works had been taken. This was in document SBW-32. Read with SBW-38, SBW-32 is relatively straightforward. The Second Tranche 1271 After Professor Wicker's initial evidence was delivered, the Second Tranche of discovery was given. This included further Hytera source code and the two 'library' files. 1272 What is a library file? Generally speaking, much of the source code which has been discovered by Hytera consists of lines of code in C or C++. Largely, the files are either 'header' files or 'source' files. The difference between these does not presently matter. However, they are both elements in coding in C and C++. When the composition of a program is completed it is compiled into object code which can be executed by a computer processor and which is incomprehensible to humans. It is possible to disassemble such code into a family of low level languages known as 'assembly languages'. An assembly language is accessible to humans but is not for the faint hearted. It is a depiction in a more readable form of what the processor is actually being asked to do. Whilst the assembly code considered as a whole will, like the object code itself, achieve the functionality of the source code from which it is derived, it is in substance a human readable form of the actual instructions the processor is given. Thus one cannot discern from assembly code any of the higher concepts discernible in the source code. As I have mentioned above, a useful analogy may be made between an architect's plans and the instructions given to the individual trades who put a building together. 1273 As part of the development process, source code files are often compiled into object code which is then stored in files known as library files. Like a real library, each library will have files on its virtual shelves and these files will consist of particular tracts of object code compiled from the original source code dealing with, for example, a particular function. Although no one made this clear, I apprehend that library files may also contain source code. However, the two particular library files in question were libraries of already compiled object code. 1274 All one could say about the library files was that they had been compiled from pre-existing Hytera source code. There was no suggestion that the source code from which the two libraries of object code files had been compiled had otherwise been discovered. In terms of the Hytera source code they therefore represented to Motorola something of a black box. 1275 Professor Wicker returned to the field on 25 July 2019 to address by way of further evidence the recently discovered additional source code and, at the same time, the mysterious contents of the two library files. By this time, Motorola had amended its particulars to include the fresh source code allegations and now also to include the significance it attributed to the two library files. 1276 In relation to the source code, he carried out the same exercise he had carried out on the first occasion expressing an opinion about the extent to which the fresh Hytera source code had been copied from the Motorola source code. The Motorola and Hytera source code files he was asked to examine are referred to in document SBW-57. However, perhaps disappointingly (at least from my perspective), Professor Wicker did not do what he had done on the previous occasion with SBW-38. Rather than set out the two sets of code side by side, SBW-57 is structured similarly to Confidential Annexure 2. It identifies: (a) particular Motorola source code files and their location on the standalone computer; (b) the corresponding Hytera file which is said to copy the Motorola source code; and (c) the specific the lines in each of the Motorola and Hytera source codes which are relevant to each alleged act of copying. 1277 In his evidence, Professor Wicker expressed a general opinion that the Hytera source code in SBW-57 had been copied from the Motorola source code in that document: SBW-56 at §17. He made particular remarks about the 29 source code files identified in SBW-57. However, without more complete extracts of both sets of the source code in SBW-57 (cf. SBW-38), it is difficult to do much with that conclusion. For reasons relating to Mr Brown's subsequent evidence, this problem is surmountable (I return to this, but in a nutshell Mr Brown did do a side by side comparison). 1278 In relation to the two library files, Professor Wicker then caused to be conducted a process of disassembly upon the object code contained in them to retrieve some information from it. This information largely consisted of the names of files and functions which had existed in the now missing source code. Professor Wicker recognised some of these file and function names as matching or partially matching file and function names he had seen in Motorola's source code. He set out these file and function names in SBW-59 and SBW-60. I will return to the detail of this evidence in due course. 1279 For present purposes, it is then necessary to understand how this Second Tranche of evidence in chief from Professor Wicker interacted with Motorola's then particularised case. 1280 As to the source code, whilst SBW-57 identifies the lines of the allegedly copied Motorola source code and Hytera source code said to do the copying, it does not set the source codes out. As a result, one cannot know the contents of the parts of Motorola's 11 works which are said to have been infringed by which Hytera source codes beyond the 29 files referred to in the body of SBW-56. But even in that case, there is not much one can do with this deprived of a side by side comparison of the code except perhaps to take Professor Wicker at his word. 1281 The only way to resolve this problem, in principle, is to retreat to the particulars themselves. However, as I have intimated above, those particulars cannot be made sense of without evidence which actually identifies the files. Whilst SBW-57 does group the 29 files into 'Mobile Firmware and Portable Firmware', 'DSP Firmware' and 'other files', it is not possible to identify which of the eight subordinate works (referred to above at [1159]-[1161]) the files are a part of. 1282 In principle, I could retrieve for myself the earlier version of the particulars and attempt to reverse engineer the changes and thereby determine the contents of SBW-57 indirectly. I do not think I should do this. I am not confident I would be correct; Hytera has not been heard on it; it would be time consuming; and it is not the Court's role to work out what Motorola's case is. 1283 Turning then to the library files (which is the point of this exegesis), Motorola's particulars do identify with precision what it seeks to get from them. The two library files are: raf_arm9.lib; and DmrDspLib.lib. 1284 From the particulars, it is apparent that Motorola alleges that raf_arm9.lib is a Hytera file which as a 'whole' copies 19 specified Motorola files. These files are identified as being part of the Portable and Mobile Firmware source codes. Hytera, but not Motorola, has undertaken the task of tracking each of these 19 files to their correct location in the EMT, Xlate, UIT and the Darwin Ergonomic Platform works: HCS(C) Mod II at [253(a)]. According to it, 12 of the files come from the EMT component (itself consisting of 151 source code files), 5 come from the Xlate component (itself consisting of 110 source code files), and 1 comes from the UIT component (itself consisting of 157 source code files). This makes for a total of 18 files which means one is missing in the analysis. I am unable to account for the location of the 19th file. In any event, it is these 19 files which are alleged to have been copied in the case of the Darwin Ergonomics Platform source code and, again, in the case of the Portable and Mobile Firmware source codes. 1285 From the particulars, it is apparent that Motorola alleges that the DmrDspLib.lib as a whole copies 64 nominated files which are identified only as being part of the DSP Firmware source code. One cannot tell from Confidential Annexure 2 whether any of these files are part of Framer, the L1 Timer, the framerLib Library and the HAL Serial Buffer or whether they are free floating parts of the DSP Firmware source code which stands outside that case. 1286 In any event, the point for both library files is the same. They are said by reason of their entire contents to be copied from 19 specified files in the portable and Mobile Firmware source codes and from 64 specified files in the DSP Firmware source code. The Third Tranche 1287 Two further libraries of object code were then discovered. These were the rfhal_c55.lib and the CPA library files. Professor Wicker again conducted a process of disassembly on these two library files and concluded that they contained references to file and function names found in the Motorola source code: SBW-61 at §§74ff. 1288 In relation to the rfhal_c55.lib library file, Motorola then alleged that the whole of this file was copied from nine identified files in the DSP Firmware source code. It did not identify whether these files formed part of part of Framer, the L1 Timer, the framerLib Library or the HAL Serial Buffer or whether they were free floating parts of the DSP Firmware source code which stood outside that case. The Fourth Tranche 1289 The issues which would have arisen from the CPA library files were averted by the Fourth Tranche of discovery which resulted in the production of four identified source code files from which the CPA library file had been compiled. Three of them are the source files EventBase.cpp, NotifierBase.cpp and ListenerBase.cpp. Each of these is alleged to be part of the mobile, portable and DSP Firmware. In each case, however, they are not alleged to be part of any of the other constituent works (that is, the EMT, Xlate or UIT). The fourth file, SingleLinkedList.cpp, is alleged to be part of the EMT component (within the Portable and Mobile Firmware). PULLING THE STRINGS TOGETHER: WHAT IS MOTOROLA'S CASE AND WHAT IS NOT? 1290 There are a number of points which emerge from the above discussion concerning what the nature of Motorola's case is. 1291 First, Motorola's case is that identified parts of its source code have been copied. The source code in suit is specified portions of specified files. Motorola does not allege that all of its source code has been taken. In particular, it does not allege that the source code which is missing in the case of the three libraries (raf_arm9.lib, DmrDspLib.lib and rfhal_c55.lib) involved copying any more than the identified files in Confidential Annexure 2 associated with each of those three libraries. Although Motorola referred to the 'wholesale' copying of its source code, that statement was not reflected in the case advanced in Confidential Annexure 2 or the case advanced by Professor Wicker. As Hytera correctly observed, there was a gulf between that statement and the reality of the number of files identified. For example, Motorola's Mobile Firmware source code as identified in Confidential Annexure 1 contained, according to Hytera, 4,994 files, but only 60 of those files appeared in Confidential Annexure 2: HCS(C) Mod II at [35]. Regardless of the role of file or line counting in the analysis called for, the word 'wholesale' was out of proportion to what it is that Motorola actually alleged. 1292 Secondly, Motorola's particularised case requires for its assessment a descent into the particulars it provided. Its submissions did not attempt this with the consequence that Motorola has not identified the 11 works on which it sues. 1293 Thirdly, in relation to the Second Tranche of discovered source code (and leaving aside the two library files discovered at that time) whilst SBW-57 identifies the names of the actual files in question, it does not set out any extracts of the source codes. I therefore have Professor Wicker's views on what a comparison of these Motorola and Hytera source codes shows without having the actual source codes on which that opinion is based. To my mind, this is unfortunate. 1294 Fourthly, because Motorola's submissions do not explain this additional source code there is no way of determining what it is. This would have required an explanation of the discovery process which took place. 1295 Fifthly, the decision to structure Confidential Annexure 2 by reference only to the Portable, Mobile and DSP Firmware source codes makes identification of how much code has been taken from the subordinate works (the Darwin Ergonomics Platform, EMT, Xlate, UIT, Framer, the L1 Timer, the framerLib Library and the HAL Serial Buffer) challenging. This difficulty is exacerbated by Motorola's failure to identify the works in suit. 1296 To illustrate the problem I have in mind and to take the example of the EMT component, what is missing from Motorola's submissions is a section where its case on the EMT component is advanced and explained. Motorola's submissions do not include: (a) an identification of the EMT source code on which Motorola sues and a reference in the evidence to where it may be found; (b) an identification of the Hytera source code (or library file) which is said to have been copied from the source code or library file in (a) and a reference in the evidence to where it may be found; (c) an analysis of the evidence explaining why the two sets of code are objectively similar; or (d) an explanation of the EMT source code so that the role that the taken parts play in it can be gauged so as to allow an assessment of whether the parts taken form a substantial part of the EMT. 1297 In the case of the overarching firmware an additional problem exists. As I have mentioned, it is apparent from Motorola's particulars that there are files within these works which are not contained in the identified subordinate works within them. For example, there are files within the Darwin Ergonomics Platform which do not appear to be part of the EMT, Xlate or UIT components. Largely, Motorola did not mention these files or explain how they fitted into its case. THE COURSE FORWARD 1298 In these circumstances, I will consider each of the works separately. For each work I will: (a) attempt, if possible, to identify the Motorola source code which is alleged to have been reproduced in the Hytera source code; (b) identify the Hytera source code which is said to be objectively similar; (c) identify where in the evidence the relevant expert opinion is located; (d) assess whether in respect of that code objective similarity is established; and (e) where objective similarity is established, determine whether the part in question is a substantial part of the relevant work. 1299 Having rejected Hytera's global originality challenge, I will not generally deal with originality. However, on some occasions, Hytera raises individual points about originality and when this is the case, I consider those challenges. 1300 I will begin with the EMT, Xlate and UIT components which are the three programs within the Darwin Ergonomics Platform. I will then consider the Darwin Ergonomics Platform and after it, the Mobile and Portable Firmware. Having done that, I will move to the two programs within the framerLib Library, that is to say, the L1 Timer and Framer, and I will then consider the HAL Serial Buffer, and then consider the position of framerLib Library. Having done that, I will finally address the DSP Firmware. XI WERE THE 11 WORKS INFRINGED? INTRODUCTION 1301 In this Chapter, I consider Motorola's extensive allegations that particular lines of its source code were copied by Hytera into its source code. As I have previously explained, that would not by itself constitute an infringement of Motorola's Australian copyright since, if established, it would have occurred in China. It is, however, an essential step in its case that the Hytera object code, which was compiled from Hytera's source code, was an adaptation of Motorola's source code which was then imported into Australia. If the Hytera source code does not involve the copying of a substantial part of the Motorola source code, then Hytera's compiled object code will not involve an adaptation of a substantial part of Motorola's source code and the importation infringement suit will fail. 1302 In the case of each tract of source code, it is necessary to determine whether the code was copied as alleged. Because Hytera concedes that the code was copied if it is shown to be objectively similar, this question devolves to whether Motorola has demonstrated that the accused lines of the Hytera source code are objectively similar to the nominated lines of the Motorola code. 1303 If copying has occurred, it is then necessary to determine whether the lines copied were a substantial part of the relevant program which Motorola puts forward as a literary work. There are 11 such works. To determine that question it is necessary for Motorola to demonstrate that the lines of code are material to the operation of the program and that they are original (in the infringement sense). 1304 The 11 works have already been identified by name. The main issues for determination in this Chapter are therefore: (1) an explanation of the nature and operation of each of the 11 works; (2) the identification of the files constituting each work which are alleged to have been copied by Hytera; (3) the identification of the lines of code within each file which are alleged to have been copied; (4) a comparison between those lines and the lines of the Hytera code which are said to do the copying so as to determine whether the two sets of code are objectively similar. If they are, then Hytera concedes that its lines of code have been copied; (5) in relation to those lines of code which have been copied, a determination of whether they are material to the work in suit; (6) in relation to the same lines of code, a determination of whether they are original in an infringement sense; and (7) a conclusion in relation to each of the 11 works as to whether a substantial part has been copied by Hytera and therefore whether Motorola's infringement suit (based on adaptation) succeeds. DIFFICULTIES WITH UNDERSTANDING MOTOROLA'S CASE 1305 As I have already explained above, Motorola's submissions do not identify any of the 11 works in suit by reference to the specific files which were said to constitute them. It is also not possible to work out which files constitute each of the 11 works from Motorola's particulars since the definitions in those particulars operate by reference to directories on a standalone laptop to which I was not given access. Hytera itself did not explicitly identify the files for each of the 11 works, although since it was not its case, it had no obligation to do so. However, as part of Hytera's line counting analysis it included a reference to Mr Brown's Confidential Annexure 'CMB-25'. CMB-25 contains a list of files for each of the constituent elements of the overarching works (the Mobile, Portable and DSP Firmware). Motorola made only fleeting references to CMB-25 in a footnote of its reply submissions, and even then did so only to challenge the reliability of Hytera's evidence generally, not to identify any of the relevant files. 1306 Motorola did not identify in its written submissions the particular lines of code which were said to have been copied from the files which it had not identified. Indeed, it did not develop any submissions about any lines of code said to have been copied and referred to very few of the files. As will be seen, there is a mountain of computer code involved and swathes of evidence from Professor Wicker and Mr Brown about that code. With some very minor exceptions, Motorola did not engage with this evidence in its submissions. 1307 Thus, largely, Motorola did not make submissions about its infringement suit at the level of the computer codes. The submissions which it did make were couched at a high level of generality which I have found to be of little use when considering at the coal face the particular lines of code it has nominated as the actual subject matter of its suit. Indeed, because Motorola did not identify the files constituting the works in suit, they were actively unhelpful in the sense that a great deal of time was squandered trying to work out what the files involved were. The identification of the work in suit in a copyright infringement suit is elementary. 1308 There were other deficiencies in Motorola's submissions to which I will refer as they arise. I have endeavoured to impose order and structure on the computer code issues in what follows. If the matter proceeds to an appeal, it should be borne in mind that this order and structure was created without assistance from Motorola. In effect, the Court has been forced to do the basic work of identifying and assessing the relevant evidence which should have been done by Motorola. 1309 I will begin with the component works situated within the Darwin Ergonomics Platform, then move to that platform before considering the Mobile and Portable Firmware. Having done that I will turn to the component works within the DSP Firmware and then that firmware itself. I begin therefore with the EMT. The EMT Component 1. GENERAL DESCRIPTION OF THE EMT AND ITS RELATIONSHIP TO THE OTHER ELEMENTS 1310 The EMT is one of the components of the Darwin Ergonomics Platform. In very broad terms, the Darwin Ergonomics Platform administers the processes by which users and a radio device interact. According to a document prepared by Motorola referred to as the 'Darwin Ergonomic Platform Architecture' document ('the Architecture Document') it was intended to be a high level software architecture for the representation and implementation of the ergonomic concepts for open architecture radios: at p 6. By ergonomic concepts, I understood this to be a reference to the working environment provided to users. An 'open architecture radio' is defined within the Architecture Document as 'a radio that the memory module it uses is off the board'. 'Open architecture' therefore is a reference to a kind of software architecture in which the operation is not dependent on the devices which are being used. As Mr Ley explained in DJL-1 at §10, the aim of the Darwin Ergonomics Platform was to provide an application environment in which different radio functionalities could be developed in a way that could be readily used in different radios. Each of the components of the Darwin Ergonomics Platform provides a set of services which allows the applications to run on a standalone basis. Where parts of the code depend on the specific radio hardware being used, these were separated into different radio-specific layers. Apart from the radio-specific layers, most of the Darwin Ergonomics Platform is hardware independent. 1311 The Architecture Document, at p 6, depicts the operation of the radio operating system and indicates that it occurs at three levels: the high level, the common level and the low level. The components of the Darwin Ergonomics Platform (including the EMT) are situated in the high level. There are five subsystems in the high level. These are the: User Input Queue Task ('UIQ'); Xlate; UIT; EMT; and Common Level Interface Management ('CLIM'). 1312 The relationship between these five core components and the common and low levels is illustrated by this diagram at p 15: [Redacted] The UIQ 1313 The UIQ is responsible for the physical inputs coming from the low level (from the user's interaction with the device). [Redacted]. The Xlate 1314 The Xlate is responsible for converting the physical inputs handed to it by the UIQ into logical inputs that can be understood by the other high level components. It communicates with the UIQ to control the flow of user information. The EMT 1315 Mr Ley explained in DJL-1 at §§29ff that the EMT is the main application environment on the radio. The applications are implemented [Redacted]. 1316 The functions of the EMT include: [Redacted] 1317 The process of [Redacted] is one of the core data services provided by the EMT. So much appears from the Architecture Document at p 27. The process of application interaction management involves [Redacted]. The [Redacted] and [Redacted] are both relevant to Motorola's case. I will describe them more closely when the need arises. The UIT 1318 The UIT is responsible for most outputs to users. [Redacted]. The CLIM 1319 The CLIM [Redacted]. 1320 [Redacted]. 2. FORMAL IDENTIFICATION OF THE EMT COMPONENT AS A LITERARY WORK 1321 I have referred above to the impossibility of identifying the EMT from Motorola's submissions or its particulars. In CMB-25, Mr Brown identified the files constituting the EMT as follows: 1322 Where the number '35' appears beneath 'SBW' this indicates that the source file was discovered by Hytera in the First Tranche of discovery. Professor Wicker provided an index of these in SBW-35 although, as in the case of Motorola's particulars, one cannot get a complete description of the EMT files from SBW-35. Where the numbers '57' or '59' appear, it indicates that the source code was discovered in the Second Tranche of discovery and indexed in SBW-57 and SBW-59 respectively. As with SBW-35, one cannot understand from SBW-57 or SBW-59 what the files in the EMT component are alleged to be. It is only with CMB-25 that this can be done. 1323 It will also be seen in relation to the files discovered in the Second Tranche that there are some files described by Mr Brown as 'Source to Binary'. What this means is that in those cases the source code was not actually discovered. Instead what was discovered were two library files, raf_arm9.lib and DmrDspLib.lib, containing object code. This object code had been compiled from source code prepared by Hytera. Hytera has not discovered the source code from which this object code was compiled. It says it has not been able to locate this source code. Professor Wicker's evidence about these files therefore relied upon his inspection of disassembled object code. Motorola's submissions about this, insofar as it concerns the EMT, were contained in a single sentence in MCS(C) Mod II(E) at [63]. I will return to the nature of disassembled object code later in this Chapter. 1324 Although Motorola nowhere clarified how the expert evidence of Professor Wicker related to the tranches of discovery, it is impossible to understand it without drawing distinctions between the tranches. I will deal with the issue of objective similarity in three phases: (a) source code files that were discovered in the First Tranche; (b) source code files discovered in the Second Tranche; and (c) object code discovered in the Second Tranche. 1325 (There are also the Third and Fourth Tranches of discovery but they are not relevant to the EMT. I will deal with them when dealing with the DSP Firmware). 1326 In relation to each file (where a file is involved), I will deal successively with objective similarity, copying (if it arises), and substantial part. In relation to substantial part, Motorola must establish that each copied portion of its code was both original (Computer Edge Pty Ltd v Apple Computer (1986) 161 CLR 171 at 182) and that it constituted a material or essential feature of the EMT: IceTV at [158]-[159]; Data Access at [84]. In determining what is material or essential it is not appropriate to approach the matter on a 'but for' basis, i.e. by asking whether the program would work without it: Data Access at [81]-[84]. Instead the Court is to engage in a process of qualitative abstraction of the material features of the computer program allegedly copied: IceTV at [158]-[159]. Generally speaking, the quality of what is taken is more important than the quantity, but quantity is not completely irrelevant. It will be seen therefore that the substantial part analysis involves two inquiries: materiality and originality. I will consider these in relation to each file after the objective similarity analysis. 3. THE FIRST TRANCHE SOURCE CODE RELATING TO THE EMT Background 1327 In relation to the First Tranche, Professor Wicker identified in SBW-32 lines of source code within Hytera's source code files which he thought had been copied from identified lines of code in files within the EMT component. He concluded that the majority of these lines of Hytera source code were identical to the lines of the Motorola source code. He also thought there were some lines that were similar but exhibited slight differences from the Motorola source code: SBW-32 at §65. He provided Motorola's solicitors with his comments about these similarities and differences. Motorola's solicitors then produced a document (SBW-38) which contained a side by side comparison of the two sets of code with Professor Wicker's observations about the similarities and the differences included in a comments column. Colour coding was also included. Where there was no colour this indicated verbatim copying. Source code which was present only in the Motorola source code was coloured blue and source code present only in the Hytera source code was coloured purple. Code which was the same but had been moved was coloured orange or yellow depending on its source. Code which had been altered was surrounded with a red box: SBW-38 at pp 1-12. It will be noted that the preparation of such a side by side analysis involves considerable effort. It is not simply a question of putting the two sets of code next to each other. 1328 In the First Tranche, Mr Brown has identified eight files in the EMT: CMB-25. However, the 'EMT Component' section of Professor Wicker's side by side analysis only deals with seven. The eighth file, com_cp_button_def.h, is dealt with by Professor Wicker under a separate section entitled 'Darwin Ergonomics Platform'. 1329 In CMB-10, Mr Brown commented on Motorola's side by side analysis in SBW-38. Largely, he agreed with Professor Wicker's analysis. 1330 The eight files are described by file names ending in '.h' or '.c' which are particular file types (I explain these shortly). The eight files are: cor_emt_user_defines.h cor_emt_app_defines.h rs_emt_mode_arbitrator.c svc_applications.h svc_interact_mgmt_services.h com_ergo_platform_app_defines.h com_ergo_platform_user_defines.h com_cp_button_def.h 1331 Before turning to these individual components, it is useful to explain the difference between the files ending in '.h' and those ending in '.c'. Most of both Motorola and Hytera's source code is written in an object oriented procedural language, C++. When code is in written in C++ it is common to split the code between 'header' files (here, the '.h' files) and 'source' files (here, the '.c' files). 1332 To understand the difference between header files and source files it is necessary to say something about variables, functions and function prototypes: SBW-32 at §§22-31. 1333 A variable is a term which can take on particular values. The kinds of values that can be taken are referred to as the variable's data type. For example, a variable might have a data type of being an integer. Alternatively, it might simply be a true/false value: SBW-32 at §31. As I understood, the purpose of declaring a variable was to establish its existence and to specify the kind of value it could have. 1334 A function is a series of commands (here, in C++) which acts on a variable and which returns a value. Independent of the commands constituting the function, it is necessary for its existence to be declared and its parameters set. For example, it might be declared that a function handles variables of a particular kind (e.g. integers): SBW-32 at §30. The process of declaring a function in C++ involves a function prototype which states the name of the function, the data type, the function returns and the parameters or variables the function takes. The function prototype does not include the actual code constituting the function. 1335 I have found a convenient way to think of variables and function prototypes as being a form of meta-information about variables and functions (and other data structures). In C++ this kind of meta-information about variables and functions must be declared in the source code. 1336 Where a variable or function is used by multiple programs or sets of code it would be possible to declare each variable and function prototype for each program. However, as Professor Wicker explained, the usual practice is to put these declarations in files known as header files: SBW-32 at §24. This practice allows the variables and functions to be used in multiple files without having to repeat the process of declaration in each file. During the process of compilation the source code picks up the declarations contained in the relevant header file by means of a command which causes the compiler to do so. Professor Wicker identified two advantages of splitting the source code into header files and source files. These were that: (a) it made the declarations more universally available; and (b) achieved efficiencies when the source code was compiled. Mr Ley gave similar evidence. When the source code is compiled, the header files are not themselves compiled. Rather they 'included' in source files (by way of an '#include' statement) to make the process of compiling the source files more efficient. The #include statement has the same effect as compiling the code in the header file but without needing to copy the whole of the header file code into the source file: SBW-32 at §§22-27. 1337 Returning then to the eight files identified above as having being taken from the EMT component, it will be seen that seven are header files and one is a source file. I will now identify the files which are said to have been copied and the line numbers of source code involved. Motorola's submissions do not undertake this exercise. A. cor_emt_user_defines.h (a) Objective Similarity 1338 This file is a header file. Professor Wicker identified 13 portions of this code that he said were objectively similar to identified portions of the Hytera header file raf_app.h: SBW-38 at 1-5. The relevant portions and lines were as follows: cor_emt_user_defines.h raf_app.h 1 141-166 46-63 2 170-198 120-147 3 199-229 148-178 4 232-248 326-342 5 250-261 352-363 6 265-275 181-191 7 278-281 198 8 283-287 64-68 9 301-328 296-323 10 350-358 281-288 11 360-372 365-373 12 383-387 290-293 13 390-391 375-377 1339 Motorola made no submissions about these lines of code. Mr Brown agreed that Professor Wicker's side by side analysis was correct. Having examined all 13 sets of lines of codes, I am satisfied that they are objectively similar. The differences between them are either cosmetic or trivial. (b) Materiality 1340 Motorola made no submissions about the materiality of any of the above lines of code. Dealing with each of the above line number ranges: Lines 141-166 1341 Motorola made no submissions about these lines. Professor Wicker says that these lines of code define [Redacted]. He goes on to say that [Redacted]. 1342 The lines of code in question are part of a header file. Making the assumption that if the source file to which these header lines relate was a substantial part of the EMT that the header file would be too, Professor Wicker did not tell me what those source files were or where they fitted into the EMT. He did say that [Redacted] was 'an example of the flexible design that Motorola's Darwin Ergonomics Platform entails'. This indirect evidence about the source files is not sufficient for me to draw a conclusion on the materiality of those source files and therefore of the materiality of these lines of the header file. 1343 I should say that Motorola made very general submissions about whether header files, in principle, could be a substantial part of a computer code. This analysis is of no use. The question cannot be answered in the abstract. Some header files may be a substantial part of a computer program; others may not. It depends on the header file and the program. Because Motorola did not engage in an analysis of the particular header and source files, it did not equip its submissions usefully to address this question. 1344 It is therefore not shown that lines 141-166 are a substantial part of the EMT and Motorola's infringement allegation with respect to these lines fails. Lines 170-198 1345 Motorola made no submissions about these lines. Professor Wicker said that these lines provide [Redacted]. He did not say what [Redacted] were although he did refer to Mr Ley's evidence in DJL-1 at §71. Mr Ley explained that this header file defined data types and functions which needed to be used by the 'Darwin Core' but needed to be used by or implemented in the radio-specific layer. By Darwin Core I took Mr Ley to be referring to the five core components discussed above. He also said that lines 170-229 of the file included [Redacted]. It is unclear how much of that evidence relates to lines 170-198. 1346 Motorola did not submit that these enumerations related to the [Redacted] associated with the file rs_emt_imt_com.c although it is possible, I suppose, that they do. Making the assumption that they do relate to the [Redacted] established by that source file, I do not accept that these header files are material to that [Redacted] or, consequently, to the EMT component. All that they do is [Redacted]. Whilst I accept that the [Redacted] would not work without these enumerations that is not the relevant test (as I have explained above). Rather, it is necessary to engage in a process of qualitative abstraction of the material features of the computer program allegedly copied and to identify the materiality of these lines to that program. Here the program is the EMT. The [Redacted] is as I explain below, material to the EMT. Whilst there may be cases where header files are material to the operation of functional code (such as the [Redacted]), there is, as I have said, no hard and fast rule about this. It depends on the functional code and the nature of the header file. In the case of this header file, all it does is enumerate [Redacted]. The material features of the [Redacted] consist of the particular way it resolves [Redacted]. In that context, the enumeration [Redacted] appears to me not to be material to the operation of the table. 1347 Motorola's infringement case in relation to these lines of code fails. Lines 199-229 1348 Motorola made no submissions about these lines. I do not conclude that they are a substantial part of the EMT. Motorola's infringement case based on these lines fails. Lines 232-248 1349 Motorola made no submissions about these lines. Professor Wicker explained these lines provided [Redacted]. As will be seen in the case of the source file rs_emt_imt_com.c (below), the [Redacted] are part of the [Redacted]. Effectively, these lines define [Redacted]. For the same reasons I have given in relation to lines 170-198, I do not accept that these lines are material. Motorola's infringement claim in relation to these lines fails. Lines 250-261 1350 Motorola made no submissions about these lines. Professor Wicker explained that these lines were [Redacted] which related 'to [Redacted]'. He drew my attention to the fact that [Redacted] was described in detail in section 7 of the Architecture Document. Having read section 7, I accept that [Redacted] is an important element in the overall operation of the Mobile and Portable Firmware. Unassisted by Professor Wicker or Motorola, it appears that it relates principally to the operation of [Redacted]. Doing the best one can, it seems that there are communications between [Redacted] – probably the EMT (Motorola did not explain this) and [Redacted]. However, there is no material available for me to work out where [Redacted] fits into the picture. Whatever the source file associated with this header file is, I am not satisfied on the evidence that that source file is a substantial part of the EMT. Consequently, I do not accept that it has been proven that an appurtenant header file is material. It is not necessary to reach a view on originality. 1351 Hence, I am not satisfied that this type definition is a substantial part of the EMT. Motorola's infringement claim in relation to these lines fails. Lines 265-275 1352 Motorola made no submissions about these lines. Professor Wicker did not explain what these lines of code did although he did say they related to the [Redacted] and referred to me to section 2.3.2.5 of the Architecture Document. That passage occurs in the context of a larger discussion about the [Redacted]. The first paragraph says this: [Redacted] 1353 I would accept that the code implementing the [Redacted] is a substantial part of the EMT as it is effectively an add-on feature to the [Redacted]. However, without knowing what these lines of code do, I do not find it possible to assess their materiality to that code. It is not necessary to reach a view on originality. Motorola's infringement case in relation to these lines fails. Lines 278-281 1354 Motorola made no submissions about these lines. Professor Wicker again said that these lines related to the [Redacted]. He did not explain what they did. For the reasons just given, I do not accept that Motorola has demonstrated materiality. Motorola's infringement claim in relation to these lines fails. Lines 283-287 1355 Motorola made no submissions about these lines. Professor Wicker again said that these lines related to the [Redacted]. He did not explain what they did. For the reasons just given, I do not accept that Motorola has shown that these lines are material to the EMT. Motorola's infringement claim in relation to these lines fails. Lines 301-328 1356 Motorola made no submissions about these lines. Professor Wicker said that these lines related to the [Redacted] which he said was 'one of the key [Redacted] used by the EMT' and which I have briefly touched upon above. He referred to the Architecture Document. Section 2.3.1.1 of the Architecture Document says: [Redacted] 1357 On that basis, I am prepared to assume that the [Redacted] itself is a substantial part of the EMT. Professor Wicker said that these lines of code 'related to' the [Redacted] and, in particular, to the common or low level. He said that [Redacted]. I take from this explanation that the lines of the header file declare [Redacted]. Of course, the declaration of [Redacted] is not [Redacted] itself. It merely establishes the format which [Redacted] will take. Whilst I would accept that header files are capable of forming a material part of a program, it depends on the header file and the program of which it is said to form a substantial part (here, the EMT). Accepting that the [Redacted] is material to the operation of the EMT does not entail that some lines of a header file which declares [Redacted] are material to the EMT. 1358 In order to assess that proposition one would need to know more about the [Redacted]. In particular, one would need to know the role that this declaration plays outside the EMT. For example, it is clear from the explanation above that the EMT communicates with Xlate, the common level and the low level. It does so by [Redacted]. The [Redacted] is in the format which is declared by these lines of code. But is not obvious whether the fact that the [Redacted] are in this format is a feature of the [Redacted] itself so that the header file may be seen as part of it or, instead, an assumed format which is required by Xlate, the common level and the low level. Further, it is unclear to me what the format declared by these lines of code actually is. To determine the materiality of these lines code would have required a full explanation of the structure and operation of the [Redacted]. In that circumstance, I am not satisfied that Motorola has proven that these lines of code are material to the operation of the EMT. Motorola's infringement case in relation to these lines fails. Lines 350-358 1359 Motorola made no submissions about these lines. Professor Wicker said that these data types make up a row of the [Redacted] which was, according to him, a key [Redacted] in the EMT. Resort to section 2.3.1.2 of the Architecture Document reveals this: [Redacted] 1360 I do not know what this means and Motorola did not explain it. I think it more likely than not that the [Redacted] is a substantial part of the EMT. However, in the absence of any explanation, it would be a guess on my part as to whether these lines are material to the EMT or original. Motorola's infringement claim in relation to these lines fails. Lines 360-372 1361 Motorola made no submissions about these lines. Professor Wicker said these lines related to the [Redacted]. For the reasons I have already given, that is not sufficient to allow me to conclude that the lines are material. Motorola's infringement claim in relation to these lines fails. Lines 383-387 1362 Motorola made no submissions about these lines. Professor Wicker said that these lines related to the [Redacted]. This is insufficiently explained for me to reach a view on materiality. For example, a little earlier Professor Wicker said that the [Redacted] was part of the EMT. Now it appears that there is an [Redacted] as well. For the reasons I have given above in relation to the [Redacted], not enough is known to form a view on materiality. Motorola's infringement claim in relation to these lines fails. Lines 390-391 1363 Motorola made no submissions about these lines. Professor Wicker said that these lines were a macro which was used to speed up the coding of function prototypes. This tells me nothing useful and is insufficient for me to form a view on materiality. Motorola's infringement claim in relation to these lines fails. (c) Conclusions on cor_emt_user_defines.h 1364 Motorola's infringement claim in relation to this file fails. B. cor_emt_app_defines.h (a) Objective Similarity 1365 Motorola made no submissions about this. Professor Wicker thought that nine portions of this file had been copied into portions of the Hytera file raf_app.h. The relevant portions and lines were as follows: cor_emt_app_defines.h raf_app.h 1 118-134 93-105 2 136-146 85-91 3 148-166 107-117 4 187-193 344-350 5 196-200 194-196 6 240-267 202-221 7 269-282 223-236 8 284-304 242-262 9 307-320 264-276 1366 Motorola said nothing about these lines of code apart from a stray reference in a quote in MCS(C) Mod II(E) at [118] of no particular moment. Having examined these, I am satisfied that they are objectively similar. (b) Materiality Lines 118-134 1367 Motorola made no submissions about this. Professor Wicker said that these lines defined [Redacted]. The explanation does not tie these definitions into any particular body of source code. There is lacking any explanation of what the [Redacted] might be, what the [Redacted] are (for example, is Professor Wicker talking about [Redacted]?), what the [Redacted] defined by these lines do or how do they do it. I am unable to determine whether they are material to the EMT. In some cases, the declarations in header files are entirely driven by the functional code to which they are referable. In other cases, they may reflect canny design. I am unable to ascertain which of these is the case with these lines. Motorola's infringement case in relation to these lines fails. Lines 136-146 1368 Motorola made no submissions about these lines. Professor Wicker said that these lines related to the various responses that are possible regarding the status of an application. This does not tell me enough to form a view on materiality. Motorola's infringement claim in relation to these lines fails. Lines 148-166 1369 Motorola made no submissions about this. Professor Wicker said that these lines define a [Redacted]. With that amount of information I am unable to conclude that these lines are material to the EMT. I do not accept, without more, that the definition of [Redacted] is original. Motorola's infringement claim in relation to these lines fails. Lines 187-193 1370 Motorola made no submissions about this. Professor Wicker said that these lines were a [Redacted]. I do not know what [Redacted] are and Motorola did not explain them. I am unable to conclude that these lines are material to the EMT. Motorola's infringement claim in relation to these lines fails. Lines 196-200, 240-267, 269-282, 284-304 and 307-320 1371 Motorola made no submissions about these lines. Professor Wicker's explanation of these lines suffers from the same difficulty as I have explained in the preceding lines of code, viz, a failure meaningfully to explain what the code does. I am unable to assess materiality. Motorola's infringement claim in relation to these lines fails. (c) Conclusions on cor_emt_app_defines.h 1372 Motorola's infringement case in relation to this file fails. C. rs_emt_mode_arbitrator.c (First Tranche) 1373 This file also appears in the Second Tranche in relation to the same and different lines. This section considers only the First Tranche allegations. (a) Objective Similarity 1374 There appear to be two slightly different versions of the file depending on whether it is part of the Mobile or Portable Firmware. Professor Wicker considered both versions. They are not analytically distinct and I will confine my attention to the version in the Mobile Firmware. Professor Wicker identified two portions of this file which he said were objectively similar to portions of the Hytera file ps_application.cpp. These were as follows: rs_emt_mode_arbitrator.c ps_application.cpp 1 106-109 109-112 2 112-156 67-107 1375 Motorola made no submissions about this file apart from a reference in MCS(C) Mod II(E) at [120] concerned with its simplicity. It made no submissions about the lines of code. Having examined them, I am satisfied that they are objectively similar. As I will explain later, the particular Hytera file in question is not one which was itself compiled because it was located in the 'RAF Library' directories (an expression I will explain in more detail later). As I also explain later, the files located with Hytera's RAF library directories were not themselves compiled into its object code. Thus whilst I accept these lines were copied as alleged, the copying has no direct relevance to Motorola's infringement suit which has an essential integer that the copied code must have been compiled into Hytera's object code before it can give rise to an infringement by the importation of the devices containing the object code into Australia. These lines are therefore irrelevant to Motorola's case. In saying that, I accept that they may assist in demonstrating that other source files which copied the templates in the RAF Library directories were themselves copied from Motorola's code. That use, however, is not relevant to this discussion. (b) Materiality 1376 Theis question is not relevant for the reasons just given. (c) Conclusions on rs_emt_mode_arbitrator.c (First Tranche) 1377 Motorola's case in relation to this file, insofar as the First Tranche is concerned, fails. D. svc_applications.h (a) Objective Similarity 1378 Motorola made no submissions about these lines. Professor Wicker identified three portions of this file which he said were objectively similar to the Hytera file raf_app.h. These were as follows: svc_applications.h raf_app.h 1 93-110 380-403 2 114-127 416-429 3 145-154 405-414 1379 Motorola made no submissions about these lines of code. I am not satisfied that the lines in (1) are objectively similar. I am, however, satisfied that the lines in (2) and (3) are. (b) Materiality 1380 Motorola made no submissions about this. Mr Ley said that this header file provided [Redacted]: DJL-1 at §69. This does not provide sufficient detail for me to form a view on the materiality of these lines of code to the EMT. Mr Ley also said that it declared [Redacted]: DJL-1 at §74(a). As I have said, whilst it is possible that a declaration of a variable or function could be material to source code, this is not a question which can be answered in a vacuum. Here it would be necessary to know more about the nature of the [Redacted] which is declared. Only once that is known could one assess whether the declaration of the [Redacted] was material to the actual code for that [Redacted], for example by contributing to the operation of the source code, and not merely a mechanical task required by the coding requirements of C++. 1381 In addition to Mr Ley's evidence, however, Professor Wicker also gave evidence about the lines in question: Lines 93-110 1382 Motorola made no submissions about this. Professor Wicker said that these lines were function prototypes for service functions used by applications. He thought they appeared to enable applications to access certain data buffers. I take it that it is the service functions which do the enabling and not the function prototypes for the service functions. For reasons already given, there is simply not enough information here to form the view that these function prototypes are material to the EMT. Lines 114-127 1383 Motorola made no submissions about this. Professor Wicker said these lines provided macros 'that are said to be used by applications to access different data structures'. This does not help. It is not sufficient to form a view on materiality. Motorola's infringement claim in relation to these lines fails. Lines 145-154 1384 Professor Wicker made the same comment about these lines. Motorola made no submissions. I reach the same conclusion. (c) Conclusions on svc_applications.h 1385 Motorola's infringement claim in relation to these lines fails. E. svc_interact_mgmt_services.h. (a) Objective Similarity 1386 Motorola made no submissions about this. Professor Wicker identified one portion of this file which he said was objectively similar to a portion of the Hytera file raf_app.h. This was as follows: svc_interact_mgmt_services.h raf_app.h 1 43-45 380-399 1387 Having examined these lines I conclude that they are objectively similar. (b) Materiality 1388 Motorola made no submissions about this. Mr Ley said that this header file declares a [Redacted]: DJL-1 at §74(b). This does not tell me enough to allow me to gauge the significance of this header file to the overall EMT. As to the particular lines: Lines 43-45 1389 Professor Wicker said that these lines were a function prototype. That does not assist in assessing the question of materiality. (c) Conclusions on svc_interact_mgmt_services.h. 1390 Motorola's infringement claim in relation to this file fails. F. com_ergo_platform_app_defines.h (a) Objective Similarity 1391 Motorola made no submissions about this. Professor Wicker identified two portions of this file as having been copied into portions of the Hytera file raf_app.h. com_ergo_platform_app_defines.h raf_app.h 1 80-82 41-44 2 103-116 70-83 1392 Having examined them, I am satisfied that they are objectively similar. (b) Materiality 1393 Motorola made no submissions about this. Mr Ley said that this header file provided definitions used by EMT [Redacted]: DJL-1 at §69. He did not provide a description of the source code to which these definitions relate. Without that I am unable to assess whether the code which provides for communications with other applications is material to the operation of the EMT. What are the definitions? How does the EMT use them? What qualities do the definitions have in terms of the structure of the EMT? None of these questions have been answered. Lacking that kind of information, I cannot assess the significance of this header file. As to the particular lines: Lines 80-82 1394 Professor Wicker said that these lines contain a list of constants. I do not know what the constants do or what they relate to. I do not find that these lines are material to the EMT. Lines 103-116 1395 Professor Wicker said this code [Redacted]. Without more, I am unable to conclude that these lines are material to the EMT. (c) Conclusions on com_ergo_platform_app_defines.h 1396 Motorola's infringement claim in relation to this file fails. G. com_ergo_platform_user_defines.h (a) Objective similarity 1397 Motorola made no submissions about this. Professor Wicker identified the following portion of this file as being objectively similar to the Hytera file raf_input.h. com_ergo_platform_user_defines.h raf_input.h 1 89-97 95-99 1398 Having examined the codes I am not satisfied that they are objectively similar. (b) Materiality 1399 This does not arise. (c) Conclusions on com_ergo_platform_user_defines.h 1400 Motorola's infringement claim in relation to this file fails. H. com_cp_button_def.h (a) Objective Similarity 1401 Motorola made no submissions about this. Professor Wicker identified the following portion of this file as being objectively similar to Hytera file raf_input.h. com_cp_button_def.h raf_input.h 1 64-102 15-52 1402 Professor Wicker's side by side comparison of this file is at p 13 of SBW-38 within the 'Darwin Ergonomics Platform' section. The file is a header file. The Motorola file contains [Redacted]. Professor Wicker said that the code defines [Redacted]. That is what Xlate does. [Redacted]. I accept that explanation of Xlate. However, of the [Redacted] established by this header file the only one referred to by Professor Wicker was [Redacted] which he said was used to [Redacted]. I accept this. As will be seen, Xlate also used this header file and it is located in both EMT and Xlate. 1403 Having examined both codes, I agree with Professor Wicker that they are objectively similar. This conclusion is underscored because a spelling error at line 95 of the Motorola code also appears at line 32 of the Hytera code ('structutes' instead of 'structures'). (b) Materiality 1404 This file does not establish any functional code. The best that can be said is that it establishes [Redacted]. Whilst accepting that it is possible for a header file to be material to the operation of the functional code, I do not accept that the mere establishment of a [Redacted] required by the functional code of both EMT and Xlate, for the purpose of [Redacted], is sufficient for that purpose. It is not necessary to address originality. (c) Conclusion on com_cp_button_def.h 1405 Motorola's infringement claim in relation to this file fails. 4. CONCLUSIONS ON OBJECTIVE SIMILARITY AND SUBSTANTIAL PART IN RELATION TO THE FIRST TRANCHE 1406 In relation to the above eight files, Motorola has failed to establish that a substantial part of the EMT was copied by Hytera into its source code. 5. THE SECOND TRANCHE OF SOURCE CODE 1407 Motorola did not identify these files in its submissions. With the aid of CMB-25 it is apparent that the source code files in the Second Tranche (excluding the files in the library files) are the following 11 files: rs_emt_mode_arbitrator.c rs_emt_load_init_mode_info.c rs_emt_handle_unused_input.c rs_emt_get_input_origin.c rs_emt_imt_com.c rs_emt_imt_com.h rs_emt_acrt.c rs_emt_adt.c cor_single_linked_list.h rs_application_id.h rs_uiopcode_list.h 1408 In SBW-57, Professor Wicker identified the line numbers of the source code in each of these files which he said had been copied into Hytera source files. In relation to the Hytera files he likewise identified the line numbers of the code which were said to do the copying. However, he did not do what he had done in SBW-38 with the First Tranche and provide a side by side comparison of the codes. In SBW-56, however, he provided a commentary on each of these 11 files. 1409 More usefully, Mr Brown identified the lines of source code said to have been infringed by particular lines of Hytera code. He set out the competing codes in a side by side analysis in CMB-13. Mr Brown produced his side by side analysis using a computer program. Professor Wicker was provided with this side by side comparison by Motorola's solicitors. 1410 Before turning to a consideration of the codes provided by Mr Brown, it is useful to mention two further matters. The first concerns multiple copies of files. At §19 of SBW-56, Professor Wicker explained that some of the Motorola files had been copied into files which were located in more than one part of Hytera's source code. For example, the same or a similar Hytera file (containing the allegedly copied Motorola code) might be found in the different parts of the source code dealing with subscriber units and repeaters. Similarly, as occurred in the First Tranche, there are some lines of the EMT source code which are alleged to have been copied into more than one Hytera file. 1411 This was not mentioned in Motorola's submissions. The course I propose to take with these doubled-up files is to ignore the multiple versions of the Motorola files since they do not add to the infringement case. In relation to the doubled-up Hytera files, it is apparent that Mr Brown has elected to do his side by side analysis by reference to one of the versions rather than to all. Since the code which has been selected by Mr Brown is the only code that has been tabulated, I will therefore identify the lines which are used by Mr Brown (noting that it is not feasible to conduct my own side by side comparison without the software used by the parties). Where there is some reason to mention why one Hytera file rather than another has been used, I do so. 1412 Secondly, in SBW-61 at section 7.2.2, Professor Wicker takes issue with the accuracy of some aspects of the side by side analysis performed by Mr Brown in CMB-13. Where necessary, I refer to these criticisms. 1413 Turning then to the 11 files in question: I. rs_emt_mode_arbitrator.c (a) Objective Similarity 1414 This file was also included the First Tranche. Now in the Second Tranche Professor Wicker identified that the same lines as in the First Tranche had been copied into other portions of various Hytera files. In addition, he now identified further lines of the Motorola file which had been copied. The evidence of Professor Wicker at SBW-56 at §19 establishes that there were three sets of directories in which the accused Hytera file could be found. He referred to these directories as respectively the 'RAF Library directories', the 'Application directories' and the 'AFP directory'. Motorola's submissions in MCS(C) Mod II(E) at [54] are consistent although not identical with the proposition that the RAF library files were not themselves compiled by Hytera but instead used as templates from which different versions were then generated, those versions later being used for compilation purposes. It is also consistent with Hytera's submissions at [199] and [201]. Mr Brown explained at T590-591 that the template files in the RAF library directories were not compiled. An attempt by the cross-examiner to get him to concede that they were discarded by the pre-compiler (and hence compiled) was unsuccessful. His evidence was that any attempt to compile the template files would generate an error. Hence, they were not compiled. I find that the files in the RAF library directories were not compiled into Hytera's object code. 1415 The most likely explanation for this evidence is the one suggested in Motorola's submissions, namely, that the files in the RAF library directories were used as templates from which substantive files were then generated and that it was these later files that were compiled. In any event, the point is that the template files in the RAF library directories were never themselves compiled into Hytera's object code. This does not mean that they may not have fed into the files in the Application and AFP directories as a sort of ur-text, but it does mean that any allegation based purely on a template file cannot succeed. Without compilation, an essential element in Motorola's infringement case is missing. Throughout this section I will deal with the RAF directory files by saying that they were not compiled which should be understood as a shorthand for this paragraph. 1416 In relation to the First Tranche of discovery (in which this file was also included) the lines of Motorola code in question were lines 106-109 and 112-156. Now in the Second Tranche, Motorola alleged that the same lines had been copied into the same Hytera file ps_application.cpp, however, this file was multiply located in the Application directories: SBW-57 at item 1 read with SBW-56 §§19 and 21. Professor Wicker explained this case at SBW-56 at §§21-22. 1417 Motorola said nothing about how I should approach these lines of code. In the absence of any submission, I will confine my attention to the case about the Application directories, that is to say, item 1 entry 2 of SBW-57. That table includes a reference to the lines of code in the RAF library which I have dealt with in the First Tranche and may be ignored. The balance of item 1 concerns the AFP directories which, given Professor Wicker's approach at SBW-56 at §21, I propose to ignore (i.e. because he did not say anything about the AFP directory version). 1418 The relevant file is therefore that version of ps_application.cpp located in the Application directories. Making the assumption that the Application directories version was compiled (and hence is useful in an adaptation analysis), the relevant lines of the Motorola and Hytera files are: rs_emt_mode_arbitrator.c ps_application.cpp 1 106-109 1148-1151 2 112-156 1086-1146 1419 Motorola made no submissions about these lines of code. I have examined the codes in Mr Brown's side by side analysis. I am not satisfied that these are objectively similar. The comments in lines 112-145 are clearly the same in the Hytera file. However, the substantive code at Motorola lines 149-156 and Hytera lines 1124-1146 are different. Professor Wicker did not give evidence that the logic of these two sets of substantive code was the same. No flow chart illustrating how the code operated was provided. I do not find it possible to say therefore that the differences are cosmetic. The high-water mark on this was Motorola's observation, in a section dealing with substantial part, that the purpose of this function was to [Redacted]: MCS(C) Mod II(E) at [120]. That does not help in the present context. 1420 Professor Wicker was persuaded at SBW-56 at §21 that the Hytera portions had been copied from the Motorola portions. The fact that the comments are nearly the same does show that whoever wrote the Hytera code likely had the Motorola code in front of them. However, the fact that I am unable to reach a conclusion about the substantive code (i.e. that part of the code not consisting of comments) prevents me from concluding that the nominated lines of the Motorola code are objectively similar to the nominated lines of Hytera code. Motorola did not offer a path through this evidence or otherwise assist. (b) Materiality 1421 This does not arise. (c) Conclusions on rs_emt_mode_arbitrator.c 1422 Motorola's infringement claim in relation to this file fails. J. rs_emt_load_init_mode_info.c (a) Objective Similarity 1423 Motorola made no submissions about this file. Professor Wicker says that lines 54-127 and 98-175 of this file have been copied into the Hytera file ps_app_mgr.cpp. Again his evidence makes clear that versions of this file exist in different directories. I will disregard the files in the RAF library directories since these were not ultimately compiled and focus on the copying into the version in the Application directories. The lines in question were set out in SBW-57 at pp 32-33. Motorola provided no analysis of the lines of code, nor any hint where they might be in the evidence. Professor Wicker provided no side by side analysis of them nor did he refer to any place where I might find a copy of the source codes in question. Only Mr Brown identified any lines of code. However, Mr Brown does not identify which directory the Hytera file came from. The lines identified by Mr Brown only match up with two versions of the file ps_app_mgr.cpp in SBW-57 at p 32 from which one may infer that these were in located in the Application directories. On that basis the files and lines are: rs_emt_load_init_mode_info.c ps_app_mgr.cpp 1 54-127 66-91 1424 I have examined the codes in Mr Brown's side by side analysis. It is clear that the comments are largely identical in Motorola lines 54-72 and Hytera lines 66-85. The substantive code at Motorola lines 75-127 is, except for one line, missing from the Hytera lines. The single line involves [Redacted] where it is reasonably clear that the Hytera function name is derived from the Motorola file name. Professor Wicker did not explain the import of the [Redacted] and Motorola's submissions did not discuss this. I would nevertheless infer from Professor Wicker's discussion at SBW-56 at §§ 23-24 that it has something to do with getting rid of a function. Professor Wicker thought that the Hytera engineers had most likely deleted the substantive code following the [Redacted] command (and which I assume would otherwise have constituted the function which was subject to the [Redacted] command) to avoid errors in compilation whereas the Motorola engineers appear to have left the substantive code in place. What these lines of code therefore do is provide some comments and a single line of code which [Redacted]. Although the fact that the [Redacted] function code remains in the Motorola file makes the file look quite different to the Hytera file, there is no significance to that code. As such the codes are structurally identical even if apparently different. I conclude that the codes are objectively similar. (b) Materiality 1425 Motorola made no submissions about this file. When discussing this file in SBW-56 at §§23-24, Professor Wicker did not explain what it did. In SBW-61 in a section headed 'The relative importance of the copied code' he discussed the significance of the lines of code taken in the Second Tranche. This section did not explain what this file (or the function it creates) does. He did tell me that much of the 'copied code' (by which he meant all the code he identified as being copied, not just this file) has been copied from the Darwin Ergonomics Platform: §97. He also said that it was a 'core' component of the Motorola programs. This is not strictly correct but does not matter. What he did not tell me was anything about this file or its relationship with the EMT component. In that circumstance, I am unable to assess the materiality of the lines of code in question since I am unable to assess the materiality of the file of which they form part. 1426 Consequently, I do not accept that Motorola has demonstrated that the lines in question are a substantial part of the EMT. (c) Conclusions on rs_emt_load_init_mode_info.c 1427 Motorola's infringement claim in relation to this file fails. K. rs_emt_handle_unused_input.c (a) Objective Similarity 1428 Motorola did not make any submissions about this file. In SBW-57 Professor Wicker identified the Motorola file as having been copied into various versions of a Hytera file which was located in each of the RAF library directories, the Application directories and the AFP directories. I ignore the RAF library directories versions since they were not compiled. Professor Wicker referred me to the location in the evidence of some source code at SBW-56 at §25 but did not conduct a side by side analysis of that code. I do not consider it my role to carry out a side by side analysis unassisted by Motorola. In any event, Professor Wicker did not tell me where the Motorola source code was located (and Motorola's submissions did not do so). Mr Brown did carry out a side by side analysis between the Motorola file and one of the Hytera versions in the Application directories at CMB-13 p 202. Mr Brown identifies the following: rs_emt_handle_unused_input.c ps_app_mgr.cpp 1 40-106 94-147 1429 Professor Wicker said that this Hytera code copied the function from the Motorola code but he accepted that it had been simplified: SBW-56 at §25. Mr Brown agreed in CMB-13 at p 203 that the overall goal and layout of the codes was the same. That function decides which tone to emit to indicate a button press was not used. He said that the Hytera version did not handle emergency button presses as in the Motorola case and simply emitted one of two tones using different logic to the Motorola code to determine the tone to emit. I do not understand this evidence. Motorola made no submissions about it. 1430 I have examined the codes in Mr Brown's side by side analysis. The comments are largely the same. However, the substantive code is different. There is no metric available to test Mr Brown's evidence that the logic is different. Professor Wicker pointed to similar logic applying at lines 121ff and 126 of the Hytera code. In the absence of any explanation of this in Motorola's submissions, I am unable to determine from this evidence that these lines are objectively similar. Any attempt to understand this, would have required Motorola to deal with Hytera's submissions at [275]. 1431 Since Motorola bears the burden of proof I do not find that these are objectively similar. (b) Materiality 1432 Professor Wicker did not explain what the function erected by this functional code did: SBW-56 at §§25-26; SBW-61 at §§96ff. I am unable to determine the materiality of this file, and hence these lines of that file, to the EMT. Consequently, I do not conclude that these lines are material to the EMT. (c) Conclusions on rs_emt_handle_unused_input.c 1433 Motorola's claim in relation to this file fails. L. rs_emt_get_input_origin.c (a) Objective Similarity 1434 This file is not mentioned in either party's submissions. In SBW-57 Professor Wicker said that it had been copied into various versions of the Hytera file ps_app_mgr.cpp located in the RAF library directories, the Application directories and the AFP directory. I disregard the copying into the RAF directories since they were not subject to compilation. Of what remains, Professor Wicker did not provide a side by side analysis although he did refer me to two parts of the evidence where the source code for the versions in the Application directories was located although not the Motorola code. Mr Brown provided me with a side by side comparison in CMB-13 at p 203 of one of the versions in the Application directories. In that circumstance, I propose to rely on Mr Brown's version. The lines (which were identified Professor Wicker in SBW-57 at pp 35-36) are as follows: rs_emt_get_input_origin.c ps_app_mgr.cpp 1 76-134 152-202 1435 There have been changes to the function and variable names. According to Professor Wicker at SBW-56 at §27 there had been changes to the names of the functions and data parameters. These appear to me to be cosmetic. Professor Wicker also observed that the Motorola code used an 'if'/'else if'/'if' structure whereas the Hytera code used a 'switch' command. He thought these were structurally equivalent although there were some subtle differences. 1436 On the other hand, Mr Brown at CMB-13 at pp 203-204 thought that the difference was more than subtle. The difference he identified related not to how the logic operated but instead to how efficient the object code would be once compiled. He thought that the use of the 'switch' command resulted in more efficient object code. Professor Wicker did not respond to this in SBW-61. 1437 I accept Mr Brown's evidence that whilst the logic of the code is the same, the Hytera source code is compiled into more efficient object code. As such, I do not accept that objective similarity has been established. (b) Materiality 1438 Professor Wicker did not explain what this code did: SBW-56 at §27; SBW-61 at §§96ff. As such I do not know what this functional code does. Consequently, I am unable to assess either its materiality to the EMT or the materiality of these lines of code. (c) Conclusions on rs_emt_get_input_origin.c 1439 Motorola's infringement claim in relation to this file fails. M. rs_emt_imt_com.c (a) Objective Similarity Motorola's First Submission 1440 Motorola made two submissions about this file. The first was at fn 24 of MCS(C) Mod II(E). Footnote 24 was said to support this statement appearing at [47(b)]: 'As addressed further below, there is no debate as to the verbatim copying into intermediate files …'. Footnote 24 suggested that Mr Brown had accepted that there had been verbatim copying of this file at T588.36-589.4. At that part of the transcript, Mr Brown accepted that the Motorola file could be used as a template into which different values might be inserted. This has nothing to do with copying by Hytera into intermediate files. 1441 I do not accept that this evidence establishes that Mr Brown had accepted that this file had been subject to verbatim copying into a Hytera file. Motorola's Second Submission 1442 The second submission was in MCS(C) Mod II(E) at [53]. In this paragraph Motorola submitted that ps_imt.cpp was a file which contained [Redacted]. I accept this. 1443 Motorola explained that the [Redacted] in the Motorola file [Redacted]. 1444 Motorola submitted that [Redacted] had, by and large, been copied into the Hytera file in the RAF library directories: MCS(C) Mod II(E) at [54]. It submitted that the structure [Redacted] remained the same in the Hytera file although Hytera had customised [Redacted]. 1445 In support of its submission that the structure of [Redacted] was the same, Motorola pointed to the cross-examination of Mr Brown where he accepted this to be so at T592.13-24. Mr Brown accepted that the structure was the same: '… that's exactly right … but you're … right that the – the process to get there seems to be rather similar'. Motorola also relied on evidence from Professor Rangan at T594.28-595.12 in these terms: PROF RANGAN: … I think the words Mr Brown used, and maybe even the question used, was "a design choice", but this is going well beyond a design choice. Yes, one can copy the concept of [Redacted] in a certain manner, but this is not just copying that decision. It's not like they had that decision and then reimplemented everything from scratch. You have the whole framework on which this is built, which we're going to talk about, the EMT framework in the first place, the idea of [Redacted], the exact syntax of [Redacted], which means that the person, even if they're implementing it from that design choice, they don't have to debug anything … and [Redacted] was copied because they just copied the whole syntax. 1446 Turning then to the other evidence: 1447 In SBW-57, Professor Wicker said that the whole of this file had been copied into various versions of the Hytera file ps_imt.cpp located in the RAF, Application and AFP directories. He did not perform a side by side analysis. His evidence at SBW-56 at §30 was that the Motorola file defined [Redacted]. 1448 Mr Brown gave evidence at T585 which is in line with Motorola's explanation of [Redacted] I have set out above when dealing with its submission. I accept the correctness of that account although noting that it did not explain what [Redacted] to which it referred were. 1449 The cross-examination of Professor Wicker revealed that the Hytera version of [Redacted] had 307 lines which had been taken from approximately 1,000 lines of the Motorola file: T483.4-12. Professor Wicker described the process which had been undertaken as 'elective copying': T483.26-.28. Professor Wicker and Mr Brown gave evidence about this particular file together at T483-485. The effect of that evidence is that: Both the Motorola and the Hytera files create [Redacted] which [Redacted]. Both files contain this idea. Parts of the Motorola [Redacted] appear in the Hytera [Redacted] verbatim whilst other parts have been varied and there are parts which appear in the Hytera version which do not appear in the Motorola version. The Motorola and Hytera devices are not the same so it was inevitable that the [Redacted] would vary to some extent. 1450 Professor Wicker gave evidence that the version in the RAF library had been copied essentially verbatim. However, this version was not compiled. The likely course of events would appear to be that whoever wrote the Hytera versions which were compiled probably started with the version in the RAF library directories (which had been copied from the Motorola file) and thereafter made adjustments to it. For reasons already given, the state of this file in the RAF library directories is not directly relevant to Motorola's infringement suit since it was not compiled into the object code installed on Hytera's devices. 1451 Professor Wicker did not provide a side by side comparison of the file in either set of directories. Mr Brown did in CMB-13 although only in relation to 56 lines of what I infer was the 307 lines referred to by Professor Wicker above. In his reply evidence in SBW-61 Professor Wicker criticised the selective nature of Mr Brown's side by side analysis whilst still not proffering one of his own. At the end of the day, the only side by side analysis I have is Mr Brown's. 1452 Mr Brown identifies these lines in both files: rs_emt_imt_com.c ps_imt.cpp 1 186-201 7-31 2 1180-1219 373-400 1453 In the light of the cross-examination of Mr Brown and Professor Wicker, I will proceed on the basis that this is what the debate is about and that the versions of the Hytera file under discussion are those in the Application and AFP directories. 1454 Having examined them, the codes are quite different, at least on their face. My impression of Mr Brown's side by side comparison is that it shows that the codes are largely different. 1455 Professor Wicker also said that lines 187-1195 of the Motorola file defined a two dimensional array as did lines 10-317 of the Hytera file. Professor Wicker said that [Redacted], and [Redacted] have been copied, verbatim, including comments, into the Hytera file': SBW-56 at §30. I have examined the code. This does not appear to be correct. 1456 Professor Wicker also referred to lines 8-9 of the Hytera file. It refers to [Redacted] as the [Redacted] which, I accept, is Motorola's terminology. I am inclined to agree with Professor Wicker's evidence in SBW-56 at §§32-34 that whoever created the Hytera [Redacted] started with the Motorola [Redacted] (most likely through the vector of the template file in the RAF library directories) but that does not mean that these tracts of code are objectively similar. Whilst that may be where the author began it is not where he or she ended up. I also accept his evidence that the function names are, in some cases, very similar but, again, that does not establish objective similarity when one focusses on the nature of the [Redacted] created. As I have said, the array appears to be quite different. 1457 However, the main point, which still makes sense even in this maelstrom of disorder, is what Mr Brown said at T592.13-24: MR LANG: But the structure [Redacted] has remained the same, that is, it's [Redacted]. MR BROWN: That's correct. MR LANG: And the [Redacted] may produce different behaviour, but the structure has remained the same. MR BROWN: That's – that's exactly right. You end up with different behaviour. The – the devices, you would assume, would act differently, but you're – you're right that the – the process to get there seems to be rather similar. 1458 I accept this point. The [Redacted] has a particular structure which specifies [Redacted]. It takes the form of [Redacted]. Motorola's point is that it does not matter that Hytera has filled its version of [Redacted]. What has been copied is the structure of [Redacted]. Motorola also relied on the evidence of Professor Rangan referred to above who said that the 'syntax' of [Redacted] was the same. 1459 Whilst Motorola has actually made a submission about this file, its submission has not been particularly helpful beyond its submission about the structure [Redacted]. It has not identified the precise lines which it says have been copied nor those which have been modified nor those which are additional. Ultimately, its submission (and the evidence) left me with the impression that parts but not all of [Redacted] had been copied into a Hytera file in the Application or AFP directories. 1460 On the question of objective similarity its point was largely that the structure of [Redacted] was the same (its submissions did not identify [Redacted] which were the same although the submission assumed in some general way that this was the case). The structure submission should be precisely identified. What is involved is [Redacted]. Motorola's contention, based on the evidence of Professor Rangan, that the syntax of the Motorola and Hytera's [Redacted] is the same is correct, however, only insofar as the concept of syntax is understood to mean that what is involved is: [Redacted] 1461 I accept that the Hytera [Redacted] shares this structure with the Motorola [Redacted]. 1462 Making the assumption that Motorola also intended to rely upon the similarities in [Redacted], Motorola did not identify those similarities in its submissions. In order to be persuaded about this aspect of [Redacted], this would have required a somewhat deeper dive into the detail of [Redacted] than Motorola's submissions afford. For example, it might have been helpful to show what [Redacted] implied by the two sets of code look like. Even more helpful would have been a side by side comparison of [Redacted] mapping their similarities and differences. 1463 Without that I am forced back on to Mr Brown's side by side comparison of the codes. This is not especially helpful since the form of [Redacted] is obscured by the codes in which they are expressed. My impression, for what it is worth, is that they are quite different. 1464 My conclusion is this: it is not shown that [Redacted] are objectively similar. However, I do accept that the structure of [Redacted] is the same. Does this mean that the lines of code giving effect to [Redacted] are objectively similar? I have concluded that it does. In light of its concession, I find that Hytera copied the structure of [Redacted] although not its contents. (b) Materiality 1465 These questions are to be addressed by reference to what has been copied. In this case, it is the structure of [Redacted] and not its contents. I have no difficulty in concluding that the [Redacted] is a material part of the EMT. It resolves the important question of [Redacted]. However, what has been copied is not the [Redacted] per se, but rather the structure of [Redacted]. I am not persuaded that the structure of [Redacted] is material to the operation of the EMT even though I am persuaded that [Redacted] itself is. What is material to the EMT is [Redacted]. Inevitably this involves [Redacted]. The Motorola code has chosen to do this in the form of [Redacted]. However, it is not [Redacted] which is material. It is [Redacted] embodied in the [Redacted] which are material. (c) Conclusions on rs_emt_imt_com.c 1466 Motorola's infringement claim in relation to this file fails. N. rs_emt_imt_com.h (a) Objective Similarity 1467 Motorola did not refer to this file in its submissions. Hytera referred to it in Annexure A at p 93 of its closing submissions but not in a way which is presently pertinent. Professor Wicker said in SBW-57 that various lines of code in this file had been copied into various versions of the Hytera file ps_imt.h. These versions were located in the RAF library, Application and AFP directories: SBW-56 at §36. I will disregard the versions in the RAF libraries which were not compiled. In relation to the remaining versions, Professor Wicker did not conduct a side by side analysis although he did provide a reference to where these source codes might be found in the evidence: SBW-56 at §36. No submission was developed as to how I might conduct a side by side analysis without the assistance of computer software. 1468 In CMB-13, Mr Brown conducted a side by side analysis of a code which he said was located in document CONF.001.001.4473. By comparing this to the Hytera source code reference given by Professor Wicker in SBW-56 I conclude that the file Mr Brown was looking at was the version in the Application directories. Mr Brown's side by side analysis identified these lines of code: rs_emt_imt_com.h ps_imt.h 1 77-89 9-28 2 91-115 30-56 3 121-124 60-63 1469 This is the version in the second entry in Professor Wicker's table in SBW-57. I am unable to assess the others since I have not been provided with a side by side analysis. 1470 My unskilled impression is that these codes are different. Mr Brown said that the only thing they had in common was the name of the [Redacted] . Professor Wicker's evidence about this was in SBW-56 at §37: [Redacted] 1471 I do not understand this evidence and Motorola's submissions did not explain it. Consequently, I am not persuaded that they are objectively similar. (b) Materiality 1472 It is not necessary to reach a view on this. (c) Conclusions on rs_emt_imt_com.h 1473 Motorola's infringement claim in relation to this file fails. O. rs_emt_acrt.c (a) Objective Similarity 1474 Motorola made no submissions about this file. Professor Wicker's evidence about this was in SBW-56 at §§65-68. His identification of the lines of code in this file said to be copied was in SBW-57 at pp 38-40. Professor Wicker included no side by side analysis. His evidence was that lines of the Motorola file had been copied into various files in the RAF, Application and AFP directories. 1475 Mr Brown's side by side analysis was at CMB-13 at pp 244-253. It is apparent from Mr Brown's analysis that he used the Hytera source code at CONF.001.002.4772. From Professor Wicker's evidence in SBW-56 at §65 it is apparent that this is the version of the Hytera file that is in the RAF library directories and hence not subject to compilation. As such there is no point determining whether the lines are objectively similar since the Hytera object code cannot be a direct adaptation of them. 1476 Consequently, I do not have a side by side comparison of any of the source code which was compiled. I do have Professor Wicker's comments in SBW-56 at §§65-68 and Mr Brown's comments at CMB-13 at p 250. His comment was that lines 40-268 were simply an array full of zeroes. Professor Wicker did not respond to this in SBW-61. 1477 I am not prepared to act on this evidence where I have neither a side by side comparison of the code nor any submission by Motorola. Having read Motorola's submissions and its evidence, I am not affirmatively satisfied that objective similarity has been established. (b) Materiality 1478 It is not necessary to determine this. (c) Conclusions on rs_emt_acrt.c 1479 Motorola's infringement suit fails in relation to this file. P. rs_emt_adt.c (a) Objective Similarity 1480 Motorola did not make any submission about this file. Professor Wicker's evidence about this file was in SBW-56 at §69 where he dealt with the position of the copying of this file into files located in the RAF library directories and at §70 where he dealt with the copying of this file into files located in the Application and AFP directories. His identification of the lines of code said to have been copied was in SBW-57 at pp 40-43. Professor Wicker did not provide a side by side analysis. Mr Brown provided a side by side analysis of one of the files at CMB-13 at p 254. Mr Brown says that he conducted his side by side analysis on the Hytera file CONF.001.002.2594. From Professor Wicker's evidence in SBW-56 at §69 it is apparent that this is a print out of the source code for a file in the RAF library directories. Since these were not compiled into the Hytera object code they have no immediate relevance. 1481 I therefore do not have a side by side analysis for the versions of the Hytera files that were compiled, that is to say, the versions in the Application and AFP directories. 1482 Motorola made no submissions about this file in relation to objective similarity. It implicitly mentioned the file in its reply submissions at [59] in response to a submission from Hytera that the Motorola file had been auto-generated by a computer. That topic relates to the question of originality. However, on the question of objective similarity, the only material I have is Professor Wicker's evidence in SBW-56 at §70. He provides three references for the location of the Hytera source code for versions of this file in the AFP and Application directories. An examination of these print outs is not fruitful. For example, the source code for the file in the Application directories at CONF.001.001.8716 is a 17 page print out of 1,178 lines of C++ code. It is single spaced. At the same time, Professor Wicker did not provide me with the reference for the source code for the corresponding Motorola file. 1483 Consequently, I am unable to assess Professor Wicker's evidence in SBW-56 at §70. The matters he points to in that paragraph are by way of 'example' from which I assume I am invited to reason that other examples may be found. I decline the invitation. 1484 Since Motorola has made no submission about this file and because I decline to conduct a side by side analysis of competing C++ codes myself, I have no view as to whether the lines of the Hytera files in the Application and AFP directories are objectively similar (nor do I know where the Motorola source code is). Having read the evidence and without the benefit of submissions from Motorola, I conclude that the fact that I have no view necessarily implies that Motorola has failed to discharge its burden of proof in relation to objective similarity. I therefore do not conclude that the Motorola files identified in SBW-57 at pp 40-43 are objectively similar to the Hytera files identified in the same place. (b) Materiality and Originality 1485 Professor Wicker did not explain in SBW-56 at §§69-70 what this file did. Nor did he do so in SBW-61 at §§96ff. As such I do not know what this file does. Consequently, I am unable to assess its materiality to the EMT still less the materiality of lines identified by Mr Brown. I do not find that the lines relied upon by Motorola were material to the EMT. 1486 In relation to originality, if it had arisen, it appears that this file was written by a computer, that is to say, generated. In MCS(C) Mod II(R) at [59], Motorola submitted in relation to the topic of auto-generated files that these files contained data which was put together from other meta-files by scripts written in Perl language. The meta-files were put together by its developers. The Perl language scripts were tools which allowed the developers to choose which form the data would be represented in. This is not therefore a case where the substance of [Redacted] involved have been generated by a computer. This may be contrasted with the position of the Yellow Pages directories in Telstra Corporation Limited v Phone Directories Company Pty Ltd [2010] FCAFC 149; 194 FCR 142. I reject Hytera's submission that the lines are not original by reason of their auto-generation. (c) Conclusions on rs_emt_adt.c 1487 Motorola's infringement suit fails in relation to this file. Q. cor_single_linked_list.h (a) Objective Similarity 1488 Motorola made no submissions about this. Professor Wicker's evidence about this file was in SBW-56 at §38. He identified the relevant Hytera files in SBW-57 at p 43. Having regard to Professor Wicker's evidence in SBW-56 at §19, it is unclear to me what the significance of the location of the Hytera file is. Since the directory nominated does not match the directories Professor Wicker identifies as the RAF library directories, I will proceed on the assumption that the identified Hytera file was, in fact, compiled into Hytera's object code (and hence can be accommodated into the structure of Motorola's adaptation case). 1489 Professor Wicker says that the nominated Hytera file, SingleLinkedList.h is 'almost identical to the Motorola file': SBW-56 at §38. He does not provide a side by side analysis. He does not identify where the competing source codes are in the evidence. Motorola's submissions do not mention this file and whilst Hytera's submissions do refer to it at [54(a)] and p 76, they do not do so in a way which advances the present debate. 1490 Mr Brown conducts a side by side analysis in CMB-13 at pp 207-210. Having examined Mr Brown's side by side analysis, I am not satisfied that objective similarity is established. I take Professor Wicker's point about the targetNode, inputNode, cor, COL_, singleListNode_t, and listNode_t. However, that evidence is not sufficient for me to assess the significance of the differences which Mr Brown's side by side analysis demonstrates. It may well be that Professor Wicker is correct. However, his explanation is insufficient for me conclude that objective similarity is established. Much more by way of explanation was needed. No explanation appeared in Motorola's submissions. (b) Materiality 1491 Professor Wicker did not indicate what the source file to which this header file relates did: SBW-56 at §38; SBW-61 at §§96ff. I cannot therefore assess the materiality of the functional code and, therefore, the materiality of this header file. Consequently, I do not find that the lines identified by Mr Brown are material to the EMT. (c) Conclusions on cor_single_linked_list.h 1492 Motorola's infringement case in relation to this file fails. R. rs_application_id.h (a) Objective Similarity 1493 Motorola did not make a submission about this file. Professor Wicker identified the competing Motorola and Hytera files in SBW-57 at pp 50-51 and gave evidence about them in SBW-56 at §§73-74. His evidence at §73 concerned the version of the Hytera file ps_application_id.h in Hytera's RAF library directories which was not compiled and which is not directly relevant. He gave evidence about two versions of ps_application_id.h in Hytera's Application directories. He did not provide a side by side analysis of the codes. He did give a reference for the location of the Hytera files in the Application directories. 1494 Mr Brown conducted a side by side analysis in CMB-13 at pp 261-265. He said that this had been conducted by reference to the Hytera source code file at CONF.001.001.4421. Comparison with Professor Wicker's evidence at SBW-56 reveals this to be the source code for a version in the Application directories (hence subject to compilation and therefore relevant). 1495 An initial assumption by me that Professor Wicker's evidence about the similarities between the Motorola file and the Hytera file in the RAF library directories could be transferred across to the Hytera versions in the Application directory has proven incorrect. In the RAF library directories version, contrary to Professor Wicker's evidence in SBW-56 at §73, lines 7-19 of the Hytera file are not identical to lines 149-161 of the Motorola file. I also do not accept that lines 10 and 19 reveal erroneous references to Motorola files: SBW-56 at §73. It is not necessary to investigate further the status of the RAF library versions since they were not compiled. Their only relevance was to the extent that something could be obtained from them derivatively for the versions in the Application directories. That does not appear to be possible. 1496 Professor Wicker said in relation to the versions in the Application directories, that the Hytera file had a list of application IDs which had been inserted into it which were not found in the Motorola file. Mr Brown agreed with this. Professor Wicker noted a placeholder comment in the Hytera code for the version of this file in the RAF library directories with an invitation to the programmer to include such a list (recalling the RAF library versions were used as templates from which other Hytera files were then developed and were not themselves compiled). In the version of the file in the Application directories, Professor Wicker says that the invitation has been accepted and that a list of application IDs has been inserted. 1497 Motorola made no submissions about this file or these lines save in one respect. This was implicitly in its submissions in reply dealing globally with Hytera's contention that various files (including this one) were auto-generated by a computer program and could not be original: MCS(C) Mod II(R) at [59]. That is not presently relevant. 1498 Unassisted by Motorola, I have examined the side by side analysis proffered by Mr Brown. I accept his evidence that they bear little resemblance to each other. Not knowing what the file is intended to achieve since Professor Wicker has not explained it, I conclude that these are not shown to be objectively similar. (b) Materiality and Originality 1499 This is a header file. Professor Wicker did not indicate what the functional code to which it related did. As such I am unable to assess whether the functional code is material to the EMT. I am therefore unable to assess whether this associated header file is material. 1500 As to originality, for the reasons I have given already, I reject Hytera's submission that the fact that this header file was generated by a Perl script means that the file is not original. (c) Conclusions on rs_application_id.h 1501 Motorola has not demonstrated this aspect of its infringement case. S. rs_uiopcode_list.h (a) Objective Similarity 1502 Motorola made no submissions about this file. Professor Wicker identified the relevant files in SBW-57 at p 52 and gave his substantive evidence in SBW-56 at §75. He said that lines 9-13 and 40-41 of the Hytera file ps_uiocode_list.h were identical to the 'corresponding lines' in the Motorola file (without identifying those lines). This was in relation to the version of the Hytera file which was in the RAF library directories and which was not compiled. For reasons I have already given, this means it is not directly relevant. He also said the UI opcodes were identical to a subset in the Motorola file. He did not explain what a UI opcode was. He said that the enumeration containing the opcodes remained the same in the version in the Application directories. He did not provide a side by side comparison. 1503 Mr Brown did a side by side comparison in CMB-13 at pp 265-269 by reference to the version in the Application directories. He thought, at p 269, that the two files bore little resemblance to each other. 1504 Neither party made any submission about this file. 1505 Professor Wicker's observations about lines 9-13 and 40-41 of the Hytera file cannot be assessed because they are not in Mr Brown's side by side analysis of the Application directories version of the file, and Professor Wicker neither provided one nor identified where I might find the 'corresponding' Motorola source code. 1506 Having examined the evidence of Professor Wicker, Mr Brown and Mr Brown's side by side analysis, I am not satisfied that these are objectively similar. (b) Materiality 1507 For the reasons I have given in relation to rs_application_id.h I do not find that the nominated lines of code are material. (c) Conclusions on rs_uiopcode_list.h 1508 Motorola has failed to establish this aspect of its infringement case. 6. CONCLUSIONS ON OBJECTIVE SIMILARITY IN RELATION TO THE SECOND TRANCHE 1509 Motorola's case in relation to the files in the Second Tranche fails. 7. THE DISASSEMBLED CODE EXTRACTED FROM THE OBJECT CODE IN THE SECOND TRANCHE 1510 Motorola did not identify the files from which copying was said to have occurred or the lines which were alleged to have been copied. From CMB-25 at p 21 I have determined that there are 13 such files as follows (being those identified by Mr Brown as being discussed by Professor Wicker in SBW-59 or SBW-64): com_ergo_platform_utils.c cor_emt_acrt.c cor_emt_adt.c cor_emt_app_interact_mgr.c cor_emt_application_manager.c cor_emt_init.c cor_emt_pending_queue_services.c cor_emt_process_xlate_inputs.c cor_emt_task.c cor_emtds_acbl_services.c svc_applications.c svc_interact_mgmt_services.c cor_single_linked_list.c 1511 In relation to all of these files apart from the last one, Motorola alleges that every line of each file has been copied: Confidential Annexure 2 at pp 42-44. Motorola alleges that this copying occurs in the Hytera file raf_arm9.lib. The code contained in that file is object code. Motorola's case is that this object code is an adaptation of the source code files in question (this is necessary since, as I have earlier explained, the object code cannot be a reproduction of the source code). 1512 In relation to the last file cor_single_linked_list.c Motorola initially alleged that the entire file had been adapted into the object code located in Hytera's library files cpa_arm9.lib and cpa_c55.lib. However, on the eve of the trial Hytera discovered the source code for its file SingleLinkedList.cpp. As a matter of taxonomy, it might have been included in the first section dealing with those cases where the source code was available. However, the fact that it emerged in the wake of the debates arising from the discovery of the library files means that it has a different evidentiary arc to the other available source code files. For that reason, I deal with it separately after raf_arm9.lib. T. raf_arm9.lib (a) Objective Similarity 1513 Motorola's submission in MCS(C) Mod II(E) at [63] suggested that the source code from which this library file had been compiled was not available. This was Hytera's position in HCS(C) Mod II at [253]. Yet in Motorola's submissions at [79] it referred to the evidence of Professor Rangan who suggested that some source code had become available for this library file. It is possible this is an erroneous reference to the cpa_arm9.lib although it may also be a reference to cor_single_linked_list.c (the source code for which did become available in the Fourth Tranche of discovery). On the other hand, in SR-22 at §§149-150, Professor Rangan gave an elaborate description of the source files associated with raf_arm9.lib. Motorola did not develop a submission about these source files and a case on them is inconsistent with what it says at [63] of its submissions. I have concluded that I should accept Motorola's submission at [63] and therefore proceed on the basis that the source code is not available. 1514 Motorola's submission about raf_arm9.lib did not descend to the detail of the EMT but was pursued, instead, as a global submission about all 11 works. Motorola did not identify the essential features of this global argument in any convenient location. However, it appears to me that its argument had the following elements: (i) Although the source code from which raf_arm9.lib is unavailable, a patent attorney, Mr Hayes, had exposed the object code contained within it to a process of disassembly. In the entrails of that process, Mr Hayes found function names. Professor Wicker was provided with these function names. He expressed the opinion that they were the same as, or very similar to, function names which appeared in Motorola's source code. He thought it likely that the source code from which the object code had been compiled had been copied from Motorola's source code. (ii) It was to be inferred from the extent of copying which had otherwise been demonstrated in relation to the available Hytera source code that copying on the same scale was likely to have occurred in the missing Hytera source code. (iii) There was evidence that the state of the development of Hytera's DMR project was in disarray as at the start of 2008. From this it could be inferred that Hytera had a motive to steal Motorola's intellectual property. Its motive was to avoid either the commercial failure which the then stage of its development would have entailed or a delayed entry into the market place if the problems within its DMR project were resolved legitimately. (iv) There was evidence that Hytera's computer engineers had access to confidential Motorola material including its source code. (v) There was evidence that the fact that the Hytera source code was not available was the result of a deliberate course of conduct by persons within Hytera whose purpose was to frustrate any copyright infringement proceedings. (vi) There was evidence that the Hytera computer engineers involved in the creation of the missing source code had set out deliberately to copy Motorola's source code and then make it appear that it had not been copied. (vii) It was to be inferred from the speed with which Hytera's DMR project was brought to a rapid conclusion that it must have done so by the use of Motorola's source code. (viii) Hytera called no one who was involved in the writing of the source code. An inference was to be drawn against Hytera that the evidence of these persons would not have assisted its case. 1515 The nature of this case is circumstantial although Motorola did not use this terminology. It is not possible directly to determine whether the Hytera source code is objectively similar to the Motorola source code since it is not available. Motorola's contention is that it should be inferred from the available circumstances that it is objectively similar. To bring the debate back to the files above, the contention is that it should be inferred that the missing source code contains lines of code which are objectively similar to the lines of code appearing in those 12 files. 1516 I will deal with issues (i)-(viii) in that order. Having done so, I will then consider whether the circumstantial case is made good in relation to the 12 files which appear to be involved. (i) The Disassembled Object Code 1517 Mr Hayes was provided with raf_arm9.lib. He applied a disassembly program, IDA Pro, to raf_arm9.lib and as a result produced screenshots of disassembled object code which became Confidential Annexure BJAH-3. At §77 of SBW-56, Professor Wicker explained disassembled object code. Effectively, the machine language in the object code was rendered into lower level assembly language. As he explained, there are difficulties with this process and, of course, the assembly language code in no way resembles the source code to which it relates since it is composed of the low level instructions given to the processor. 1518 Professor Wicker also explained that the process of disassembly was imperfect and that what one got out of the process rather depended on the kind of compiled code being disassembled. Here the compiled code was not the object code which had been installed as firmware in the Hytera devices. It was instead a step before that and consisted of the library file which had been generated by the compiler. 1519 Professor Wicker did not explain the implications of the difference but his evidence shows that, at least in this case, the compiler was fed a file in source code (ending in .c, .cpp or .h). From each source file (.c or .cpp) a fresh file with the same name was generated but now ending in .obj (for object code). It is important to emphasise that this is a file on a computer and not binary code installed on a device. Whilst the contents of the file can be installed on a device as binary code, the file itself can be read by a text editor: SBW-56 at §78. 1520 Professor Wicker then explained what he derived from BJAH-3. The first step was that IDA Pro was applied to open the raf_arm9.lib library file itself. This produced a list of partial file names. Where the file designation is visible it is .obj. Comparison between the partial Hytera file names in BJAH-3 (disregarding the file designation) and the list of Motorola files is strongly indicative that the library file contains files of object code with the same name as the nominated Motorola source code files. 1521 Mr Hayes was then able to click on each of the retrieved file names. For example, the first file name in the list was the partial file name com_ergo_platfo. When Mr Hayes clicked on that file, IDA Pro brought up another screen which showed what the disassembler had obtained from the object file. On the window 'IDA View-A', there is a smaller window entitled 'Function window'. For the first file, com_ergo_platfo, it lists a function name 'corUtilSortButtonDefsByBco(radioHardwareBu'. It is apparent that the full name has been cut off by the side of the window. However, Mr Hayes has then opened the function window more fully and the full function name can be seen on the next page. 1522 In addition to retrieving the function names, IDA Pro also provided the output from a window marked 'Exports'. This output includes identifier names that are made available to other files and not only the file in question. These identifiers could include function names but also names for variables or constants made available to other files. Professor Wicker noted that the function names could appear in both the 'Functions' window and the 'Exports' window: SBW-56 at §80(b). 1523 The same process has been repeated for all of the files which appeared on p 24 of BJAH-3. Professor Wicker looked at this material and at §81 said that it was immediately apparent to him on doing so that a number of the partial function names he saw were very similar to function names he had observed in Motorola's source code. Motorola's solicitors then cross-referenced the partial file names and function names retrieved by IDA Pro against Motorola's source code. By doing so they were able to identify the Motorola file names which matched the Hytera partial file names. They also located where in the Motorola source code the same function names appeared as those retrieved from the library file. 1524 This was then tabulated into SBW-59. In the left column, each Hytera partial file name appears and beneath it the function names retrieved by IDA Pro. In the right column, the corresponding Motorola file name appears and where there is a matching function name, that is set out under the file and lined up with the Hytera function name. For example, taking the first entry in SBW-59, Mr Hayes and Professor Wicker have together identified this function name in the Hytera object code: corUtilSortButtonDefsByBco(radioHardwareButtonConfig_t *) 1525 This may be compared with the name of the corresponding Motorola function: [111] void parm1( corUtilSortButtonDefsByBco,radioHardwareButtonConfig_t *buttons ) 1526 Professor Wicker did not attempt to group this analysis by reference to any of the 11 works, including the EMT component. Using CMB-25 at pp 20-21, I accept each of the files Mr Brown identifies in as being part of the EMT and that those that are 'Source to Binary' files may be found in Professor Wicker's SBW-59 as a file name in the right hand column. 1527 I accept that in relation to these 12 EMT files, Motorola has shown that function names in the disassembled Hytera object code are similar to or the same as function names which appear in each of the 12 Motorola files. I infer that the missing source code therefore also used function names which were similar to or the same as the function names appearing in the 12 EMT files. 1528 I note Professor Wicker's view and Professor Rangan's opinion that these similarities mean that the missing Hytera source code was copied from Motorola's code. Professor Rangan's opinion was in part based on his analysis of the history of how the missing source code was developed and, in particular, his view that Hytera's engineers had set out to copy the Motorola source code and then conceal that fact. I propose to deal with that issue myself and do not think that Professor Rangan's views about the matter are directly useful. In my view, Professor Wicker and Professor Rangan's evidence is helpful on the question of the extent of the similarities between the Motorola and Hytera source codes but how those similarities interact with the balance of Motorola's circumstantial case is a matter for the Court. I do nevertheless accept as useful Professor Rangan's evidence about what normal software development looks like and how far from normal Hytera's software development practices were: SR-22 at §78(c). 1529 On its own I would not accept that the fact that the function names retrieved from the disassembled object code were the same or similar to the function names in the Motorola code was sufficient to draw an inference that the missing source code was objectively similar to the Motorola source code. This was Mr Brown's view in CMB-3 at §185. There are, as he observed, examples in the evidence where Hytera functions with similar names to a Motorola function turn out to be different. The example he proffered was the Hytera function psRafLoadInitModeInfo which has a similar name to the Motorola function, rsEMTLoadInitModeInfo: CMB-3 at §185. Mr Brown observed that the Hytera function was empty whereas the Motorola function contained 50 lines of code. 1530 More generally, in the course of preparing these reasons I have seen numerous examples where available Hytera source code (including header files) have involved the adaptation of Motorola source code by the act of deleting tracts of the Motorola source code. In some cases this has been entire tracts of code, in others it has involved retiring the functional code into comments in the Hytera souce code. Mr Brown's example is not, therefore, an isolated one. Partly, this phenomenon can sometimes be explained on the basis that the Hytera source code is more simplified than the Motorola source code. The functionality which its authors set out to achieve is less complex than what the Motorola version achieved. It is also to be explained because, as I will shortly outline, the persons writing the missing Hytera source code deliberately set out to make it look different to the Motorola source code. 1531 These kind of differences do not persuade me that the Motorola source code was not the basic material from which the missing Hytera source code was fashioned. But it is one thing to say that the missing source code was fashioned from the Motorola source code and another to say that any particular Motorola file is objectively similar to a file with a similar name in the missing Hytera source code. 1532 Motorola's response to this problem was to point to several surrounding circumstances to buttress this case. The first of these was the extent of copying which had been demonstrated in Hytera source code which is available. (ii) The Extent of Copying in the Available Hytera Source Code 1533 As will be seen from the reasons which follow, most of Motorola's case on infringement is rejected for a variety reasons. 1534 Nevertheless, I am satisfied that Motorola has demonstrated that on some occasions, Hytera's available source code is objectively similar to Motorola's source code and hence, in light of Hytera's concession, copied. However, in the case of the available Hytera source code, much of which consists of header files, this is not universal. 1535 Motorola nevertheless referred to 'wholesale' copying by Hytera. However, the word wholesale is not apposite for what has been demonstrated with the available source code. A more accurate global description of what has been demonstrated about the available Hytera source code is that there are instances where it is clear that the persons who wrote it copied Motorola's source code and, in some circumstances, did so verbatim. It may therefore be inferred, and I find, that in the development of the firmware for its DMR devices, Hytera's software engineers sometimes engaged in the copying of Motorola's source code. (iii) The State of Development of Hytera's DMR Project 1536 I have dealt with this in Chapter VIII where I concluded that at the end of 2007 Hytera's DMR project was in disarray and something had to be done. I conclude therefore that Hytera had a motive to steal Motorola's intellectual property. (iv) Hytera's Computer Engineers Had Access to Motorola's Confidential Information 1537 In SR-22, Professor Rangan collected a number of documents which were in the possession of Hytera which can only have come from Motorola. One of these documents, for example, is the Darwin Ergonomics Platform Architecture Document referred to above as well as other documents which clearly indicate much more than a passing familiarity with the DSP Firmware. The evidence does not show directly that Hytera was in possession of all of the source code for the mobile, portable and DSP Firmware. In the next section I will deal with the three laptops of Ms Peiyi Huang, an ex-Motorolan who worked for Hytera. Material retrieved from these three laptops shows that they contained 544 source code files that were identical to files in the Motorola Mobile Firmware: MCS(C) Mod III at [17]. The available inferences about this are that the ex-Motorolans brought with them a limited subset of the Motorola source code or that they brought with them all of it. 1538 What inference should be drawn? Two facts are established. Source code was brought from Motorola by the ex-Motorolans and some of that source code was used by them to assist in writing Hytera's code. From these facts it is open to infer that the code was brought by them for the purpose of copying. I draw that inference. Since it cannot have been clear to the ex-Motorolans at the outset how much source code they were going to need, it seems to me inherently more likely that they would have brought all of it. I therefore infer that the ex-Motorolans brought with them all of Motorola's source code both for the Mobile and Portable Firmware and also the DSP Firmware. Since what is involved in that conclusion involves the proposition that the ex-Motorolans engaged in intellectual property theft of the most serious kind, it is appropriate to reflect on the seriousness of that conclusion before reaching it. Here the thinking is that the more serious the misconduct alleged, the less likely in the ordinary course of human affairs it is that such conduct would be engaged in. In this case, that reflection does not alter my conclusion: the ex-Motorolans took all of the Motorola source code and did so to provide themselves with a resource from which they could later harvest that code for the purposes of writing Hytera's source code. 1539 More particularly in relation to EMT, it is clear that Hytera's computer engineers were in possession of detailed components of it. For example, an email dated 20 July 2009 shows that Hytera was attempting to understand the thread structure of the five core components of the Darwin Ergonomics Platform (referred to above) including the EMT, UIQ and Xlate: SR-22 at §133. And, a document of 9 December 2008 shows that Hytera was engaged in 'UIT migration and organization' which would appear to be a reference to using Motorola's UIT for Hytera's own code: SR-22 at §138. (v) Deliberate Suppression of Source Code 1540 This brings me to the laptops of Ms Peiyi Huang and the failure of Hytera to discover the source code underpinning some of the library files, including relevantly raf_arm9.lib. As I will now explain in detail, the evidence satisfies me that at some point, Motorola's source code was present on one of Hytera's servers but has subsequently been deliberately deleted. I am satisfied that this was done by or at the instigation of the ex-Motorolans (and, perhaps, at least two others) and does not reflect any attempt by Hytera's management not to give proper discovery. 1541 Ms Peiyi Huang was formerly employed by Motorola but was recruited by Hytera in February 2009: MCS(C) Mod III at [17]. Ms Peiyi Huang reported to Mr Chia throughout her time at Hytera: MCS(C) Mod III at [17]. She led the group responsible for developing the software for the host processor from early 2009: MCS(C) Mod III at [27]. Her employment at Hytera ended on 28 July 2018: MCS(C) Mod III at [17]. 1542 After this proceeding had been commenced but before she left Hytera, Ms Peiyi Huang was instructed by a Mr Luo, the Manager of the Technology, Patents, Strategy and Price Management Department at Hytera, not to delete or to dispose of any information or documents that could be relevant to the dispute with Motorola: Luo-5 at §12. Mr Luo is the person at Hytera who was put in charge of complying with Hytera's discovery obligations. On 22 November 2017, Ms Peiyi Huang was instructed to provide all her Hytera computers to the IT department for imaging. It has transpired that she had three laptops. In response to Mr Luo's instruction she produced, however, just one laptop, numbered HYT153209. The laptop was sent to an external firm, Epiq, for imaging. 1543 In November 2018, Mr Luo recovered a further laptop of Ms Peiyi Huang's: Luo-5 at §14. This laptop was numbered HYT141896. Mr Luo said that it had been reassigned to another employee. Once Mr Luo became aware of its existence it was immediately sent to Epiq for imaging and document processing. 1544 In the same month, Mr Luo also determined that a third laptop which had been used by Ms Peiyi Huang was located in Hytera's fixed asset warehouse: Luo-5 at §15. It was numbered HYT109495. Mr Luo retrieved it and provided it to Epiq for imaging and processing. 1545 There are therefore three laptops of Ms Peiyi Huang: (a) HYT153209 ('Laptop #1'); (b) HYT141896 ('Laptop #2'); and (c) HYT109495 ('Laptop #3'). 1546 Hytera provided discovery from all three laptops. It is Laptop #3 which is relevant to the present discussion. Many files were unable to be retrieved from the laptop: MCS(C) Mod II(C) at [52(c)]. However, a forensic log of this laptop is available which reveals what was once on it. The forensic log is contained in an Excel spreadsheet (C14.192) which contains 130,831 rows. 1547 So far as the EMT is concerned, it is apparent that most of the EMT was at one time present on Laptop #3. The EMT contains 151 files: CMB-25 at p 20. Amongst the 130,831 rows, there are 424 rows which contain references to the EMT including what appears to be a large number of the files making up the component. 1548 Motorola's submissions about Laptop #3 were not focussed on the 11 works in suit. It did not seek to develop submissions about the works or the files comprising them. Instead, it sought to demonstrate that at one time, there had been a Hytera server referred to by the file directory '\SVN'. It is plain from the forensic log that at one time Laptop #3 contained a series of sub-directories beginning with '\SVN\CPA' and that there are many examples in these directories in which Motorola file names appear. For example, in the directory \SVN\CPA\raf_core\emt, there appears the file name cor_emt_adt.cpp. This of course is the name of a source code file which is missing. The presence within it of an identifiable source file from within the EMT is evidence, although not conclusive evidence, that the Hytera source code was copied directly from the Motorola code. It is not conclusive because it does not, in itself, exclude the possibility that although the file name was not changed some of the code within it may have been. 1549 Turning then to what \SVN signifies, there appear to be three sources of evidence. First, Professor Sun accepted at T1162.25-36 that the practice within Hytera whilst he was in charge was for persons working on the source code to upload it to a server known as the SVN server. Secondly, there is an email from December 2008 from Yang Shuangfeng to Xiong Weiming, Ruan Hanchun and YT Kok which contains inter alia the statements 'the code has been uploaded to the SVN': MCS(C) Mod II(C) at [58(e)]; SR-44 at p 302. Thirdly, Mr Luo gave evidence that SVN is a piece of computer software available on the market: T800.3-9. His answer bears setting out: THE INTERPRETER: I do not agree with what counsel said. According to my understanding SVN is a piece of computer software that is available on the market. It is a piece of software, it doesn't necessarily mean that it refers to a centralised server at Hytera. Anyone can install that software on their computer. According to my understanding it will not necessarily mean – and I'm not sure about that – that it allows you – or it refers to a local copy on the computer of what it has stored on the SVN. 1550 This contains two ideas. One is that SVN is piece of software. The other is that this software allows one to store a local copy of the SVN onto the computer in question. In light of Professor Sun's evidence and the email, it seems to me to be unarguable that there was not a server known as SVN to which files were uploaded. I therefore reject this aspect of Mr Luo's evidence. I conclude that there was a server at Hytera known as the SVN server. 1551 It was not put to Mr Luo that Hytera had failed to discover the contents of SVN directory on its server. I accept that this is so. However, the fact is that it has not been produced. I conclude that the SVN directory on the Hytera server was deleted by the ex-Motorolans. 1552 As this point, confusion enters the picture. In MCS(C) Mod III at [72], Motorola referred me to the evidence of Professor Rangan in SR-22 at §90 which was to the effect that 'the underlying source code used to compile certain library files was not stored on Hytera's SVN server'. However, this evidence reflects a recitation of a Hytera affidavit which was not read. In any event, the particular library files are not identified. I am unable to say whether what Professor Rangan said applied to the file raf_arm9.lib (the library file here under discussion). On the other hand, in MCS(C) Mod II(C) at [52(c)(i)], Motorola submitted that the SVN folder path on Laptop #3 contained the names of 'Hytera source code files used to compile libraries which have since gone "missing"' although this was not accompanied by any reference to the evidence. Given the morass of material, there is no feasible way for me to work out the answer to this conundrum. I am unable to determine this matter. 1553 In any event, it is not necessary to do so. I accept Motorola's submission that whatever was in the SVN directory on the server has been made to disappear. The same may be said for each of the three laptops which appear to have been reformatted: T800.32-39. I therefore accept as a general proposition that much of the evidence which would have thrown light on this infringement suit has been lost. I am unable to conceive of a legitimate reason why this would have been done. Whilst I accept that Mr Luo did his best with discovery, the difficulty here is upstream from Mr Luo. I conclude that a deliberate attempt to suppress evidence which might assist in an infringement suit was embarked upon and was, to a considerable degree, successful. (vi) Deliberate Concealment of Copying 1554 Two matters lead me to accept Motorola's submission about this. As I now explain, there is: (a) explicit evidence that Hytera personnel set out to disguise the fact that they were copying Motorola's files; and (b) there is explicit evidence that source code was distributed between the engineers working on it by email rather than being stored on the central server. Dealing with each in turn: 1. AN INTENTION TO DISGUISE THAT COPYING WAS OCCURRING 1555 Professor Rangan gave some examples of internal communications at Hytera which indicated that its computer engineers were repurposing Motorola source code and then attempting to disguise this fact. For example, an internal task list was circulated within Hytera in 2009 which took the form of an Excel spreadsheet: SR-22 at §103. Row 38 was as follows: 1556 'YT' is Mr YT Kok. The reference to 'GCISS' is a reference to the Consumer, Government and Industrial Solutions Sector which is a division within Motorola. The document speaks for itself. It involves an active contemplation of using library files to lower the risk of detection in the event that the code was disassembled. 1557 Row 133 of the document is as follows: 1558 Professor Rangan thought, and I agree, that this task was discussing the risk of detection by Motorola of copying. By itself, it might have been a little equivocal, but read with Row 38 I think that it becomes clear that this is precisely what the document is talking about. Combined with the fact the case under consideration concerns precisely Motorola's attempts to win something from the rubble of the disassembled object code, the document is not only eloquent but, in a sense, prophetic. 2. Distribution of Source Code between Engineers by Email 1559 The evidence establishes to an extent that software engineers within Hytera distributed source code between each other via email rather than through uploading it to the SVC server although in some cases the evidence is a little unclear. 1560 There was an email chain between Peiyi Huang, Wang Fei and Ni Huang between 20-21 April 2009. I have dealt with the three laptops of Ms Peiyi Huang above. Ms Ni Huang is not an ex-Motorolan and she remains employed by Hytera. She identified herself in an affidavit of discovery as 'the person at Hytera who is responsible for managing the radio frequency hardware abstraction layer (defined as "RF HAL")'. She also said that she had been 'unable to clarify what has become of the RF HAL Source Code, or the date that it was written': MCS(C) Mod II(E) at [70]. 1561 Ms Peiyi Huang sent a library file to Wang Fei, which is then forwarded to Ms Ni Huang, attaching a library file entitled rfhal_c55.lib. This library relates to the L1 Timer sub-system which I discuss later in these reasons. There is confusion in the evidence as to whether rfhal_c55.lib was a library of uncompiled source code or a library of compiled object code. For example, in MCS(C) Mod II(E) at [63] and [73], Motorola said that the file was a compiled library file i.e. object code. Yet at [87(d)] it expressly submitted that the library file was source code and was an example of source code being sent between Hytera's engineers via email. 1562 At [57(c)] of MCS(C) Mod II(C), it submitted that the file included 'the same files which the forensic logs from Ms Peiyi Huang's laptops indicate had been sent by Ms Peiyi Huang to Ms Ni Huang (and which had the same filenames as Motorola's L1 Timer/Framer source code files from which copying had been identified)'. This is supported by fn 174. There it is said that the contents of the file were 'as shown on pages 261 to 263 of Confidential Schedule 2 to List of Documents from Jun Ping Luo dated 4 March 2020'. I have consulted pages 261 to 263 and did not find the experience enlightening. As I explain shortly, I do accept that the forensic log of Ms Peiyi Huang's laptop provides evidence from which it might be inferred that a number of files, mostly likely source and header files, were sent by her to Ms Ni Huang. However, that does not assist in ascertaining whether the library file attached to the email chain was itself a library file of source or object code or, perhaps even both. 1563 Professor Rangan also touched on this topic in SR-22 at §97. He observed that Ms Peiyi Huang had accompanied the library file with a header file which was then identified by Ms Ni Huang to be the wrong header file. At §101 he said that it would have been obvious to Ms Ni Huang from her review of both files that 'this file, and the underlying source code used to compile the rfhal_c55.lib library file, contains code that originated from Motorola'. Yet, on the other hand, at §96, Professor Rangan appeared to commit himself to the position that the library file contained source code. At that paragraph, in the course of explaining why it was irregular for computer engineers to share library files by email, he said that in his experience 'it is extremely irregular for software engineers to send source code, especially in the form of large library files, to each other by email'. 1564 Given the absence of clarity in the evidence and Motorola's submissions, I do not find it proved that the library file attached to the email chain contained source code. To reach that conclusion would have required more explanatory effort than was expended on Motorola's part. I therefore do not find this allegation proven. 1565 Professor Rangan referred to other examples of source files having been emailed between software engineers. For example, at SR-22 at §127 he referred to an email with the subject heading 'L1timer materials' from Ms Ni Huang to Huang Guang Bin dated 14 May 2015 which attached a .rar archive file. He said that he had been informed by Motorola's solicitors that the archive file contained source code for the L1 Timer. Although this is hearsay, no objection was taken to it and I see no reason not to act on it. The email also contained this statement: Guang Bin This information can only be shared between the both of us. Others cannot have access to the code and information, including Zhu Deyou, unless authorized by me. Only lib and .h can be uploaded even after implementation. The code can only be stored on your computer and mine. Best Regards! Maggie 1566 This certainly suggests that whatever was included in the email was for tight distribution. For completeness, Huang Guang Bin is not one of the ex-Motorolans. 1567 There are further emails demonstrating such internal distributions. For example, see: email chain of 13-14 June 2008 ('Can you modify the code and rerun the second RAF lib i sent you just now?'): SR-22 at §135; email of 6 September 2011 ('The relationship between RAF and Motorola is sensitive, so the spread and use of RAF should be as small as possible'): SR-22 at §136; and email of 4 December 2008 ('The code had been uploaded to SVN'): SR-22 at §137. 1568 Finally, I accept that Ms Peiyi Huang sent source code files to Ms Ni Huang. Entries 125,230 to 125,262 of the forensic log for Laptop #3 appear to record that a number of files were sent by Ms Peiyi Huang to Ms Ni Huang. For example, the entry in the log for the file framer.h records as the path for the file: \personal\L1 backup\rfhal_sent_to_huangNi_withusToTickConvert 1569 Hytera submitted that it ought not to be inferred that this file (and the other similar files) were sent to Ms Ni Huang: HCS(C) Mod III at [51]. The nature of the evidence inclines me to infer that this path means what it says and that the file in question was sent to Ms Ni Huang. Since she did not give evidence that the files were not sent to her, I draw that inference more confidently. 1570 My conclusion is that distributions of source code between software engineers via email took place. I accept Professor Rangan's evidence that this is irregular. In light of the comments extracted above, I conclude that it was taking place to obscure what was being done with Motorola's code by ensuring that the code was not centrally located. 1571 So far as the extent of internal distribution is concerned, the picture appears to be that distribution was not limited to the ex-Motorolans, as Hytera submitted, but that the Hytera employees who had engaged in this process were to an extent limited. Non-ex-Motorolans who were involved included Huang Guang Bin, Wang Fei and Ni Huang. As I discuss a little later, I think it unlikely that the harvesting which was taking place was unknown amongst the rest of Hytera's software engineers. (vii) Implausible Speed of Hytera's Development of its Source Code 1572 Professor Rangan gave evidence in SR-22 at §78(d) that Hytera had been able to produce large amounts of code with complex functionality in a matter of months rather than the many years it took Motorola to develop its code. In his opinion, this was not possible. Motorola submitted to the same effect: MCS(C) Mod II(E) at [87(e)]. 1573 Hytera submitted in Annexure B to its closing submissions that much of Professor Rangan's evidence in SR-22 was in the nature of a general assertion. It was also said that he had no experience in working in a DMR development team. Whilst this is true, I do not think it detracts from the force of his observations given his obvious qualifications in the area. There remains the question: how did Hytera do in such a short period of time what had taken Motorola many years to do? On the face of it, I accept that Professor Rangan's evidence is some evidence that it was not possible for Hytera legitimately to have developed its code in the time that it did. There were many other software engineers involved in the creation of the Hytera code apart from the ex-Motorolans. It was open to Hytera to call these witnesses to explain just how it was that the Hytera code was composed. In my view, it is open to infer that Hytera could not legitimately have developed its software in the timeframe it did from: (a) the difference in development times for Motorola and Hytera; and (b) Professor Rangan's evidence that Hytera could not have developed the software to operate its DMR devices in the time that it did. I am inclined to draw that inference. I may more comfortably draw that inference in circumstances where Hytera has not called any of its software engineers. 1574 I therefore find that it was not possible for Hytera to have composed its DMR firmware in the time that it did using legitimate means. (viii) Adverse Inferences 1575 I have already twice drawn adverse inferences against Hytera for failing to call Ms Ni Huang and for failing to call any software engineers involved in the creation of its DMR code. I do not draw an adverse inference against Hytera for failing to call the ex-Motorolans. They have all left Hytera and there is reason to think that given their own exposure that they would not have been co-operative. Conclusions on Objective Similarity In Relation to the 12 Files 1576 There is no doubt that Hytera's software engineers engaged in industrial scale harvesting of Motorola's source code and that they set out to make this as difficult to detect as possible. The software engineers involved included the ex-Motorolans and Huang Guang Bin, Wang Fei and Ni Huang. I do not accept that it is possible that all of the software was developed by these individuals alone. There were many other software engineers working at Hytera. Whilst I accept that there were efforts to limit the extent of any evidence of what was happening, I do not think it was a secret. Further, I do not accept that it is likely that what was going on was limited to the above individuals. As I have said, it is significant that none of the software engineers were called. That failure allows me confidently to draw the inference that more personnel than just the ex-Motorolans were involved. 1577 For that reason, I am confident that in the missing Hytera source code there were tracts of code which were, before their untimely disappearance, objectively similar to portions of Motorola's source code and that these portions had been copied. In some cases, the copying would have been verbatim, in other cases there would have been cosmetic changes. 1578 However, I am also confident that there were tracts of code in the missing Hytera source code which are not objectively similar to the Motorola source code. This may be because they had been written independently. For example, because the Hytera devices are not the same as the Motorola devices, there are of necessity differences in the codes. There may also be other circumstances where Hytera's software engineers used the Motorola code as a basis for producing something which, although descended from the Motorola source code, is sufficiently different that it is no longer objectively similar. The removal of functionality from the Motorola source code for the simplified Hytera source code is an example. 1579 These possibilities are opened up by the source code which is available. In considering Motorola's case that its source code had been copied, I have concluded in very many cases that objective similarity is not established. Motorola urged me to reason from what had happened in those cases where the Hytera source code was available that something similar was likely to have happened in the case of the source code which was not available. It did so by its submission that the former exhibited evidence of 'wholesale' copying with the invitation that similar wholesale copying must have taken place in the missing source code. I have rejected that submission. But I nevertheless accept the invitation to reason by analogy from the source code which is available to the source code which is not. 1580 It is very likely that amongst the missing source code files there are files which have been copied from the Motorola source code (using copied as a shorthand for objective similarity and causation). It is also quite possible that some of the missing source code files are not objectively similar. Turning then to the 12 files presently under consideration the problem becomes in each case how to determine which class the file falls into. 1581 I see no way of resolving that question in relation to any particular file. I am not satisfied on the balance of probabilities that any of the nominated missing Hytera source code files is objectively similar to the 12 Motorola files in question. I think it likely that some of them have been copied but I am neither able to estimate how many nor to identify the files where this has happened. 1582 Motorola did not pursue a claim for breach of confidence. Whereas the copyright infringement case encounters the problem that Hytera set out to alter the Motorola source code to reduce its objective similarity, it is not self-evident that this would have been an answer to a breach of confidence case. 1583 Despite therefore being persuaded that Hytera took Motorola's source code and fashioned it into its own source code (which has then been lost), I am not persuaded in the context of a copyright infringement suit that it has been demonstrated, at the level of these particular files, that the missing Hytera source code was objectively similar to the corresponding Motorola source code. I have not the slightest hesitation in concluding that the missing Hytera source code was in many instances fashioned from the Motorola source code. However, the fact that refashioning certainly took place and that not all of it was cosmetic, means that when one asks what conclusions can be drawn about particular files, the answer is that one cannot say. 1584 I conclude that Motorola has not shown that the missing source code contained tracts of source code which are objectively similar to the source code in the 12 files. Motorola's infringement claim in relation to them therefore fails. (b) Materiality 1585 Motorola made no submissions about the materiality of the 12 files. I have no explanation of what any of the files do in terms of the EMT. Consequently, even if I had been satisfied that copying as alleged had taken place, I could not have been satisfied of their materiality. There are 151 files in the EMT. I cannot reason simply from the fact that a file has been taken that it was material to the overall work. (c) Conclusions on Infringement 1586 This part of Motorola's case fails. U. cor_single_linked_list.c 1587 I have explained the procedural history of this file above at [1512]. Motorola alleges that the whole of this file has been copied into the Hytera file SingleLinkedList.cpp. (a) Objective Similarity 1588 Motorola provided no side by side analysis of these two files. At MCS(C) Mod II(E) at [48], Motorola said that this file was Motorola's single linked list implementation. 1589 Hytera submitted in HCS(C) Mod II at [284] that the experts had conducted a comparison of these two files at T649.45-653.8 and that they had agreed that the Hytera file contained materially different source code. It relied on Mr Brown's evidence that in the Motorola function, the pointers were located inside the node whereas in the Hytera file, the pointers are located outside the node. Mr Brown said that this resulted in different data structures, different logic and a different implementation of the single linked list: T652.8-35. Hytera submitted that Professor Wicker had agreed that the Hytera code was different from the single linked list function: T653.6-8. 1590 Motorola submitted that Mr Brown and Professor Wicker had not agreed that the Hytera source contained materially different code. Rather the reverse was true: MCS(C) Mod II(R) at [46]. What they had agreed on was that the files in the CPA libraries were 'exact or close matches to corresponding Motorola files'. The evidence for this was said to be in the 'common comment' section of the Joint Expert Witness Conference dated 8 July 2020 at pp 5-6 ('JEWC-2'), in response to Q4(a). In relation to the particular Hytera file SingleLinkedList.cpp, Motorola submits that the experts agreed with Professor Wicker's description of the file as 'essentially identical to the Motorola code, save for some minor modifications' which Professor Wicker said in SBW-66 at §25. It was also said that Professor Wicker had said that the modification which had been made to the Hytera file simply [Redacted]. He was said to have said this at T651.41-43. 1591 In light of this disagreement it is necessary to examine the evidence pointed to by the parties. 1592 Hytera's four page transcript reference leaves much for the reader to do. Professor Wicker was shown a copy of the source code for the Hytera file. Professor Wicker said that the Hytera function had been derived from the Motorola function: T651.27-31. He thought that the two sets of code did the same things (T651.20-25): PROF WICKER: … except with regard to [Redacted] that I've mentioned. So we see at the beginning, [Redacted]. But again, we have to account for [Redacted]. So the code looks different because of [Redacted], but it's doing essentially the same. 1593 He accepted that the Hytera function had been modified from the Motorola function ('Yes, that – that's certainly true'): T651.36. He did not accept that the modifications to the Hytera file were significant: T651.41-43. He said that it functioned differently to 'account for the different processor': T651.43. He also accepted that the Hytera code was more complex at T651.41-652.2 although he said this was 'an artefact of [Redacted]'. An attempt to get Professor Wicker to agree that the code for the Hytera function was materially different to the Motorola source code led to Professor Wicker outflanking the question by observing that the code under discussion was only for one operation although he agreed in relation to that operation that the code was different adding by way of qualification 'taking into account the factors we've already discussed': T653.8. He added at T653.16-21 that the cross-examination had been concerned with one portion of the code that [Redacted] but observed that not all of the code had been examined. Looked at as a whole he felt that the list code was 'substantially the same in both the Motorola and the Hytera files': T653.19. The difference which had been examined related to the fact that a different processor was being used: T653.20. 1594 Mr Brown then explained that [Redacted] had been around since 1955 when they had been published by Rand Corporation: T652.10. Professor Wicker agreed with this, observing that he had studied it as an undergraduate: T652.46. Mr Brown then explained that [Redacted]. Mr Brown thought that in the Motorola code [Redacted] whereas in the Hytera code [Redacted]: T652.14-27. Mr Brown did not explain what [Redacted] was. The fact that [Redacted] led to different data structures. Professor Wicker agreed with this explanation but not with Mr Brown's view that the difference was significant (although I have not located Mr Brown's evidence where he said the difference was significant): T652.33-35. 1595 Turning then to Motorola's evidentiary references, the first is to the common comments of JEWC-2 at Q4(a) at pp 5-6. The experts agreed that the Hytera files contained instances where there are exact or close matches to the corresponding Motorola files. In SBW-66 at §25, Professor Wicker said that the code for the Hytera file was 'essentially identical to the Motorola code, save for some minor modifications'. He explained the modifications this way: Hytera has systematically made two minor modifications to the functions in this file: [Redacted] 1596 I have not been able to locate a side by side analysis of the two codes. The evidence has not explained to me what a [Redacted] is. Nor do I have any idea what it means for [Redacted]. Motorola has not attempted to explain what Professor Wicker's [Redacted] point is. There is some discussion between Professor Rangan and Mr Brown at T655 about [Redacted] which appears to have something to do with the process of compilation but neither party relied on this. 1597 In circumstances where I am unable to examine the two sets of code side by side this makes assessment of this evidence difficult. I understand that they differ by reason of [Redacted] but it has not been explained to my satisfaction what this entails. I am aware that [Redacted] are treated differently in terms of [Redacted]. And I know that Professor Wicker thinks that this does not matter and that Mr Brown thinks that it does because it affects the data structures. Without: (a) some explanation of what all of this means; and (b) a side by side comparison of the codes, I do not see how I would be more than guessing at which of Mr Brown or Professor Wicker is correct about this. 1598 The burden lies on Motorola to make good this point. As such, I am unable to be affirmatively satisfied that the Hytera source code is objectively similar to the Motorola source code. (b) Materiality and Originality 1599 Neither party explained what the single list link did. As such I am not able to engage in the qualitative analysis demanded repeatedly in Motorola's submissions. I am unable to assess its materiality to the EMT. 1600 I am unable to assess its originality although Hytera submitted that the single linked list function was a common computer algorithm that had been known for many years. It pointed to Mr Brown's evidence at T652.8-12 and Professor Wicker's evidence at T652.29-47 that he 'studied it as an undergrad'. I accept Hytera's point that the idea of a single linked list has been around since 1955. However, it may be that the originality lies in what is in the single linked list and not the fact that it is a single linked list. However, I was not taken to any evidence by either party about the contents of this single linked list so that its originality might be assessed. As such, had it arisen I would not have been able to conclude that the Motorola file was original in the infringement sense. (c) Conclusions on Infringement 1601 This part of Motorola's infringement case fails. 8. WAS A SUBSTANTIAL PART OF THE EMT COMPONENT COPIED BY HYTERA INTO ITS FILES? 1602 Motorola's submissions about this in relation to the EMT were confined to MCS(C) Mod II(E) at [100(a)], [101]-[105], the first sentence of [123], and [138(a)]. Apart from those dealing with [Redacted] which concerned a single file and its submissions about cor_single_linked.c in its submissions in reply, no submissions of any substance about any of the files within the EMT were made. For the reasons I have given, I find that Motorola has not demonstrated that a substantial part of the EMT component was copied by Hytera. The Xlate Component 1. NATURE OF THE XLATE 1603 I have mentioned above when dealing with the EMT that the Xlate is the 'User Input Translate Task' and is one of the five core components of the Darwin Ergonomics Platform. Xlate and another of the core components, the UIQ, are grouped together under the heading entitled 'User Input Subsystem': Architecture Document at pp 19-24. The user input subsystem is responsible, as the name suggests, for receiving and translating user inputs. Within that subsystem, Xlate translates the user inputs into a form which can be understood by the EMT and sends them on to it. However, the user inputs do not go directly to Xlate. Rather, they arrive in the UIQ where they are queued and sent to Xlate progressively. The reason for the queueing arrangement is to stop Xlate from becoming overloaded. 1604 Xlate is described in the Architecture Document as translating the physical inputs received from the user (by, for example, pressing a button) into logical inputs. It says this: Xlate translates physical to logical inputs and sends the input messages to EMT. [Redacted] 2. IDENTIFYING MOTOROLA'S CASE ABOUT XLATE 1605 Motorola's submissions do not identify either the files or the lines of code within those files which it alleges have been copied. As I have previously explained, for these purposes, consulting Motorola's particulars is pointless. 1606 Mr Brown identifies those files within the Xlate which are alleged in the particulars to have been copied in CMB-25 at p 22. He identifies 19 such files. They fall into four categories: (a) files where the alleged infringements relate to available Hytera source code which was discovered in the First Tranche of discovery; (b) files where the alleged infringements relate to available Hytera source code which was discovered in the Second Tranche of discovery; (c) files where the alleged infringements relate to available Hytera source code which was discovered in the Fourth Tranche of discovery; and (d) files where the alleged infringements relate to unavailable Hytera source code where Motorola seeks to prove that the missing Hytera source code contained lines of code copied from its files. It does this by resort to the disassembled Hytera object code contained in the library file raf_arm9.lib together with the surrounding circumstances. 1607 I will deal with these categories separately. It would appear from CMB-25 that a number of files which are alleged to be contained within the Xlate are also alleged to be contained within the EMT. In each case I will indicate the full listing of files as indicated in CMB-25. Instead of reaching conclusions on files which I have already considered, I will instead merely repeat the conclusion reached in the EMT section with a cross-reference. 3. ALLEGED INFRINGEMENTS RELATING TO AVAILABLE HYTERA SOURCE CODE DISCOVERED IN THE FIRST TRANCHE OF DISCOVERY 1608 The evidence concerning these may be found in SBW-35, SBW-38 and CMB-25. There eight such files (as identified in CMB 25 at p 22): com_ergo_platform_app_defines.h com_cp_button_def.h svc_xlt_services.h cor_xlt_user_defs.h com_ergo_platform_user_defines.h rs_bco.h rs_xlt_config.c rs_xlt_config_com.c 1609 Dealing with each in turn: A. com_ergo_platform_app_defines.h 1610 This file appears in the EMT and is dealt with above at [1391]. For the reasons I give there, Motorola's case in relation to this file fails. B. com_cp_button_def.h 1611 This file appears in the EMT and is dealt with above at [1401]. For the reasons I give there, Motorola's case in relation to this file fails. C. svc_xlt_services.h (a) Objective Similarity 1612 This is a header file. In SBW-38 at pp 264-265, Professor Wicker identified lines 68-113 of this file as being objectively similar to lines 104-138 of the Hytera file raf_input.h. Having examined these portions I am satisfied that they are objectively similar. (b) Materiality 1613 Professor Wicker said at SBW-38 at pp 264-265 that this header file defined function prototypes for the functions which [Redacted]. The definitions in the function prototype are to be distinguished from the functional code defining the functions themselves. A function prototype establishes the name of the function, the data type the function returns and the parameters and variables the function takes: SBW-32 at §30. Professor Wicker explained that Xlate used [Redacted]. It is unclear to me what is involved in [Redacted] although I have no difficulty understanding what [Redacted] implies. I accept that the task of [Redacted] is important. 1614 As such, I accept that the functional code [Redacted] and the functions which perform each of the activities just mentioned are material to the operation of Xlate. I do not, however, accept that the function prototypes which establish the parameters for those functions are, without more, material to the operation of the Xlate. They are necessary in a but for sense but merely establishing the parameters, in this case, for the functions established by other functional code does not seem to be material to the Xlate. Professor Wicker did not point to some aspect of these functional prototypes which elevated them beyond what appears to me to merely incidental code. I accept that in some circumstances the tail may wag the dog and that the declarations in a header file may themselves be material, however, I do not think this is one of them. (c) Conclusions on svc_xlt_services.h 1615 Motorola's infringement claim in relation to this file fails. D. cor_xlt_user_defs.h (a) Objective Similarity 1616 This is a header file. In SBW-38 at p 266, Professor Wicker identified the following portions of this file as being objectively similar to portions of the Hytera file raf_input.h: cor_xlt_user_defs.h raf_input.h 1 104-105 96 2 106-116 67-73 3 117-127 54-65 4 128-150 19, 75-94 5 151-153 95-102 1617 I am satisfied that (1), (2), (4)-(5) are objectively similar. The differences in (3) relate to the comments which are plainly not objectively similar. However, I accept that in the substantive code which was compiled, lines 123-126 are the same as lines 62-65 of raf_input.h. As such I accept objective similarity for (3) as well. (b) Materiality 1618 Mr Ley in DJL-1 at §71 explained that this file included [Redacted]. 1619 Professor Wicker's evidence about these lines was largely the same. It was that each set of lines contained [Redacted] : SBW-38 at p 266. Whilst I would accept that it is possible for the declaration of data types and functions in a header file to constitute a material part of the computer program to which they are appurtenant, more needs to be shown than has been shown here. I do not know anything about the functional code to which they relate. I take Professor Wicker's evidence to be implying that at times there are functions within the platform agnostic Darwin core which need to interact with an actual device and that this is mediated through the radio-specific layer. However, I do not know what the functions in question are and I have no understanding of the interface between the Darwin core and the radio-specific layer. Accepting for the sake of argument that the functions have to be freshly declared (for reasons unknown to me), the situation remains that I would not accept that declarations of this kind are, without more, material to the computer program (here, the Xlate). Assuming for the moment that there is some substantive code which mediates the relationship between the Darwin core (through Xlate) and the radio-specific layer, I do not know how significant the role of these declarations is in the scheme of that unidentified code. 1620 I am unable to conclude that these lines of code are material to Xlate. (c) Conclusions on cor_xlt_user_defs.h 1621 Motorola's infringement claim in relation to this file fails. E. com_ergo_platform_user_defines.h 1622 This file appears in the EMT and is dealt with above at [1397]. For the reasons I give there, Motorola's case in relation to this file fails. F. rs_bco.h (a) Objective Similarity 1623 This is a header file. At SBW-38 at p 271, Professor Wicker identified line 52 as being objectively similar to line 88 of the Hytera file kcode_def.h. I agree. (b) Materiality 1624 Mr Ley said in DJL-1 at §76(a) that this file [Redacted] 1625 [Redacted]. Whilst I do not doubt that the way Xlate [Redacted] are material to its operation, I do not accept that the mere declaration of the variable name for a [Redacted] is material to the operation of the Xlate. Motorola made no submissions about this single line of code. I do not find that it is a substantial part of Xlate. It is not necessary to consider originality. (c) Conclusions on rs_bco.h 1626 Motorola's claim in relation to this file fails. G. rs_xlt_config.c (a) Objective Similarity 1627 This is a source file. At MCS(C) Mod II(E) at [100(b)], Motorola said that this source file contained functions which related to [Redacted] and the function 'rsIsThisPTTInput' which is used [Redacted]. Professor Wicker's treatment was at SBW-38 at pp 267-268. He identified lines 113-186 of the Motorola file as having been copied by lines 40-76 of the Hytera file ps_xlt_config.cpp and provided a side by side comparison. Having examined these lines of code I am not satisfied that they are objectively similar. As Professor Wicker explains at p 267, the Motorola code [Redacted] whereas the Hytera code creates only one. [Redacted]. The Hytera function is similar to the other Motorola function. However, as Professor Wicker explained, the logic of the Hytera function was not quite the same and they do not perform in quite the same way. 1628 In any event, Professor Wicker also said in SBW-56 at §40 that this Hytera file was located in the RAF library directories. As I have explained when dealing with the EMT, the files in these directories were not compiled into Hytera's object code and hence are irrelevant to Motorola's adaptation case. (b) Materiality 1629 Mr Ley said in DJL-1 at §76(c) that this source file [Redacted]. 1630 Professor Wicker's evidence in SBW-38 at p 267 was that the two Motorola functions were used to [Redacted]. I accept that this code is material to the operation of Xlate. (c) Conclusions on rs_xlt_config.c 1631 Motorola's infringement claim in relation to this file fails since the Hytera file was not compiled into Hytera's object code. H. rs_xlt_config_com.c (a) Objective Similarity 1632 This is a source file. In SBW-38 at pp 269-271, Professor Wicker identified two portions of this file as being similar to lines of the Hytera file ps_xlt_config.cpp: rs_xlt_config_com.c ps_xlt_confi.cpp 1 193-273 186-244 2 276-322 80-111 1633 I am satisfied that these are objectively similar. The differences largely relate to comments which are not subject to the compilation process. (b) Materiality 1634 Mr Ley gave evidence in DJL-1 at §76(d) that this file [Redacted]. This does not advance the debate very far. Dealing with the nominated lines of code: Lines 193-273 1635 Professor Wicker thought that these lines of code 'related to' [Redacted]. Whilst I understand that [Redacted], I do not know what is involved in the idea of 'relating to'. Motorola made no submissions about these lines of code. Knowing that this code relates to [Redacted] is not sufficient for me to conduct a qualitative assessment of the code's overall significance to Xlate. Consequently, I do not find that these lines are a substantial part of Xlate. Lines 276-322 1636 Professor Wicker made the same observations about these lines of code. I conclude that Motorola has not shown that these lines are a substantial part of Xlate. (c) Conclusions on rs_xlt_config_com.c 1637 Motorola's infringement suit in relation to this file fails. 1638 That file concludes the discussion of the infringements related to available Hytera source code in the First Tranche of discovery. Motorola's claim fails on each file. 4. ALLEGED INFRINGEMENTS RELATING TO AVAILABLE HYTERA SOURCE CODE DISCOVERED IN THE SECOND TRANCHE OF DISCOVERY 1639 These included three files discussed in the First Tranche (about which there was new evidence in the Second Tranche) together with five new files for a total of eight files: CMB-25 at p 22. The eight files are: cor_xlt_user_defs.h rs_xlt_config.c rs_xlt_config_com.c rs_xlt_utilities.c rs_xlt_cpval_uiop_table.c cor_single_linked_list.h rs_application_id.h rs_uiopcode_list.h 1640 The evidentiary difference between the First and Second Tranches is that Professor Wicker did not provide a side by side analysis of the available source code in the Second Tranche. As was the case with the EMT, this necessitates the use of Mr Brown's side by side analysis in CMB-13 to overcome the combined effect of the corresponding lacuna in Motorola's submissions hitched to the inaccessible nature of Motorola's particulars. Professor Wicker's fresh evidence was contained in SBW-56 where he provided a narrative on each of the files in the Second Tranche without indicating which of the 11 works in suit it belonged to, and SBW-57 where he identified the lines of Motorola code said to be copied into Hytera code. Motorola's submissions did not attempt to connect the evidence in SBW-56 or SBW-57 with particular works. By examining CMB-25 at p 22, removing the doubled up files from the EMT and then cross-referencing what remains to SBW-57, I have been able to allocate Professor Wicker's evidence to the relevant work. Professor Wicker also responded to Mr Brown's side by side analysis in SBW-61. As I have previously noted he criticised that side by side analysis without offering his own. I. cor_xlt_user_defs.h (a) Objective Similarity 1641 This file is not mentioned in Motorola's submissions. Professor Wicker discusses it in SBW-56 at §39. He told me that lines 6-9 of the Hytera file ps_xlt_rcdb.h contain two function prototypes which are essentially identical to lines 190 and 194-196 of the Motorola file. He did not provide a side by side comparison although the lines (but not the code itself) are identified in SBW-57 at p 43. 1642 Mr Brown dealt with the two files in his side by side comparison at CMB-13 at p 210. The lines in question are: cor_xlt_user_defs.h ps_xlt_rcdb.h 1 187-196 6-9 1643 Mr Brown expressed the view that he agreed with Professor Wicker and that the function prototypes established by these lines are similar. I conclude that lines involved are objectively similar. (b) Materiality 1644 I do not know anything about the functional code to which these function prototypes relate. As such I am unable to assess from a qualitative perspective the significance of these lines of code to Xlate. Consequently, I cannot be satisfied that they are material to it. (c) Conclusions on cor_xlt_user_defs.h 1645 Motorola's infringement claim in relation to this file fails. J. rs_xlt_config.c (a) Objective Similarity 1646 As I have previously mentioned in relation to this file in my treatment of it in the First Tranche, there is a reference in Motorola's submissions to this file in MCS(C) Mod II(E) at [100(b)] to the effect that it contains functions related to [Redacted]. Professor Wicker discusses the file at SBW-56 at §40. He explains that the same lines of code are involved as were involved in his consideration of this file in the First Tranche. As I have explained above, I am not satisfied that the two sets of code are objectively similar. 1647 Unlike the version in the First Tranche, the Hytera files identified in the Second Tranche were located in the Application and AFP directories which, unlike the RAF directories, were subject to compilation. Had the codes been objectively similar, they would have been relevant to Motorola's adaptation case since they were compiled into its object code. (b) Materiality 1648 For the reasons already given in relation to this file in the First Tranche I would have concluded that these lines were material to Xlate. (c) Conclusions on rs_xlt_config.c 1649 Motorola's infringement claim in relation to this file fails. K. rs_xlt_config_com.c (a) Objective Similarity 1650 This file is not mentioned in Motorola's submissions. Professor Wicker's treatment of it in the Second Tranche is at SBW-56 at §§41-43. He said that lines 25-26, 30-33 and 35-38 of the Hytera file ps_xlt_config.cpp are almost identical to the corresponding lines in the Motorola source code identified in SBW-57 although he did not say what the Motorola lines of code were. The lines of code are not themselves contained in SBW-57, but they are identified there at pp 45-47. It would appear that the code is alleged to have been copied into the RAF library and Application directories. For reasons I have already explained, the files located in the RAF library directories are irrelevant to Motorola's adaptation case. The Hytera lines of code identified in SBW-57 are more extensive in terms of sets of lines of code than those Professor Wicker has referred to in SBW-56. I will proceed on the basis that SBW-56 narrows the broader claims made in SBW-57 to a single set of lines. Professor Wicker does not identify which set of lines of the Motorola code he was talking about in SBW-56. However, resort to SBW-57 reveals that they are lines 79-81, 95-98 and 108. 1651 Professor Wicker did not provide a side by side analysis. I have his evidence that the competing lines are 'almost identical' and an explanation of that evidence: SBW-56 at §§41-43. Professor Wicker said that there were these differences: the Hytera code does not include code relating to the extended press function which is present in the Motorola code. I assume this is because the Hytera devices do not have extended button press functionality (i.e. generating a different meaning for a button by holding it down for a bit longer); as such the Hytera code was a simplification of the Motorola code; the Hytera function 'psGetSigButtonsAndSwitches' is very similar to the Motorola function 'rsXltGetSigButtonsAndSwitches' and includes substantially identical comments; a section of code which in the Motorola code is treated as a function call is instead in the Hytera code simply included in the code; and not all of the code in the Motorola code is present in the Hytera code. Professor Wicker thought that this reflected simplification. 1652 Mr Brown's side by side analysis is at CMB-13 at pp 211-216. It includes a number of lines which are not pursued by Professor Wicker in SBW-56 and may be disregarded. The relevant portion is the first three tables appearing on p 212. I have examined these lines of code and am satisfied that they are objectively similar. (b) Materiality 1653 Mr Ley said in DJL-1 at §76(d) that this file [Redacted]. It will be recalled from the discussion of different lines of this file set out above in relation to the First Tranche that Professor Wicker thought that the lines related to [Redacted]. 1654 The comments in the Motorola lines suggest that the code contains [Redacted]. I do not know what this means. The upshot is that I do not know what these lines of code do. As such I am unable to embark upon a qualitative assessment of their significance to Xlate. I do not find that the lines in question are material to Xlate. (c) Conclusions on rs_xlt_config_com.c 1655 Motorola's infringement claim in relation to this file fails. L. rs_xlt_utilities.c (a) Objective Similarity 1656 This file is not discussed in Motorola's submissions. Professor Wicker discusses it in SBW-56 at §§44-45. He identifies two Hytera files both called ps_xlt_utilities.cpp. One of these is in the RAF library directories and may be disregarded since it was not compiled. The other is in the Application directory and was compiled. Professor Wicker identifies the relevant lines of both the Motorola and Hytera files in SBW-57 at pp 47-49. According to Mr Brown, Professor Wicker has identified 206 lines of code: CMB-13 at p 216. It is unclear which of these Professor Wicker is talking about in SBW-56 although perhaps it is all of them. 1657 Professor Wicker has not provided a side by side analysis and, for reasons already given, I am not going to do one. Mr Brown gives a side by side analysis in CMB-13 at pp 216-219. He considers only lines 227-287, 289-347, 908-954 and 1589-1627 of the Motorola file. Although Professor Wicker identifies more lines of code than merely these lines (SBW-57 at pp 47-49), I have no side by side comparison for them and can do nothing with Professor Wicker's evidence about them. The files Mr Brown has examined are those which were located in the Application directories (and which were therefore compiled). The competing lines of code are: rs_xlt_utilities.c ps_xlt_utilities.cpp 1 227-287 41-122 2 289-347 169-223 3 908-954 125-167 4 1589-1627 225-250 1658 Dealing with each in turn: Lines 227-287 1659 Mr Brown thought that the goal of both sets of code was similar although they achieved it by different means: CMB-13 at p 217. The difference was that the Motorola code used an if/else chain whilst the Hytera code used a switch statement. Although elsewhere Mr Brown expressed the view that this resulted in a more efficient compilation process, he did not do so on this occasion. Professor Wicker also observed the change from if/else chains to switch statements: SBW-56 at §45. He also thought that some additional functions had been added. I conclude that these lines are objectively similar. Lines 289-347 1660 Mr Brown thought that this code did nothing in the Hytera devices: CMB-13 at p 218. He observed that some functional code in the Motorola code had been placed inside comments (which meant that it would be discarded by the pre-processor). Professor Wicker's only view was that the copying was 'almost identical': SBW-56 at §44. I have examined Mr Brown's side by side analysis in CMB-13 at pp 217-218. I agree that Motorola's functional code has been moved into comments. Whilst this means the operation of the Motorola and Hytera files is quite different – one does something, one does not – they remain textually similar since the former functional code lives on as non-functional text inside the comments. Viewed from a programming (rather than textual) perspective, however, I do not think that these files are objectively similar. In a sense, they a quite different. I conclude that these lines are not objectively similar. Lines 908-954 1661 Mr Brown made no remarks about these lines and Professor Wicker's only comment was his general remark at SBW-56 at §44. The side by side comparison is at CMB-13 at pp 218-219. I have examined these and am satisfied that they are objectively similar. Lines 1589-1627 1662 Mr Brown's evidence is at CMB-13 at p 219. In a nutshell, the Motorola lines [Redacted]. The Motorola file has been copied into the Hytera file. However, the Motorola code has then been rewritten to ensure that the functions involved [Redacted]. Mr Brown thought, and I agree, that this indicates that the Hytera devices do not have this functionality. What has happened is that the code has been brought across from the Motorola code but then, because the Hytera devices do not actually have this feature, the code has been rewritten so that it is not used. Effectively, it is an artefact of the copying process. Whilst it plain that the origin of these lines of code is the Motorola lines, what they actually do is nothing. Accordingly, I do not conclude that they are objectively similar. (b) Materiality 1663 Mr Ley said in DJL-23 at §9 that this file was a radio-specific implementation file. Professor Wicker did not say what the file did in SBW-56 at §§44-45. Lines 227-287 1664 I have considered through CMB-13 at pp 216-217 whether the comments in lines 227-287 of the Motorola file demonstrate that these lines perform an exhaustive test to determine the hardware source of the user input. Since the Xlate converts real word button presses by users into logical inputs for the EMT, it is straightforward to reason that lines 227-287 are functional code which determines what kind of hardware the user is using. From this one could conclude that these lines are material to the Xlate. It is obvious that determining the hardware being used is important for the function performed by Xlate which is to convert what is happening at the physical end of the user into logical values for the EMT. 1665 One difficulty which arises is that neither party has made any submission about these lines of code or the comments (although Hytera referred to the file in an annexure). I have a concern that if I conclude on the basis of the comments that lines 227-287 are material to Xlate I may deny Hytera procedural fairness. I have concluded that I would not do so. It is alleged by Motorola that these lines are a substantial part of the Xlate. The evidence includes the evidence of Mr Brown, Professor Wicker and Mr Ley. That evidence includes in CMB-13 at pp 216-217 and the lines of code including the comments. They are relevant to the allegations which are made. Consequently, I conclude that Hytera was sufficiently on notice that it was alleged that these lines of code were material to the Xlate. 1666 Consequently, I conclude that these lines of code are material to Xlate. Further, as a set of functional code with a clearly understood purpose, I am satisfied that they are original in the infringement sense. Lines 289-347 1667 I have concluded that the corresponding Hytera lines are not objectively similar. If I am wrong in that conclusion I would not have concluded that the Motorola lines are shown to be material. The purpose of these lines and their relationship to the overall Xlate has not been demonstrated. Lines 908-954 1668 The comments for these lines indicate that they [Redacted]. I do not know what this means. I was taken to no other evidence about their materiality. I am unable to determine the qualitative significance of these lines to Xlate. I do not find that they are material. It is not necessary to express an opinion on whether they are original. Lines 1589-1627 1669 I have concluded that the Hytera lines are not objectively similar to these lines so the question of materiality does not arise. Had it arisen, the comments suggests that these lines [Redacted]. That would appear to be material to the operation of Xlate. (c) Conclusions on rs_xlt_utilities.c 1670 Motorola's infringement claim succeeds in relation lines 227-287 of this file. These lines are a material part of Xlate. They were copied by Hytera into source code which was then compiled into object code. The Hytera object code therefore involves an adaptation of a substantial part of the Xlate. M. rs_xlt_cpval_uiop_table.c (a) Objective Similarity 1671 This file is not mentioned in Motorola's submissions. Professor Wicker discusses it at SBW-56 at §§71-72. He identifies the relevant lines and files in SBW-57 at pp 49-50. Mr Brown provides a side by side analysis of some of those lines in CMB-13 at pp 255-261. Since it is the only version I have, this is the version I will work from. He identifies lines 41-303 of the Motorola file as having been copied into a Hytera file named ps_xlt_cpval_uiop_table.cpp at lines 16-293. This corresponds to one set of code lines referred to by Professor Wicker in SBW-57 at p 50. 1672 These lines of code define [Redacted]. According to Mr Brown at CMB-13 at p 261, [Redacted]. It is evident that the Hytera [Redacted] has been customised, for example, [Redacted]: lines 91-92. Plainly, whoever wrote the Hytera [Redacted] started with the Motorola [Redacted]. 1673 However, I do not think these [Redacted] are, in terms of their contents, objectively similar. The contents are quite different. Professor Wicker thought that the same structure had been used in the Hytera [Redacted]. This is, no doubt, true since both versions are [Redacted]. For the reasons I have given in relation to the [Redacted] in the EMT, I accept that these two [Redacted] ae objectively similar because they have the same structure (although their contents are not objectively similar). (b) Materiality 1674 For the same reasons I have given in relation to the [Redacted] in the EMT, I am not satisfied that the fact that the information present in Motorola's [Redacted] takes the form of a [Redacted] is material to Xlate. 1675 Leaving aside the file's [Redacted]-ness, I have not accepted that its contents are objectively similar either. If I had accepted that, I would not have accepted Mr Brown's view that [Redacted] was immaterial to the operation of Xlate. It is true that at this level, one is deep in the granular (and may have been there for some time). No doubt, it is true that for Xlate to work there must be [Redacted]. No doubt the selection of the former is driven by the device. The selection of the latter can be arbitrary. It does not really matter [Redacted] as long as whatever [Redacted] is selected is always the same. Even so, the Xlate will simply not work without such a [Redacted]. In saying that, I do not seek to imply that a 'but for' approach to assessing materiality is appropriate. Rather, what I am endeavouring to say is that the [Redacted], whilst mundane, is also foundational. The Xlate must act as the interpreter between the EMT and what is physically happening on the device viz a viz the user. Effectively, this [Redacted] is an interpretation engine. Like a dictionary this [Redacted] is drab, but that does not mean it is not material. (c) Conclusions on rs_xlt_cpval_uiop_table.c 1676 Motorola's case on this file fails. N. cor_single_linked_list.h 1677 This file has been dealt with under the EMT at [1488]. Motorola's claim in relation to it fails. O. rs_application_id.h 1678 This file has been dealt with under the EMT at [1493]. Motorola's claim in relation to it fails. P. rs_uiopcode_list.h 1679 This file has been dealt with under the EMT at [1502]. Motorola's claim in relation to it fails. 5. ALLEGED INFRINGEMENTS RELATING TO AVAILABLE HYTERA SOURCE CODE DISCOVERED IN THE FOURTH TRANCHE OF DISCOVERY 1680 There is only one file in this category. It is cor_single_linked_list.c. I have dealt with this file above in the EMT at [1587]. Motorola's case in relation to this file fails. 6. ALLEGED INFRINGEMENTS RELATING TO UNAVAILABLE HYTERA SOURCE CODE WHERE THE OBJECT CODE COMPILED FROM THAT SOURCE CODE WAS DISCOVERED IN THE SECOND TRANCHE AS A LIBRARY FILE OF OBJECT CODE 1681 The files in question are set out in CMB-25 at p 22. They are: com_ergo_platform_utils.c svc_xlt_services.c cor_xlt_task.c cor_xlt_utils.c cor_xlt_xe_functions.c 1682 The relevant library file is the raf_arm9.lib file. I have explained this library file above in relation to the EMT. Along with the Motorola files identified by Professor Wicker in the EMT where function names from those files could be detected in the disassembled object code, Professor Wicker also identified other files from Xlate where this could be done too. In the case of four of the above files he did so at SBW-59 at pp 62, 68-69 and 74-75. In the case of the fifth file cor_xlt_utils.c he did not identify this file but rather a file called cor_xlt_utilities.c: SBW-59 at p 68. Having consulted Motorola's particulars, it appears that Mr Brown has misnamed this file and that 'utils' should read 'utilities'. 1683 For the reasons I have given in relation to the corresponding files in the EMT, I do not accept Motorola's case about these four files based on the raf_arm9.lib object code. 7. CONCLUSIONS ON XLATE 1684 Motorola has succeeded in demonstrating that a substantial part of Xlate was copied into Hytera's source code and then compiled into its object code, specifically lines 227-287 of rs_xlt_utilities.c. The UIT Component 1. THE NATURE OF THE UIT 1685 I have briefly mentioned the role that the UIT plays in the user input system in the EMT section above. The UIT is responsible for managing the output to users. [Redacted]: MCS(C) Mod II(B) at [9]. 2. IDENTIFYING MOTOROLA'S CASE ABOUT THE UIT 1686 Motorola did not identify the files making up the UIT or those files from which it alleges code was taken or the lines of code which it says were copied. As in the case of the EMT and Xlate, the files can be identified from CMB-25 at p 23. There are ten files identified there. As in the case of Xlate, they may be grouped into four categories: (a) files where the alleged infringements relate to available Hytera source code which was discovered in the First Tranche of discovery; (b) files where the alleged infringements relate to available Hytera source code which was discovered in the Second Tranche of discovery; (c) files where the alleged infringements relate to available Hytera source code which was discovered in the Fourth Tranche of discovery; and (d) files where the alleged infringements relate to unavailable Hytera source code where Motorola seeks to prove that the missing Hytera source code contained lines of code copied from its files. It does this by resort to the disassembled Hytera object code contained in the library file raf_arm9.lib together with the surrounding circumstances. 1687 Again, I will deal with these separately. As with the Xlate, there are files within the UIT which have already been dealt with as part of the EMT. Where this occurs I refer to the previous treatment. 3. ALLEGED INFRINGEMENTS RELATING TO AVAILABLE HYTERA SOURCE CODE DISCOVERED IN THE FIRST TRANCHE OF DISCOVERY 1688 There are five files involved (CMB-25 at p 23): com_ergo_platform_app_defines.h com_cp_button_def.h svc_display_protocols.h com_ergo_platform_user_defines.h cor_uit_user_defs.h 1689 Dealing with each in turn: A. com_ergo_platform_app_defines.h 1690 This file has been dealt with as part of the EMT at [1391]. For the reasons given there, Motorola's infringement claim in relation to this file fails. B. com_cp_button_def.h 1691 This file has been dealt with as part of the EMT at [1401]. For the reasons given there, Motorola's infringement claim in relation to this file fails. C. svc_display_protocols.h (a) Objective Similarity 1692 In SBW-38 at pp 272-273, Professor Wicker identifies the following lines as having been copied into lines of the Hytera file raf_display.h and provides a side by side comparison. The competing lines of code are: svc_display_protocols.h raf_display.h 1 139-140 40-41 2 141-143 17-20 3 179 15 4 183-253 and 517 51-71 and 72-80 Lines 139-140 1693 Having examined these lines of code, I am satisfied they are objectively similar. Lines 141-143 1694 Having examined these lines of code, I am satisfied that they are objectively similar. Line 179 1695 These two lines are identical. Line 183-253 and 517 1696 The lines initially look quite different but this is because Motorola's comments have not been copied across. The substantive function prototypes declared by these lines are identical. I am satisfied that lines 51-71 and 72-80 of the Hytera file are objectively similar to the lines 183-253 and 517 of the Motorola lines. (b) Materiality 1697 This is a header file. Mr Ley explained in DJL-1 at §61 that he wrote svc_display_protocols.h and the functional code svc_display_protocols.c to [Redacted]. He also said at §74(c) that the header file declared [Redacted]. Professor Wicker gave evidence about the particular lines of code. Lines 139-140 1698 Professor Wicker said at SBW-38 at p 272 that these lines define a data type used for UIT request options. This is not sufficient for me to conclude that this declaration is a material part of the UIT. Lines 141-143 1699 Professor Wicker said at SBW-38 at p 272 that these lines define a set of constants which appeared to be the masks referred to at line 139. I have examined line 139 which does refer to a mask. I do not know what the mask is or does. Accepting Professor Wicker's evidence that the constants declared at lines 141-143 were the mask referred to at line 139, this does not assist me in understanding the qualitative contribution of lines 141-143. As such, I am unable to conclude that these lines are material to the UIT. Line 179 1700 Professor Wicker said that this line provided [Redacted]: SBW-38 at p 272. I would say it declares [Redacted]. Making the assumption that the UIT needs to deal with [Redacted], I can grasp that the functional code dealing with that situation would be material to the UIT's operation. I am not persuaded however that the declaration of [Redacted] for use by that code is material. It is a machinery matter. Line 179 is not a substantial part of the UIT. Lines 183-253 and 517 1701 Professor Wicker said that these lines provided service function prototypes: SBW-38 at p 272. The function to which those prototypes related were concerned with various display requests. I would accept that the functional code dealing with display requests would be a substantial part of the UIT. I am not satisfied however that these declarations of function prototypes satisfies the materiality requirement. (c) Conclusions on svc_display_protocols.h 1702 Motorola's infringement claim in relation to this file fails. D. com_ergo_platform_user_defines.h 1703 This file has been dealt with as part of the EMT at [1397]. For the reasons given there, Motorola's infringement claim in relation to this file fails. E. cor_uit_user_defs.h (a) Objective Similarity 1704 In SBW-38 at p 274, Professor Wicker identified the following lines as being copied by lines in the Hytera file raf_display.h: cor_uit_user_defs.h raf_display.h 1 92-119 26-29 and 30-38 1705 Having examined these I am satisfied that lines 28-29 of the Hytera file are objectively similar to lines 99-100 of the Motorola file, that Hytera lines 37-38 are objectively similar to Motorola lines 105-106, and that Hytera lines 31-35 are objectively similar to Motorola lines 112-116. (b) Materiality 1706 Mr Ley explained that this file included definitions for data types and functions [Redacted]: DJL-1 at §71. This does not tell me enough to assess the materiality to the UIT of these declarations for these data types and functions. For example, Mr Ley does not tell me what the functions are or the nature of the declarations disclosed by this header file. 1707 Professor Wicker expressed the view at SBW-38 at p 274 that these lines of code contained [Redacted]. I would accept that the functional code which [Redacted] is material to the UIT. However, without knowing more about the declarations in the header file, I am unable to assess their significance. 1708 It is not shown that these lines of code are material to UIT. (c) Conclusion on cor_uit_user_defs.h 1709 Motorola's infringement case in relation to this file fails. 4. ALLEGED INFRINGEMENTS RELATING TO AVAILABLE HYTERA SOURCE CODE DISCOVERED IN THE SECOND TRANCHE OF DISCOVERY 1710 Professor Wicker set out a list of the files and nominated lines of code relating to the Second Tranche without indicating to which work they belonged: SBW-57. He made comments on these files in SBW-56. There are three of these files (CMB-25 at p 23): cor_single_linked_list.h rs_application_id.h rs_uiopcode_list.h F. cor_single_linked_list.h 1711 This file is dealt with in the EMT at [1488]. For the reasons given there, Motorola's infringement case in relation to this file fails. G. rs_application_id.h 1712 This file is dealt with in the EMT at [1493]. For the reasons given there, Motorola's infringement case in relation to this file fails. H. rs_uiopcode_list.h 1713 This file is dealt with in the EMT at [1502]. For the reasons given there, Motorola's infringement case in relation to this file fails. 5. ALLEGED INFRINGEMENTS RELATING TO AVAILABLE HYTERA SOURCE CODE DISCOVERED IN THE FOURTH TRANCHE OF DISCOVERY 1714 Here a single file is involved. It is cor_single_linked_list.c. I have dealt with this file in the EMT at [1587]. For the reasons given there, Motorola's claim in relation to this file fails. 6. ALLEGED INFRINGEMENTS RELATING TO LOST HYTERA SOURCE CODE ARISING FROM THE DISCOVERY IN THE SECOND TRANCHE OF THE RAF_ARM9.LIB LIBRARY FILE 1715 There is one file involved: CMB-25 at p 23. It is com_ergo_platform_utils.c. I have dealt with this file in the EMT at [1510]-[1511]. For the reasons given there, Motorola's claim in relation to this file fails. 7. CONCLUSIONS ON THE UIT 1716 Motorola's claim in relation to the UIT fails. The Darwin Ergonomics Platform 1. THE NATURE OF THE DARWIN ERGONOMICS PLATFORM 1717 I have given an explanation of what the Darwin Ergonomics Platform does in the section dealing with the EMT. It is not necessary to repeat it. For present purposes, it may be understood as the loose confederation of the programs constituted by the five core components. 2. MOTOROLA'S CASE ABOUT THE DARWIN ERGONOMICS PLATFORM 1718 Motorola's submissions did not explain whether it relied upon files which, whilst not within the EMT, Xlate or UIT, nevertheless were within other parts of the Darwin Ergonomics Platform. However, the evidence suggested that there was such a case. 1719 I assume that Motorola's case on the Darwin Ergonomics Platform consists of its case on each of the EMT, Xlate and UIT (since each of these are a component of it) together with any additional files that its particulars identify as being within the platform but which are not files within any of those three core components. 1720 It is impossible to identify any file in this latter category from Motorola's submissions, SBW-38 or Motorola's particulars. However, as I will shortly explain, Motorola's evidence includes evidence which can only be about files of this kind, that is to say, evidence from Motorola about files which cannot be found within the EMT, Xlate or UIT but which are nevertheless certainly within the Darwin Ergonomics Platform. One begins by asking what files within the Darwin Ergonomics Platform Motorola alleges have been copied. 1721 Mr Brown provided a list of the files within the Darwin Ergonomics Platform which Motorola alleged that Hytera had copied. This was in CMB-25 at pp 18-20. This list was created by Mr Brown accessing the standalone laptop and applying Motorola's particulars to it. There are, of course, more files in the Darwin Ergonomics Platform than appear in the list at pp 18-20. This is a reflection of the fact that Motorola does not allege that all of the files in the Darwin Ergonomics Platform have been copied. 1722 Mr Brown also conducted a similar exercise for the EMT, Xlate and UIT at pp 20-23. By cross-referencing these lists with the list he has provided for the Darwin Ergonomics Platform, it is possible to detect files which are relied upon by Motorola as part of its case on the Darwin Ergonomics Platform but which fall outside the three components. 1723 I have conducted the cross-referencing task referred to in the previous paragraph to do what Motorola has not done. As a result of that exercise, I have identified five such files: svc_string_utils.h svc_string_utils.c cor_uiq_task.c cor_uiq_utils.c cor_double_linked_list.h 1724 Helpfully, Mr Brown's document also tells me where these files are mentioned in Professor Wicker's evidence. The first file is from the First Tranche of discovered source code whilst the next three files are part of the raf_arm9.lib disassembly. I have already explained why I do not accept Motorola's case on the raf_arm9.lib and I reject its case on these three files for the same reasons (noting that I have examined the list of function names associated with the three files in SBW-59 at pp 67-68 and 72). The remaining file appears in Professor Wicker's evidence in three places, SBW-56 at p 18, SBW-57 at p 60 and SBW-64 at p 121. However, as Mr Brown pointed out at CMB-25 at p 20, this file does not actually form part of Motorola's particularised case. Professor Wicker noted that as well in SBW-56 at p 18. Since it is not part of the particularised case, it is not necessary to deal with it. It is therefore only necessary to deal with svc_string_utils.h. A. svc_string_utils.h (a) Objective Similarity 1725 Dealing with the file svc_string_utils.h, Professor Wicker's treatment of this is at SBW-38 at p 274. He says that lines 124-142 have been copied into lines 44-62 of the Hytera file raf_string.h and provides a side by side comparison of the codes. I am satisfied that these are objectively similar and hence copied. (b) Materiality 1726 Professor Wicker says that this header file declares a data type and function prototype 'which contain information about the way in which display strings are formatted on the screen of the radio'. I assume that the functional code to which these relate use the variables and functions thus declared to [Redacted]. To take line 132 for example, I do not think that declaring that there will be a variable called [Redacted] contributes anything to the functional code to which it relates. I therefore do not accept that these lines are material to the Darwin Ergonomics Platform. 1727 Consequently, I do not accept that these additional four files lead to any relief for Motorola. 3. CONCLUSIONS ON THE DARWIN ERGONOMICS PLATFORM 1728 The only part of the Darwin Ergonomics Platform which Motorola has succeeded on is the Xlate file rs_xlt_utilities.c where I have concluded that Hytera copied lines 227-287 into its file ps_xlt_utilities.cpp. 1729 I conclude that by engaging in that copying, Hytera also copied a substantial part of the Darwin Ergonomics Platform. I do so because I am satisfied that lines 227-287 are not only material to Xlate but also material to the platform itself. The code in question determines the hardware source of the user input. Its place in in the overall structure of the platform is clear. 1730 Motorola's case on the Darwin Ergonomics Platform therefore succeeds. Mobile and Portable Firmware 1. INTRODUCTION 1731 At no point in its submissions did Motorola give any clear exposition of the nature of its case on the two works, the Mobile and Portable Firmware. However, it is apparent that it has two elements: (a) a case based on its case on the Darwin Ergonomics Platform (and therefore the EMT, Xlate and UIT and the four particularised files external to those three works but still within the Darwin Ergonomics Platform discussed in the previous section); and (b) a case based on a number of files which, whilst within both the Portable and Mobile Firmware, are not within the Darwin Ergonomics Platform. 1732 As to (a), I accept this case for the same reason I have accepted the case in relation to the Darwin Ergonomics Platform. The lines of code taken from the Xlate component were a substantial part of the Portable and Mobile Firmware for the same reason they were a substantial part of the Darwin Ergonomics Platform. 1733 As to (b), Motorola did not identify in its submissions what the files involved in this part of the case were. The third sentence of [139] in MCS(C) Mod II(E) glancingly refers to files which may be part of this case: [Redacted] 1734 This identifies six files as being involved: ListenerBase.h ListenerBase.cpp EventBase.h EventBase.cpp NotifierBase.h NotifierBase.cpp 1735 This single sentence is accompanied by fn 156 which refers me to the evidence of Mr Zetzl in DPZ-6 at §15. I am not referred to any definitive statement of what the additional files are. What Mr Zetzl says there is this: [Redacted] 1736 So at the end of Motorola's submissions I do not know: (a) what the files in question are, although I know they at least include the above six files; (b) where the evidence in relation to the source files is located (noting that Mr Zetzl is only discussing the header files); (c) any explanation of the structure of the Portable and Mobile Firmware. Thus whilst I am aware of the structure of the Darwin Ergonomics Platform, I am in the dark as to what else is within the Portable and Mobile Firmware beyond that platform; (d) the nomination of any lines of code of the Motorola files which are said to have been copied; (e) the identification of the Hytera files which are said to contain the copied code; (f) the identification of the lines of the Hytera files which are said to do the copying; and (g) any reference to where any of the expert evidence about these matters might be. 1737 I have considered whether it may be said that Motorola has failed to advance a case about these files. In my view, Motorola has not advanced such a case. My dispositive reason for dispatching this second element in Motorola's case on the Portable and Mobile Firmware is that Motorola's submissions simply do not advance it. In the event that this conclusion proves erroneous on appeal, I will nevertheless consider what the evidence shows. 2. WHAT FILES ARE INVOLVED? 1738 There is no way to determine this from Motorola's particulars or its written submissions. Mr Brown provides a list of files which are part of Motorola's particularised case on the Portable and Mobile Firmware at CMB-25 at p 24. The six files listed above are not on this list. Instead, they appear on a list which Mr Brown provides for those files which are: (a) part of Motorola's particularised case on the DSP Firmware; and (b) not part of the subordinate works contained within the DSP Firmware: CMB-25 at pp 27-30. Motorola's submissions at [139] noted above assume that the six files are part of all three sets of firmware. Despite that assumption, I have been unable to identify any evidence that this is in fact so and Mr Brown's evidence contradicts this assumption. Given that I have concluded that this part of Motorola's case should be dismissed on the basis that it has not been advanced, I do not propose to spend any more time trying to find these files within the Mobile and Portable Firmware. Instead, I will assume in Motorola's favour that the six files are indeed part of the Portable and Mobile Firmware and that Mr Brown has omitted them from his list at p 24 of CMB-25 through oversight. 1739 On that basis, the files involved consist of the list at CMB-25 p 24 with the additional six files mentioned above. These are as follows: vris.h app_powerup.c app_powerup.h powerup_app_launch_handler.c rs_cpvalue_list.h ListenerBase.h ListenerBase.cpp EventBase.h EventBase.cpp NotifierBase.h NotifierBase.cpp 3. WHERE IS THE EVIDENCE ABOUT THESE FILES LOCATED? 1740 For ListenerBase, EventBase and NotifierBase, the relevant evidence is as follows: (a) the three header files are dealt with by Professor Wicker in SBW-56 at pp 17-18; (b) the three source files are dealt with by Professor Wicker in SBW-66; and (c) there is a side by side comparison by Mr Brown of the three header files in CMB-13 at p 235. 1741 That leaves these files: vris.h app_powerup.c app_powerup.h powerup_app_launch_handler.c rs_cpvalue_list.h 1742 The last of these, it is true, is fleetingly referred to in fn 24 of Motorola's submissions. This footnote is attached to this statement 'As addressed further below, there is no debate as to the verbatim copying into intermediate files'. Apart from that, the other files are not mentioned in Motorola's submissions. 1743 A return to Mr Brown's list in CMB-25 at p 24 provides guidance. The first file is discussed by Professor Wicker in SBW-35 (and hence SBW-38) and the balance form part of his discussion in SBW-57 (and hence SBW-56). And, of course, to know SBW-56 is to know that Mr Brown has discussed the same files in CMB-13. 4. THE FILES A. vris.h (a) Objective Similarity 1744 Professor Wicker's explanation of this is at SBW-38 at p 275. He says that lines 90-108 of the Motorola file have been copied into lines 94-122 of the Hytera file rapis_def.h. He provides a side by side analysis and some textual commentary. Summarising and shortening: he thinks the two sets of code are the same but that [Redacted]. I accept this evidence. I find that that the two sets of code are objectively similar. (b) Materiality 1745 Professor Wicker does not attempt these issues himself but instead refers me to Mr Ley's affidavit at §20(b) which I assume is a reference to DJL-1 at §20(b). At §20, Mr Ley explains that the Darwin Ergonomics Platform was designed to be used on radios based on ROS/VRIS and the concept of HL/CL/LL as it had been implemented in earlier devices. HL/CL/LL refer to high level, common level and low level. The 'VRIS' is the Virtual Radio Interface Standard. It is, according to Mr Ley, a hardware abstraction layer between the low level code and higher levels of code. The advantage of this is that it enables the higher level layers of code (such as the core components of the Darwin Ergonomics Platform) to be designed for the VRIS rather than for the specific hardware being used on the device: DJL-1 at §20(b). 1746 So the VRIS is a hardware abstraction layer. Here, I regret, the trail runs cold. To know that the VRIS itself is a hardware abstraction layer does not help me to understand more about vris.h than that it is a header file which has got something to do with the hardware abstraction layer. On that slim basis I am unable to engage in the qualitative analysis called for in terms of materiality. I conclude that it is not shown that the lines in question are a material part of the Portable or Mobile Firmware. (c) Conclusions on vris.h 1747 Motorola's infringement claim in relation to this file fails. B. app_powerup.c (a) Objective Similarity 1748 Professor Wicker discusses this file at SBW-56 at pp 15-16. He says that much of it has been copied into the Hytera files app_default.cpp and app_cps.cpp with, inter alia, some changes to the coding but with no substantive impact on the logic of the code. He identifies a number of specific lines from Hytera file app_default.cpp (143, 193, 21, 6, 17, 83, 109, 120, 124, 165, 177, 10 and 216). He also says that this first Hytera file was a template file from which copying and thereafter modification in the second file occurred. 1749 He did not provide a side by side analysis of the codes. Without it, Professor Wicker's evidence is gloop. Mr Brown did one in CMB-13 at pp 221-227. He identifies the file and lines in dispute as follows: app_powerup.c app_cps.cpp 1 151-571 169-357 2 573-732 452-558 3 734-780 1452-1463 4 872-923 1410-1449 1750 He has not therefore dealt with the Hytera template file, app_default.cpp, which I do not have. I therefore disregard the case in relation to the template file. Mr Brown has dealt with the differing versions in the Mobile and Portable Firmware. Turning to the nominated lines: Lines 151-571 1751 Mr Brown in CMB-13 at p 223 agrees with Professor Wicker in SBW-56 that the overall structure of the functions is clearly similar although observing that the complete functionality is significantly different. Professor Wicker responded to bits of CMB-13 (see, for example, SBW-61 at §§45, 51(b)-(c)) but not to this bit and, of course, Motorola's submissions did not deal with actual lines of code. I must therefore weigh Professor Wicker's evidence that the code has been copied with some non-material changes against Mr Brown's evidence that the structure is similar but the complete functionality is significantly different. Mr Brown did not explain in what way the functionality differed. 1752 I have not found that the side by side comparison assists me in working out how to resolve this problem. At this point (and at other points too), I would have benefited from submissions from Motorola about the lines of code. 1753 Making the assumption that it is permissible to consider functionality as an indirect input into a structural analysis (a potentially controversial proposition), I do not know what the functional differences are. Because I do not know what the differences in functionality are, I am unable to assess what implications these differences might have for the structural analysis. As such, I do not think I can do much with Mr Brown's evidence about the functional differences between the two sets of code. This then leaves the evidence that the structure of the two sets of code is the same. I conclude on the basis of this evidence that the lines are objectively similar. Lines 573-732 1754 Mr Brown in CMB-13 at p 225 thought these two sets of lines had little similarity because they handled different 'states'. However, he also accepted that 'there is evidence of common origin in the comments and structure' although the functionality was different. Professor Wicker's evidence, it will be recalled, was that the changes to the Hytera code had no substantive impact on its logic. In that circumstance, I conclude that the structure of the two codes is similar although their functionalities differ. I therefore find that these lines are objectively similar. Lines 734-780 1755 Other than in relation to the similarity in the function names ('pwrUpSelfTerminate' and 'defaultAppSelfTerminate') Mr Brown saw no similarity between these lines of code: CMB-13 at p 226. So far as I can see, Professor Wicker did not respond directly to this evidence in SBW-61. I therefore have Professor Wicker's evidence in chief that the two sets of code have substantially the same logic, Mr Brown's evidence that they are not similar and, of course, I have the side by side analysis. My perusal of the competing codes has not persuaded me in either direction since I am unable to plumb the logic of the code to test or understand Professor Wicker's evidence about that logic. I can see no rational way to choose between the evidence of Professor Wicker and Mr Brown on these lines of code. 1756 Consequently, I am unable to form a view on the issue. Since Motorola bears the burden of demonstrating objective similarity, it fails. Lines 872-923 1757 Mr Brown thought these files were not identical and that many of the details differed: CMB-13 at p 227. Nevertheless, he accepted that there was 'a clear similarity between the two in the operations performed and the order of these operations'. If the operations performed by the Hytera code are similar to the operations performed by the Motorola code and it does so in the same order, it is open to infer that the Hytera code has a similar structure to the Motorola code. I draw that inference. I therefore conclude that these lines are objectively similar. (b) Materiality and Originality 1758 Professor Wicker does not tell me what this file does or where it fits in. As it happens, there is evidence about this in Mr Ley's evidence: DJL-23 at §§43-49. I have consulted Motorola's submissions to see whether they refer to this evidence. They do in MCS(C) Mod II(E) at [138(d)] but only to state that this evidence relates to the Darwin Ergonomics Platform rather than the Mobile and Portable Firmware. This would appear to be erroneous. 1759 Returning to Mr Ley's evidence, he said that he had written this code. He explained that the power-up function was launched when the radio was powered up. It waits for all expected internal hardware statuses and external (accessory) devices to power up, checks if there are any internal or external errors, and then broadcasts the power up status of the radio. He then turned to what particular lines of the code do. So far as the lines above are concerned he only gives explanations for the code starting at 211, 559, 573, 734, and 872. I will not set these out but they are at §47. I am satisfied that Mr Ley's evidence describes what the lines do and that the lines are material to the operation of the program. 1760 Motorola has not provided a general description of what is in the non-Darwin core part of the Mobile and Portable Firmware. However, plainly, it must include the power-up function. However, even without knowing what else lurks in the non-Darwin core part of the Portable and Mobile Firmware, I am satisfied that the power-up function is material to them. Turning the radio on matters. Further, I am satisfied that the codes beginning at 211, 559, 573, 734 and 872 are material to the Portable and Mobile Firmware too. (c) Conclusions on app_powerup.c 1761 Had it been put, Motorola's infringement claim would have succeeded in relation to lines 151-571, 573-732 and 872-923. D. app_powerup.h (a) Objective Similarity 1762 This file is discussed by Professor Wicker in SBW-56 at §§46-48. Mr Brown provides a side by side comparison in CMB-13 at pp 220-221. The lines of code and the Hytera file involved are (recalling in the case of the Hytera files that declarations can occur in a source file and need not be located in a header file): app_powerup.h app_cps.cpp 1 74-81 82-89 2 84-103 91-98 3 105-119 101-119 4 192-202 121-136 Lines 74-81 1763 Professor Wicker and Mr Brown disagree about these lines. Although I am prepared to accept that a header file may have structural aspects, I do not think that this one does. It defines an enum. The entries for the enum have different names. On the other hand, it is clear that the programmer of the Hytera file understood this header file to fit into the functional code in the same way. The comments for both header files make clear that what these lines do is to define the possible power up states. I conclude that, notwithstanding the different names, the Hytera lines are objectively similar to the Motorola lines. Lines 84-103 1764 Professor Wicker and Mr Brown disagree. This part of the header defines a struct. Having examined both sets of code, I am not satisfied that they are objectively similar. Lines 105-119 1765 Mr Brown agreed with Professor Wicker that the overall structure of these lines were similar. I conclude that these are objectively similar. Lines 192-202 1766 Professor Wicker thought the Motorola and Hytera files were essentially the same: SBW-56 at §§46-47. Although limiting himself to particular lines, Mr Brown agreed that there were similarities: CMB-13 at pp 220-221. He did not contradict Professor Wicker's more general evidence. Having examined them, I conclude that these lines are objectively similar. (b) Materiality 1767 I infer that this header file relates to the source file app_powerup.c dealt with immediately above. As I have there explained, I am satisfied that the source file is material to the portable and Mobile Firmware. The question then is whether these lines of the corresponding header file are also material to the operation of the portable and Mobile Firmware. In principle, the struct could have been included in app_powerup.c. It is practical matters (relating to accessibility and ease of compiling) which caused them to be included in a header file. In the case of this header file, it is possible to determine its relation with the corresponding source file. Whilst I have generally not accepted Motorola's case about header files, this one seems to me to be in a different category. I therefore accept that it is material to the Portable and Mobile Firmware. For example, elements of the struct are clearly identifiable in the functional code for app_powerup.c: see CMB-13 at p 222. (c) Conclusions on app_powerup.h 1768 Motorola's infringement claim in relation to lines 82-89, 101-119 and 121-136 of the Hytera file app_cps.h would have succeeded had such a case been put. E. powerup_app_launch_handler.c 1769 Professor Wicker deals with this at SBW-56 at §54 and Mr Brown at CMB-13 at p 227. The files and lines involved are: powerup_app_launch_handler.c app_cps.cpp 1 71-197 361-378 (a) Objective Similarity 1770 Professor Wicker thought these lines were 'essentially identical'. Mr Brown agreed and said that they constituted the whole of the function 'cps_app_launch_handler' although he observed that the Motorola file involved many more lines of code. However, I am not examining the code for the whole function, just these lines. I conclude that these are objectively similar. (b) Materiality 1771 I have been unable to locate a discussion of this file in Motorola's submissions. However, Mr Ley discusses it in DJL-23 at §48. He said that the code beginning at line 179 contains the function 'pwrUpInitAdb'. These lines appear in Mr Brown's side by side analysis of the code at lines 71-197. Mr Ley told me that the file (which I take to mean the whole file) handled an LTD-specific requirement for powering up via non-traditional means, such as an emergency footswitch rather than the normal power switch. [Redacted]. My inspection of lines 71-197 is not consistent with Mr Ley's evidence being about 'pwrUpInitAdb' at lines 179ff and it seems to me that he is discussing what powerup_app_launch_handler.c does. 1772 I am unable to assess the materiality of lines 71-178 since Mr Ley does not say anything about those lines. In relation to lines 179-197, I accept that these are the code for the 'pwrUpInitAdb' function but I do not know what that function is. As such, I am unable to assess its significance to the overall structure of powerup_app_launch_handler.c. I therefore conclude that it is not shown that these lines are material to the Portable and Mobile Firmware. (c) Conclusion on powerup_app_launch_handler.c 1773 Had Motorola's infringement claim been advanced in relation to this file it would have failed. F. rs_cpvalue_list.h 1774 This file is discussed by Professor Wicker at SBW-56 at §§55-56 and by Mr Brown at CMB-13 at pp 227-232. Professor Wicker responds to Mr Brown's evidence at SBW-61 at §51(c). Motorola mentions this file in fn 24 of MCS(C) Mod II(E). The files and lines involved are: rs_cpvalue_list.h ps_cpvalue_list.h 1 1-203 1-257 (a) Objective Similarity 1775 Professor Wicker's evidence in SBW-56 at §55 is directed to the version of the Hytera file in the RAF library directories. As I have previously explained, the files in that directory were not compiled into Hytera's object code and are not directly relevant to Motorola's adaptation case. Mr Brown correctly considered the version in the Application directories. Professor Wicker criticised him for this in SBW-61 at §51(c) but the criticism is not well founded. 1776 Professor Wicker's evidence about the version in the Application directories was at SBW-56 at §56. He thought these included the versions in the RAF library but with 'some further minor changes'. I have previously observed that Hytera programmers had used the versions in the RAF library directories. The small modifications he identified were the change of the constant cp_vol to cp_volknob and the addition of a new first entry cp_null which had resulted in the value of each subsequent constant being increased. 1777 Mr Brown accepted that many of the names were the same but that the values were all different. For example, the Motorola value for cp_vol is 0x02 whereas the value for Hytera's cp_volknob is 0x03. In reply in SBW-61 at §51(c), Professor Wicker said that the difference in values was accounted for by the addition of cp_null in the Hytera lines. I accept this evidence. Mr Brown also thought that following the compilation, the object code would be significantly different. No doubt this is true due to the offset caused by cp_null. However, a difference in the object code is a red herring. The correct question is whether the lines of the Hytera header file are objectively similar to the lines of the Motorola header file. In my view, they are. 1778 Motorola's submission at fn 146 related to some examination of Mr Brown at T558.15-29 where it was said Mr Brown had accepted that the copying in relation to this file was verbatim. His acceptance is in line with the conclusion I have reached. (b) Materiality 1779 None of Motorola, Professor Wicker or Mr Brown said what this file does but Mr Ley says something about it in DJL-23 at §§41-42. The header file defines feature values that are programmed to user inputs (buttons, menus and switches). These codes are accessed by Xlate [Redacted]. I do not accept that the mere definition of a set of a variable type is sufficient to constitute a material part of whatever program this actually connected to. (c) Conclusions on rs_cpvalue_list.h 1780 Motorola's infringement claim in relation to this file would have failed had it been advanced. 1781 This brings one to the six header and source files concerning the three functions ListenerBase, EventBase and NotifierBase which are actually referred to in Motorola's submissions. G. ListenerBase.cpp (a) Objective Similarity 1782 Professor Wicker identifies the Hytera file as ListenerBase.cpp. He deals with these two files (Motorola and Hytera) in SBW-66 at §19. He says the two functions identified in the Hytera file are identical to the Motorola code. However, he did not set either code out and I do not have a side by side comparison of the source files. I have the benefit of the experts' common comment which appears in the JEWC-2 at pp 5-6 in response to Q4(a). The experts there agreed in relation to, inter alia, the four recently discovered source files (including this one) which had originally only been accessible as object code in the cpa_c55.lib library file that 'it is clear that Hytera's CPA libraries were likely compiled from Hytera files containing instances where there are exact or close matches to corresponding Motorola files'. This assumes, but does not state, that the four Hytera source files are exact or close matches with the corresponding Motorola files. 1783 In fact, in relation to one of those four pairs of files, the Motorola file cor_single_linked_list.c and the Hytera file SingleLinkedList.cpp, I have actually concluded above in the EMT section that Motorola has not established objective similarity. The evidence therefore consists of the unarticulated assumption in JEWC-2 at pp 5-6 limited to three of the four files, and the evidence of Professor Wicker. 1784 Since I have not been shown the competing codes next to each other, I am disinclined to act on this evidence. Without a side by side comparison it is not possible to assess the value of Professor Wicker's evidence. For much of these reasons for judgment, my unwillingness to reach a conclusion on objective similarity in the absence of a side by side comparison has been ameliorated by the fact that Mr Brown had himself performed in many cases just such an analysis. In the case of this file, however, that is not so. 1785 Further, elsewhere in these reasons, I have from time to time rejected Professor Wicker's evidence that two sets of competing code are materially the same. For similar reasons, acting on the barely articulated assumption in JEWC-2 at pp 5-6 that the four Hytera and Motorola source files are exact or close matches without seeing the codes next to each other myself, strikes me as potentially risky where that barely articulated assumption is made by reference to one file where I have concluded that objective similarity is not established. 1786 In those circumstances, I do not conclude that Motorola has established that this file is objectively similar to its file. (b) Materiality 1787 In MCS(C) Mod II(E) at [139], Motorola submitted that ListenerBase.cpp (and EventBase.cpp and NotifierBase.cpp and each of their corresponding header files): … provide a paradigm for communication between different components of the Mobile and Portable Firmware (as well as the DSP Firmware) and, as with other [sic – unidentified] parts of the copied code, influence the form of other code in that they are 'inherited' by other components to enable them to communicate with one and other. 1788 The evidence for this is said to be in an annexure to Mr Zetzl's second affidavit, DPZ-6 at §15. However, what Mr Zetzl discusses there is not the source files but the header files. He says: [Redacted] 1789 I reject Motorola's submission that this evidence concerns the source file which is wrong. 1790 Since there is no evidence about what this file does I do not conclude it is a material part of the Portable and Mobile Firmware. I have considered whether I can repurpose Mr Zetzl's evidence set out above about the header file and treat it derivatively as some sort of statement about the source file. I do not think that I should. (c) Conclusions on ListenerBase.cpp 1791 Motorola's infringement claim in relation to this file would have failed had it been advanced. H. ListenerBase.h 1792 Professor Wicker deals with this file in SBW-56 at p 17 and Mr Brown deals with it at CMB-13 at pp 235-236. Mr Brown identified the files and lines as follows: ListenerBase.h ListenerBase.h 1 1-68 1-50 (a) Objective Similarity 1793 Professor Wicker thought there were some differences but that the lines were almost identical once the comments were removed (as they should be since they are not compiled). Mr Brown agreed in CMB-13 at p 240 that they were fundamentally the same once the comments were removed. I therefore find the lines of code to be objectively similar. (b) Materiality and Originality 1794 Mr Zetzl's evidence at DPZ-6 (above) is about this file. I assume that there is some functional code somewhere inside the Portable and Mobile Firmware that provides for a component to listen for notification of an event. I accept Mr Zetzl's evidence that this header file defines connection types and methods of communication that are permitted by the 'GCP'. As he explained in DPZ-1, this stands for the 'global common platform'. Figure 1 in DPZ-1 is as follows: [Redacted] 1795 Mr Zetzl explains that the GCP is the part shaded in green. In this case, I am prepared to accept that this header file is a material part of the Portable and Mobile Firmware. Since the communications happen between a large number of constituent elements of different sets of code, the definition of the connection types and methods of communications is not a mere declaration. Rather, it must reflect an underlying architectural unity in the GCP. I therefore accept these lines are material to the Portable and Mobile Firmware. (c) Conclusions on ListenerBase.h 1796 Motorola's infringement case in relation to this file would have succeeded had it been advanced. I. EventBase.cpp, EventBase.h, NotifierBase.cpp and NotifierBase.h. 1797 The issues which arise from these files are the same as those which arise from ListenerBase.cpp and ListenerBase.h. My conclusions are the same. Had the case been advanced, Motorola would have failed on the source files and succeeded on the header files. 5. CONCLUSIONS ON THE MOBILE AND PORTABLE FIRMWARE 1798 Motorola's case succeeds in relation to the lines of code copied from the Xlate component. Its submissions did not adequately advance its case in relation to files located outside the Darwin Ergonomics Platform and is rejected for that reason. If I have erred in reaching that conclusion, Motorola's case about these non-platform files succeeds in relation to the files I have indicated above. The L1 Timer 1. INTRODUCTION TO THE DSP FIRMWARE 1799 The L1 Timer is a component within the DSP Firmware. It is necessary now to give some brief explanation of where the DSP Firmware fits into the picture. Mr Zetzl gave evidence about this in DPZ-1 at §10. Each mobile and portable device contains two processors. One is known as the host processor which runs most of the radio firmware and applications. The other is called the 'digital signal processor' or 'DSP'. It is responsible for low-level audio processing. The firmware for the host processor is known as the host firmware (or as I have called it the Portable and Mobile Firmware). The firmware for the DSP is known as the DSP Firmware. 1800 The components in the DSP Firmware are illustrated in a diagram provided by Mr Zetzl in DPZ-1 at §24. I have set this diagram out before but it is useful to set it out again: [Redacted] 1801 It will be seen that the DSP Firmware is in the bottom right hand corner in a black box marked 'DSP'. Motorola identifies five works involving the DSP. These are the: DSP Firmware (it will be apparent that this consists of the 17 components in the box above); Framer; L1 Timer; framerLib Library; and HAL Serial Buffer. 1802 It will be noted that the framerLib Library and the HAL Serial Buffer do not appear in the diagram. As I understood it, framerLib Library was another name for what Motorola referred to as the L1 Timer subsystem and consisted only of Framer and L1 Timer. At this stage, it is convenient to assume that the HAL Serial Buffer is part of the HAL. HAL is an acronym for 'hardware abstraction layer'. 1803 To enhance clarity, I will deal with L1 Timer then move to Framer. Once they have both been considered, it will be possible to understand how Motorola's case about framerLib Library works. Having done that, I will consider the position of the HAL Serial Buffer. Having considered these components, I will then consider the broader case about the DSP Firmware. 2. THE NATURE OF L1 TIMER 1804 The L1 Timer and Framer work together. Although I will explain this in more detail later when dealing with Framer, it will suffice for present purposes to note that Framer [Redacted]. The evidence of Mr Simms touched on this aspect of the matter in more detail. Mr Simms was involved in the writing of the L1 Timer. 1805 In MES-1, Mr Simms explained the L1 Timer subsystem which consists of the L1 Timer together with Framer (amongst other components). [Redacted]. 1806 What the L1 Timer subsystem appears to do in a precisely timed fashion is to control the behaviour of the radio. [Redacted]. 1807 [Redacted]. 1808 [Redacted]. 1809 [Redacted] 1810 At §17 he explained that the purple shading indicated that these three elements were protocol agnostic. Thus, as adverted to above, these three elements are indifferent as to whether the protocol is FDMA or TDMA. Mr Simms also annexed a document entitled 'DSP L1 Timer Requirements' as MES-4. At section 1.4.1 of that document an overview is provided in these terms: [Redacted] 1811 At section 1.6.2 the requirements for the L1 Timer's basic operation are specified: [Redacted] 1812 [Redacted]. From this, one may discern that the L1 Timer: provides for [Redacted] which are used to interact with other components of the radio hardware. I assume that these relate to physical steps such as, but not limited to, signal generation; it processes [Redacted] allowing the radio to be made to do particular things at precisely determined times (such as, I imagine, transmitting a binary bit on the frequency); [Redacted]; [Redacted]; and [Redacted]. 1813 At section 1.6.3, [Redacted]: [Redacted] 1814 From this, one may discern that another function of the L1 Timer is to handle the process of frame synchronisation (as discussed in the 764 Patent). 1815 At section 1.6.4 [Redacted]: [Redacted] 1816 It is not entirely clear to me what this means (and Motorola did not seek to explain it), however, it is clear that this topic is a third field of activity for the L1 Timer. 1817 It can be seen therefore that the L1 Timer does three things in broad terms: [Redacted] 3. IDENTIFYING MOTOROLA'S CASE ABOUT L1 TIMER 1818 It is not possible to identify the files which constitute the L1 Timer from Motorola's particulars since they are not broken down by reference to the works in suit. Motorola's submissions do not identify the files involved or the lines of code involved. In CMB-25 at p 25, Mr Brown identifies three files from the L1 Timer which he says Motorola's particulars allege to have been copied from. These are: event_codes.h l1timer.h l1timer.cpp 1819 Mr Brown says that the first two files are referred to by Professor Wicker in SBW-35 from which it may be deduced that these files were discovered in the First Tranche of discovery. Evidence about these two files is therefore readily locatable in SBW-38 where Professor Wicker has done a side by side comparison of the source codes with a commentary. 1820 Mr Brown says that the third file is referred to in SBW-63. SBW-63 consists of a list of function names which Professor Wicker has identified from the disassembled object code for the rfhal_c55.lib library file. This library file has not previously been discussed in detail but, as will be seen, it follows a similar trajectory to that of the raf_arm9.lib library file discussed in the EMT component (and other components). Mr Hayes, the patent attorney, applied disassembly software to the library file, the output of which was then provided to Professor Wicker: SBW-61 at §§75-76. Professor Wicker identified file and/or function names within the disassembled code which were the same as or similar to file and/or function names he had seen before. He tabulated these into SBW-63. The left column of SBW-63 lists each file shown in the disassembled object code and, for each such file, the function names indicated in the disassembly materials are also listed. Where Professor Wicker detected that a file name matched a Motorola file, he listed the location of the Motorola file in the corresponding right column. Where he detected a match of a function name within that file, he aligned the entry in the right column to the function names in the left column. Having done so, he expressed the view in SBW-61 at §82 that the degree of similarity suggested that it was 'highly likely' that the rfhal_c55.lib library file contained code which had been copied from Motorola code. I take this to mean that he thought that it was highly likely that the missing intermediate source code contained code which had been copied from Motorola code and that the missing intermediate source code had been compiled into rfhal_c55.lib. 1821 In any event, the point for present purposes is only to note that Motorola does not know exactly what copying has occurred because the intermediate source code is missing. In its particulars, it says that the whole of l1timer.cpp has been copied by rfhal_c55.lib. This cannot literally be correct because one is in source code and one is in object code. I take it to be a rolled up way of alleging that all of l1timer.cpp was copied into the missing source code which was compiled into rfhal_c55.lib. 4. THE THREE FILES 1822 Turning then to the three files: A. event_codes.h (a) Objective Similarity 1823 In SBW-38 at pp 276-279, Professor Wicker identified lines 1-270 of this file as having been copied into lines 1-240 of the Hytera file eventcode.h. Having examined the code, it is apparent that there has been verbatim copying. The only differences relate to the comments at lines 1-17 and 256-266 of the Motorola file which have not been copied into the Hytera file. Since they do not impact on the compiled code I conclude that objective similarity is demonstrated. (b) Materiality 1824 Leaving aside the comments at lines 1-17, Professor Wicker identified the purpose of these lines 1-270 of code as [Redacted]: [Redacted] 1825 [Redacted]. 1826 [Redacted]. 1827 So viewed, it is apparent that the source file could have been written without the [Redacted]. Instead, the programmers could simply [Redacted]. But this would have made the code difficult to read and would not have been able to be shared between different source files. 1828 I therefore accept Hytera's submission that these lines of code are not instructions which are executed in any radio device: HCS(C) Mod II at 219. The [Redacted] is, after all, an instruction to the pre-processor. [Redacted]. Hytera did not submit, and I do not find, however, that these lines of code have no impact on the source file. The effect of the pre-processor is that [Redacted]. Nor do I find that it can be said that these lines of code have no impact on the compiled object code. [Redacted]. It would be possible to circumvent this problem by [Redacted]. However, this would be cumbersome from a programming perspective because the programmers would need constantly to [Redacted]. It would open up a much greater potential for error. 1829 Hytera submitted that there was no necessary connection between the structure of the code in the source file and the form of expression in a header file: HCS(C) Mod II at [221]. That may be so. However, in this case it is known from Mr Simms' evidence that one of the three functions of the L1 Timer is [Redacted]. No doubt there is substantial programming work involved in establishing the means by which the [Redacted]. 1830 I am nevertheless unable to discern from that description that the structure of this header file is reflected in the structure of the source code which performs this feat. At best, [Redacted]. How [Redacted] is governed by a host of other questions such as [Redacted]. 1831 On balance, I would not be prepared to conclude that this header file impacts the structure of the source file. I am not therefore satisfied that it is material to the code. 1832 Accordingly, I do not accept that these lines of code are a substantial part of the L1 Timer. (c) Conclusions on event_codes.h 1833 Motorola's infringement claim in relation to this file fails. B. l1timer.h (a) Objective Similarity 1834 In SBW-38 at p 280, Professor Wicker identified lines 102-108 of this file as having been copied into lines 61-67 of the Hytera file rfhal.h. Having examined the codes, I conclude that the lines of the Hytera file are objectively similar to the lines of the Motorola file. (b) Materiality 1835 Motorola made no submissions about this. 1836 Professor Wicker referred me to §§75-77 of Mr Simms' MES-1. Mr Simms explained that this file [Redacted]. 1837 To digest this it is necessary to deal with some issues of terminology. [Redacted]. Secondly, an array is a systematic arrangement of objects. Thirdly, the concept of a 'structure' was explained by Professor Wicker in SBW-32 at §§33-34. A structure is a composite data type which can be a collection of variables. In C++ a structure is established by the command 'struct'. He gave this example: [Redacted] 1838 Lines 102-108 are as follows: [Redacted] 1839 In light of Professor Wicker's evidence, what these lines of code do is to establish [Redacted]. 1840 Reference has already been made to the fact that the L1 Timer [Redacted]. The [Redacted] is therefore a [Redacted] by which such [Redacted] may be expressed. It goes without saying that it is not the actual [Redacted] themselves. It is simply a defined concept in which such [Redacted] may be included. 1841 Mr Simms explained in MES-1 at §77 the significance of these lines as follows: [Redacted] 1842 I take from this that [Redacted] are constructed from [Redacted] and that [Redacted] are [Redacted] stored in the form of the [Redacted] established by [Redacted]. The structure of each [Redacted] is therefore a [Redacted] whose [Redacted] in the format declared by [Redacted]. I take from Mr Simms' evidence that the [Redacted] and, with it, the [Redacted] structure, is important to the operation of the L1 Timer. 1843 Whilst I accept that the [Redacted] structure is important to the L1 Timer, I do not think that it was dictated by [Redacted]. Rather, it is the other way around. The [Redacted] are how a significant part of the L1 Timer operates but the fact that the L1 Timer uses the [Redacted] does not follow from the declaration of [Redacted]. MES-4 is a Motorola document authored by Mr Simms which is entitled 'DSP L1 Timer Requirements'. It sets out the requirements which the L1 Timer was to achieve. Section 1.6.2 of that document shows that [Redacted] were regarded as fundamental to its basic operation. By contrast, the general requirements set out at section 1.5.1 say that 'The L1 Timer shall be released with header files'. From this I infer that the [Redacted] structure did not come from [Redacted] but rather was inherent in the design of the L1 Timer itself, whilst the header file was merely released with the L1 Timer and not an essential part of it. Further, as I explain when dealing with Framer, [Redacted]. 1844 Having decided that pairs were to be used in the substantive source file, it seems to me that the decision to [Redacted] is just a mechanical exercise giving effect to an anterior design choice. I do not mean by this conclusion to suggest that the copying of L1 Timer with its [Redacted] might not have involved the taking of a material part of the functional code for it. However that is not what is alleged. (c) Conclusions on l1timer.h 1845 Motorola's infringement claim in relation to this file fails. C. l1timer.cpp (a) Objective Similarity 1846 As I have explained above, the relevant Hytera source code is missing and what is involved is Professor Wicker's file and function name matching process conducted on what could be won from the disassembled library file rfhal_c55.lib. For the reasons I have given in relation to the same process conducted in relation to the raf_arm9.lib file in the works comprising the Portable and Mobile Firmware, I am not satisfied that it is shown that the missing Hytera source code is objectively similar to this file. (b) Materiality 1847 I was not taken to any evidence about what l1timer.cpp actually did. Mr Simms told me in MES-1 at §59(c) that all of the source code for the L1 Timer was located in the directory 'l1timer\:'. However, I do not know what is in that directory. Even so, I am prepared to infer that this file contains some of the source code for the L1 Timer. At §65, Mr Simms discusses some files in the L1 Timer but not this one (although he discusses the header file with the same name). In MES-14 at §7, he discusses a number of other files from the DSP Firmware but, again, this is not one of them. Mr Zetzl touches on the L1 Timer in DPZ-1 at §86 but does not discuss this file. Motorola's submissions do not mention it. 1848 I think it is possible that this file is the source code file which contains the functional code for the L1 Timer. The name suggests this to be so. However, I do not know the names of all of the files in the L1 Timer, although I do know the names of the files which Motorola alleges have been copied: CMB-25 at p 25. On balance, since I do not know what the file does I cannot say that it is material. (c) Conclusions on l1timer.cpp 1849 Motorola's claim in relation to this file fails. 5. CONCLUSIONS ON THE L1 TIMER 1850 Motorola has not demonstrated that a substantial part of the L1 Timer was copied by Hytera into its source code. The infringement claim fails in respect of this work. Framer 1. NATURE OF FRAMER 1851 I have briefly described what Framer does above in the treatment of the L1 Timer. In short, [Redacted]. Evidence about the Framer was given by Mr Simms who provided a copy of a document entitled 'DSP Framer Requirements' in MES-3 of which he was the author and which sets out the requirements for the software to instantiate Framer. At section 1.4.1, there is an overview in these terms: [Redacted] 1852 This is followed by the same diagram I have set out above when dealing with the L1 Timer. At section 1.6.2, the architectural requirements are set out. These are: [Redacted] 1853 Four aspects of this should be noted. [Redacted]. 1854 At section 1.7 there appears 'Runtime Framer Requirements'. At that section this appears [Redacted]: [Redacted] 1855 [Redacted]. 1856 Mr Simms' evidence about Framer was in MES-1 at §22. He said that it [Redacted]. 2. IDENTIFYING MOTOROLA'S CASE ABOUT FRAMER 1857 Motorola's submissions do not identify the files or lines of code involved in its case on Framer. Mr Brown identifies the files in question in CMB-25 at pp 24-25. They are: frame_list_primitive.h frame_primitive.h default_frame_list.cpp frame_list_primitive.cpp frame_primitive.cpp framer.cpp run_dvi.cpp 1858 From CMB-25 at p 24 one may deduce that the first two of these files are discussed by Professor Wicker in SBW-35 and hence that he deals with them in SBW-38; that is to say, they are source code files discovered in the First Tranche. From CMB-25 at pp 24-25 one may deduce that the remaining five files are mentioned in SBW-63. SBW-63 is explained in SBW-61. At SBW-61 at §§74ff, Professor Wicker explains that the same process of disassembly as had been conducted on the raf_arm9.lib library file, was also conducted on two other library files: the CPA library (two versions, namely, cpa_arm9.lib and cpa_c55.lib) and rfhal_c55.lib. As I have discussed above in relation to L1 Timer, what this means is that the Hytera source code is not available and that Professor Wicker, with the assistance of Mr Hayes, has traced the similarities between the file and function names retrieved from the disassembled Hytera object code and the nominated Motorola files. 3. THE FILES A. frame_list_primitive.h (a) Objective Similarity 1859 In SBW-38 at pp 280-281, Professor Wicker said that the following lines of the Hytera file rfhal.h had been copied from the following lines of the Motorola file frame_list_primitive.h: frame_list_primitive.h rfhal.h 1 52-65 61, 78-89 2 73-120 95, 138-183 1860 I have examined both of these in Professor Wicker's side by side comparison in SBW-38. I am satisfied that they are objectively similar. In light of Hytera's concession, I therefore conclude that the Motorola lines of source code were copied by Hytera into its file rfhal.h. (b) Materiality Lines 52-65 1861 Mr Simms dealt with lines 54-65 in MES-1 at §87. He said that it defined a 'union' called event_control_t. Professor Wicker told me at SBW-32 that a union was a kind of custom data structure like an enum and a struct. Whilst he explained what an enum and struct were, he did not give an explanation of what a union was. Motorola's submissions did not make any submission about what a union was either. 1862 On the other hand, Mr Simms gave this explanation of lines 54-65: [Redacted] 1863 Professor Wicker's comments on these lines of code in SBW-38 at p 280 were that: [Redacted] 1864 Doing the best I can, it seems from Mr Simms' evidence that [Redacted]. 1865 I have dealt with header files above in relation to L1 Timer. Since I do not know what a 'union' is I am unable to assay whether it impacts on the structure of the code (unlike the struct or enum commands in the case of the L1 Timer). As such, I am not satisfied that Motorola has demonstrated that it does have a structural impact and is therefore material. Lines 73-120 1866 Mr Simms gave evidence about lines 92-118 in MES-1 at §§14 and 85 as follows: [Redacted] 1867 Professor Wicker's evidence about it was at SBW-38 at p 280: [Redacted] 1868 I understand this to mean that [Redacted]. Motorola made no submissions about this. I do not understand this evidence. As such, Motorola has not proven that these lines of code are material to Framer or that they are original. (c) Conclusions on frame_list_primitive.h 1869 Motorola's claim in relation to this file fails. B. frame_primitive.h (a) Objective Similarity 1870 Professor Wicker, in SBW-38 at pp 281-282, said that the following lines of the Hytera file rfhal.h had been copied from the Motorola file frame_primitive.h: frame_primitive.h rfhal.h 1 49-95 95-133 1871 I have examined Professor Wicker's side by side comparison in SBW-38 and am satisfied that these lines of code are objectively similar. (b) Materiality and Originality 1872 Mr Simms' evidence about this was in MES-1 at §§80-81: [Redacted] 1873 Professor Wicker's evidence was at SBW-38 at p 281: [Redacted] 1874 Motorola made no submissions about this evidence. I do not understand it. Consequently, I cannot conclude either that these lines of code are material to the operation of Framer. (c) Conclusions on frame_primitive.h 1875 Motorola's claim in relation to this file fails. C. default_frame_list.cpp (a) Objective Similarity 1876 This file is not mentioned in Motorola's submissions. As I have explained above, the infringement claim for this and the remaining files is based on what can be inferred from the disassembly of the library file rfhal_c55.lib file. In its particulars, Motorola identifies that the whole of this file has been copied into rfhal_c55.lib: Confidential Annexure 2 at p 56. Professor Wicker's survey of the file and function names retrieved from the disassembly of rfhal_c55.lib begins at p 85 of SBW-63. For the reasons I have given in relation to the L1 Timer, objective similarity is not established. (b) Materiality 1877 I have not been able to locate any discussion of what this file does in Motorola's submissions, Mr Zetzl's evidence in DPZ-1 or DPZ-6, or in Mr Simms evidence in MES-1, MES-14 or MES-15. I have considered whether anything about the functionality of this file can be inferred from its name. As in the case of l1timer.cpp, I conclude that I should not. Consequently, I do not know what this file does and cannot infer anything about materiality. (c) Conclusions on default_frame_list.cpp 1878 Motorola's claim fails in relation to this file. D. frame_list_primitive.cpp (a) Objective Similarity 1879 Professor Wicker's treatment of the function and file name matches with the disassembled code from rfhal_c55.lib is at SBW-63 at pp 86-87. For the reasons I have given above in relation to default_frame_list.cpp I conclude that it is not shown that the missing source code is objectively similar to frame_list_primitive.cpp. (b) Materiality 1880 Whilst Mr Simms discusses a header file with the same name at MES-1 at §85, he gives no evidence about the source file. Motorola did not submit that I should infer that the functionality Mr Simms described in relation to the header file should be assumed to apply to the source file with the same name. Indeed, it made no submission about the file at all. I do not infer its functionality from its name. I am unable to conclude that this file is material. (c) Conclusions on frame_list_primitive.cpp 1881 Motorola's infringement claim in relation to this file fails. E. frame_primitive.cpp (a) Objective Similarity 1882 Professor Wicker's analysis of the file and function name matches is at SBW-63 at pp 88-89. For the reasons I give in relation to frame_list_primitive.cpp, I do not accept that it has been shown that the parts of the missing Hytera source code are objectively similar to this file. (b) Materiality 1883 A header file with a similar name is mentioned at MES-1 at §80 but the source file is not mentioned in the evidence (apart from in SBW-63). For the reasons given in relation to default_frame_list.cpp I am unable to reach a view on materiality so that Motorola fails. (c) Conclusions on frame_primitive.cpp 1884 Motorola's infringement claim in relation to this file fails. F. framer.cpp (a) Objective Similarity 1885 Professor Wicker's analysis of the file and function name matches is at SBW-63 at pp 89-94. The matching of function and file names is very extensive. For the reasons I have given in relation to l1timer.cpp, it cannot be concluded that the missing Hytera source code is objectively similar to framer.cpp. (b) Materiality 1886 For the reasons given in relation to default_frame_list.cpp it is not shown that this file is material. (c) Conclusions on framer.cpp 1887 Motorola's infringement claim in relation to this file fails. G. run_dvi.cpp (a) Objective Similarity 1888 Professor Wicker's analysis of function and file name matches is at SBW-63 at pp 118-119. This is relatively short. For the reasons I have given above in relation to default_frame_list.cpp I conclude that it is not shown that the missing source is objectively similar to run_dvi.cpp. (b) Materiality 1889 This file is not mentioned in the evidence or Motorola's submissions. I do not know what it does. I am unable to infer anything about the functionality of this file. Consequently, I am unable to form a view on whether it is material. (c) Conclusions on run_dvi.cpp 1890 Motorola's infringement claim in relation to this file fails. 4. CONCLUSIONS ON FRAMER 1891 Motorola's claim in relation to Framer fails. FramerLib Library 1892 Motorola submitted in MCS(C) Mod II(E) at [124] that the code for the L1 Timer subsystem was contained within framerLib Library. This raises two questions: what is the L1 Timer subsystem and what is the framerLib Library? The answer to both of these questions is provided by the evidence of Mr Simms in MES-1 (some of which I have already discussed in relation to the L1 Timer above). At the time of the initial release of the Motorola source code (the relevant release for these proceedings), the L1 Timer subsystem consisted of L1 Timer, Framer and the QSPI. It will be recalled that Framer [Redacted], L1 Timer [Redacted]. These components, apart from the HAL, were compiled into a library file. The library file had a directory which contained the source files for Framer (framer\:), a directory for the source files for the L1 Timer (l1timer\:), a directory for the source files for the QSPI (qspi\:), and a directory containing the compiled object code for all three (framer\release\:): MES-1 at §§58-59. 1893 Mr Simms also gives some evidence about the directory structure on the standalone laptop. Without setting out the detail of this evidence, its bottom line is that the framerLib Library is defined in such a way that it picks up the source code for each of the L1 Timer, Framer and the QSPI, as well as the compiled object code in the framer\release:\ directory. It is thus an amalgam of source and object code. 1894 Motorola's submissions did not develop any submissions based on the fact that the framerLib Library contains object code and I did not apprehend such a case to be advanced. Instead, as I understood it, Motorola's case was that the framerLib Library was a literary work consisting of source code for three different components: the L1 Timer, Framer and QSPI. 1895 Motorola's submissions do not discuss the files which are said to make up the framerLib Library or where they or the evidence about them might be found. However, Mr Brown has identified them from Motorola's otherwise inaccessible particulars in CMB-25 at pp 25-26. From this, it is apparent that there are no files within the framerLib Library upon which Motorola relies apart from the three files I have considered in Motorola's case on the L1 Timer and the seven files I have considered in its case on Framer. 1896 If Motorola had something else in mind, I have not been able to discern it from its submissions. Since Motorola's case has failed in relation to the L1 Timer and Framer, it therefore fails in relation to the framerLib Library. The HAL Serial Buffer 1. THE NATURE OF THE HAL SERIAL BUFFER 1897 The HAL Serial Buffer is part of the hardware abstraction layer or 'HAL'. In order to understand the role of the HAL Serial Buffer, one must therefore first grasp the role of the HAL. Motorola explained that the purpose of the HAL was to provide a layer which enabled the software components to send instructions to the hardware without needing to know the particulars of the hardware: MCS(C) Mod II(B) at [16]. The five core components of the Darwin Ergonomics Platform are good examples of components of this kind. To give an example not rooted in the facts but nevertheless useful from an explanatory perspective, a higher level software component might contain an instruction to increase the volume. Just what is involved in increasing the actual volume on particular devices may differ between devices. The HAL is able to receive the instruction 'increase the volume' and turn it into an actual instruction which the particular device can obey. By doing this, the software engineers were able to ensure that the core software did not need to be varied for each device. The variations which were necessary could be confined to the HAL. 1898 Turning then to the HAL Serial Buffer, it may first be said that this is part of the HAL. Mr Simms explained in MES-1 at §§27-28 that the HAL transmits data to the hardware using [Redacted]. 1899 The distinction between these is not material to the present discussion. What is important is that the drivers' role in the device is to move data from the HAL to the relevant hardware component. For the driver to move the data, it must be provided with the data. One way of doing this might be to allocate a particular region of the device's memory to each driver. The role of the driver would be to transmit whatever was found in that area to its destination. One might regard such a zone as being like a bus station within the HAL. Other elements within the HAL would know that if data was to be transmitted to a particular hardware element, it was to be left at the bus station. 1900 This, however, is not how the HAL Serial Buffer operates. Rather, it is more like a pick-up service. Instead of other elements depositing the data at the bus station, elements within the HAL which wish to send data to particular hardware elements put in the HAL Serial Buffer a pointer to where the data is located together with information about how the long the data is. The HAL Serial Buffer then arranges for the relevant driver to transmit the data identified by that information. 1901 Mr Simms explained that the advantage of this arrangement is that it provides for more efficient memory storage and transfer of data. Presumably, these efficiencies relate to not having to move the data twice within the HAL. 2. IDENTIFYING MOTOROLA'S CASE ABOUT THE HAL SERIAL BUFFER 1902 The files in question are not identified in Motorola's submissions. However, from CMB-25 at p 26, it is clear that the Buffer consists in its entirety of only two files: SerialHalBuffer.h and SerialHalBuffer.cpp. Motorola alleges that these files have been copied in their entirety into two Hytera files: HalSerialBuffer.h and HalSerialBuffer.cpp. 1903 In CMB-25 at p 26, Mr Brown identifies that the header file is dealt with in Professor Wicker's evidence in SBW-35 (and hence SBW-38). As such it is apparent that the Hytera header file was discovered as source code in the First Tranche of discovery. 1904 At the same place, Mr Brown identifies that the Hytera source file is discussed by Professor Wicker in SBW-57 (which identifies lines of code) and hence SBW-56 where Professor Wicker discusses the source files discovered in the Second Tranche of discovery. The relevant part of SBW-56 is at p 17. Mr Brown also indicates that the header file was also discovered a second time in the Second Tranche. Mr Brown provides a side by side comparison of the Second Tranche source files at CMB-13 at pp 232-235. 3. THE FILES A. SerialHalBuffer.cpp (a) Objective Similarity 1905 Motorola alleges that the whole of this file has been copied by Hytera into HalSerialBuffer.cpp. There are in fact two Motorola files. One is part of the portable and mobile (or host) firmware, whilst the other is part of the DSP Firmware. This is clear from Professor Wicker's analysis at SBW-56 at §58 (and also SBW-57): This Hytera file contains code that is practically identical to that in the Motorola files, down to and including the SetRegister function (line 186 of the Motorola file in the 'hal_dsp' directory and line 177 of the Motorola file in the 'hal_host' directory), except that it does not contain the comments that are present in the Motorola file. The SetRegister function differs slightly between the two Motorola files; the SetRegister function in the Hytera file is essentially identical to the Motorola file in the 'hal_dsp' directory. 1906 It is clear from Motorola's submissions that its case about the HAL Serial Buffer is that it is part of the DSP Firmware: MCS(C) Mod II(B) at [16]. Although Motorola's evidence shows that there are files which were present in both the host and DSP Firmware, that is not how Motorola put its case and I am not going to consider it. Consequently, the version in the host firmware is therefore irrelevant. It is the version in the DSP Firmware that is in contest. 1907 Professor Wicker did not provide a side by side comparison between the Hytera file and either the Motorola host firmware or DSP Firmware versions. Mr Brown's side by side comparison is at CMB-13 at pp 233-235 however the Motorola file he considered was the host firmware version, not the DSP Firmware version. On the face of it, therefore, I do not appear to have access to a side by side analysis of the codes in question. The only evidence about the DSP Firmware version is therefore Professor Wicker's statement that the Hytera file contains lines of code which are 'practically identical' to lines 1-186 of the Motorola DSP Firmware file. Without a side by side analysis, it is difficult to evaluate this evidence. 1908 Mr Brown's comments at p 235 say that the only function in the Hytera code which was different was the function HalSerialBuffer::SetRegister. However, this evidence is about the version of the file in the host firmware, not the DSP Firmware version. 1909 If it is open to reason that it is likely that the host firmware and DSP Firmware versions of the Motorola file are largely identical then I would accept Motorola's case on this file. At that point, I would be able to apply Professor Wicker's evidence about lines 1-186 of the DSP Firmware version to the side by side comparison with the host firmware version proffered by Mr Brown. I would also be to apply Mr Brown's evidence that the host firmware version differed only by the function HalSerialBuffer::SetRegister. 1910 The question then is whether it open to reason in that fashion. In favour of concluding that it is open are these matters: (a) the operation of the HAL Serial Buffer in both the host and DSP Firmware may be similar in that they both provide a particular kind of buffer (described above); and (b) as such, it seems plausible that the host and DSP Firmware versions are likely to be quite similar since they do the same thing. Against reasoning in this fashion are these matters: (a) Motorola did not suggest such a path of reasoning; and (b) it may be unsound to assume that two sets of code achieving the same functionality but appearing in different parts of the software would necessarily be the same. One would need to know more about the context to address that question. 1911 Some additional light in this dim place might also have been thrown if it were possible to access the Motorola source code for both the host and DSP Firmware versions of the file (and not just the host firmware version disclosed by Mr Brown in CMB-13 at pp 233-235). This may have been futile, but there is some chance it may have indicated that the two Motorola files were very similar. 1912 I was not directed to the location in the evidence of the host or DSP Firmware versions of the Motorola file and have located the host firmware version only through the evidence of Mr Brown. Motorola's submissions do not contain a ready reckoner of file locations (indeed, the submissions do not mention most of the files which form the subject matter of its case) and whilst Hytera's do, the DSP Firmware version is not in that ready reckoner (making comparison impossible). 1913 Consequently, that additional light is not available. Returning to the matters weighing in each direction referred to three paragraphs ago, I conclude that I should not reason that I can use evidence given about the host firmware version to reach conclusions about the DSP Firmware version. To do so would be to guess. 1914 The evidence about the DSP Firmware version therefore consists only of Professor Wicker's evidence that the Hytera file contains lines which are practically identical to lines 1-186 of Motorola's DSP Firmware file. I am not prepared to act on that evidence without being shown a side by side comparison of the source codes to which it relates. I therefore do not conclude that Motorola has established objective similarity. (b) Materiality and Originality 1915 Mr Simms gave evidence about the DSP Firmware version of this file in MES-14 at §9: In the same directory there is also a SerialHalBuffer.cpp file. This file also comprises part of the HAL Serial Buffer component, and contains the functions used to implement the HAL Serial Buffer. Its revision history is the same as that for the SerialHalBuffer.h file I discussed in my first affidavit at paragraphs 91-92. 1916 From this I infer that this source file contains the functions used to implement the HAL Serial Buffer whose functioning I have explained above. As such I accept that the Motorola file is material to the operation of the HAL Serial Buffer. Had I concluded that the Hytera file was objectively similar to the Motorola file, then subject to the question of originality, I would have concluded that the Motorola file was a substantial part of the HAL Serial Buffer. 1917 In relation to the originality of this file, Hytera submitted that the Court should conclude either that the Motorola code had itself been copied from an open source data base known as 'MySQL' or was so obvious a solution to a common problem as to be implemented independently and yet be significantly similar: HCS(C) Mod II at [311]. There are two points involved in this contention. Copying from MySQL 1918 Motorola pursued two procedural objections to the Court entertaining this argument. First, it objected to Hytera making this submission when it had not put to Mr Simms that he had copied the code from MySQL and where he had given evidence that he and his colleagues had written the HAL Serial Buffer. Mr Brown's evidence on this topic was delivered in CMB-3 as an exhibit to his affidavit of 6 December 2019. Mr Simms' evidence in chief on this topic was exhibit MES-14 to his affidavit of 27 June 2019. Therefore at the time that Mr Simms prepared his evidence, he was not on notice of what Mr Brown was going to say about MySQL. On the other hand, Mr Simms gave further evidence in reply in the form of Exhibit MES-15 to his affidavit of 12 March 2020 at which time Motorola was on notice of what Mr Brown was saying about MySQL. It was open to elicit evidence about this from Mr Simms in MES-15 but Motorola did not do so. I do not think therefore that it was necessary to put to Mr Simms what Mr Brown had said as a matter of procedural fairness. That opportunity was afforded to Motorola when it prepared MES-15. 1919 In any event, Mr Simms' evidence in MES-14 does not assist Motorola and its submission overstates the effect of his evidence at MES-14 at §10. What he says there is that revision histories for the file show that it was created by a Mr Carter in May 2003 and in the same month 'updated' by Mr Simms. Mr Simms' evidence is not inconsistent with Mr Carter having copied the file. Indeed, Mr Simms would not have been able admissibly to say whether Mr Carter copied the file or not and I do not think that Hytera was bound to put to Mr Simms a question he could not admissibly answer. Motorola knew when MES-15 was being prepared that Mr Brown was saying that the file had copied from MySQL. It had the opportunity to call Mr Carter and it had the opportunity to include what Mr Simms wanted to say about the matter in MES-15. It did neither. In that circumstance, there is no unfairness in permitting Hytera to advance this argument. 1920 Motorola's second procedural objection was that Hytera had not pleaded this matter its defence. I do not find this persuasive. It is clear that 'substantial part' has been put in issue across the whole broad sweep of the case. 1921 Turning then to the evidence supporting Hytera's submission, Mr Brown put forward the publicly available file NdbApiSignal.hpp which is available from the public resource MySQL: CMB-3 at §§133-134. He set the code for that program out in CMB-8 next to lines of code from SerialHalBuffer.cpp. Mr Brown expressed the view based on that side by side comparison that the two systems performed similar tasks, that both provided identical interfaces with only the names of the parameters changed along with the case of the function names. He thought that the fundamental structure of the code and its functionality was 'close to identical': CMB-3 at §134. 1922 Professor Wicker did not agree with Mr Brown's view that the codes were 'close to identical' but he was prepared to accept that they were 'certainly similar': T768.34. He agreed that the fundamental structure of the codes was close to identical 'in the sense that they are both creating buffers with pointers that can be manipulated': T768.40-41. 1923 Motorola submitted that Mr Brown had not annexed the whole of the MySQL file 'instead annexing a reconstruction of parts of it': MCS(C) Mod II(E) at [133]. This contention was not supported by any evidentiary references so I will ignore it. It also submitted that Professor Wicker had said that 'there is no identity of comments or actual code'. I accept this. It was said in Professor Wicker's comments in the JEWC-2 in response to Q4(c). 1924 Having examined them, they are certainly not identical but they bear striking structural similarities. It is likely that Mr Carter used the MySQL file in the process of creating SerialHalBuffer.cpp. But I would not say that it has been copied. The adaptations are non-trivial. It seems to me that Mr Carter (and after him, Mr Simms) did more than just copy this code. Consequently, I do not accept Hytera's submission that these lines of code are not original in the requisite sense. 1925 Consequently I find that lines 1-186 of the Motorola file are material to the HAL Serial Buffer and original in the requisite sense. (c) Conclusions on SerialHalBuffer.cpp 1926 Motorola's case about this file fails since it has not proven objective similarity. B. SerialHalBuffer.h (a) Objective Similarity 1927 In SBW-38 at pp 283-284, Professor Wicker said that lines 1-82 of the Hytera file HalSerialBuffer.h had been copied from lines 1-90 of a Motorola file named SerialHalBuffer.h. He included a side by side comparison of the codes. Another version of the Hytera file appears to have been discovered in the Second Tranche of discovery. In SBW-57 at p 56, Professor Wicker identified two versions of the file, one in the DSP Firmware and one in the host firmware. As I have said, Motorola does not advance a case that the HAL Serial Buffer was part of the host firmware. The table in SBW-57 shows that the version in DSP Firmware involved lines 1-90 (as the whole file) whereas the version in the host firmware involved lines 1-83. Professor Wicker's analysis in SBW-38 at p 283 involved lines 1-90 from which I deduce that the version discussed in SBW-38 was the DSP Firmware version whereas the version discovered in the Second Tranche is not part of Motorola's case. 1928 Mr Brown conducted a side by side analysis of the host firmware version in CMB-13 at pp 232-233. However, this is not the correct version. Professor Wicker's comments in SBW-38 at p 283 were that the difference between the Motorola and Hytera lines was that the Hytera file used 'HalSerialBuffer' whereas the Motorola file used 'SerialHalBuffer'. However, at lines 19, 20 and 70, the Hytera file still used the Motorola nomenclature. 1929 Having examined the code, I am satisfied that lines 1-82 of the Hytera file are objectively similar to lines 1-90 of the Motorola file and, consequently, that the former has been copied from the Motorola file. (b) Materiality and Originality 1930 Mr Simms gave evidence about this file at MES-1 at §§ 90-93. He said that it provided the main definitions for the 'SerialHalBuffer' class. Although Motorola did not explain what this meant, I take it to mean that the header file contains the declarations necessary for the source file. Motorola made no submissions about this file beyond referring me to Mr Simms' evidence (above) that he had written most of the header file himself. Professor Wicker said in SBW-38 that the lines provided the main definitions for the 'SerialHalBuffer' class and referred me to Mr Simms' evidence at MES-1 at §90. I am unable to do any more with Professor Wicker's evidence than I can do with Mr Simms'. 1931 In this case, however, it is clear that the header file travels with the source file and that the source file is material to the HAL Serial Buffer. The declarations could have been included in the source file in which case they could have formed part of that material code. Putting the declarations in the header file is, in this case, a machinery matter. As such, since I know the source file is material to the operation of the HAL Serial Buffer, I am satisfied that the header file is too. 1932 Turning then to originality, closely read, Hytera's submissions did not contend that the header file had been copied from the MySQL resource. In light of Mr Simms' evidence that he wrote the file, I accept that these lines are original. (c) Conclusions on SerialHalBuffer.h 1933 Motorola's claim in relation to this file succeeds. 4. CONCLUSIONS ON THE HAL SERIAL BUFFER 1934 Motorola's infringement claim in relation to this work succeeds. Hytera infringed Motorola's copyright by copying Motorola's header file into its own header file and thereafter compiling this into object code installed on devices imported into Australia. DSP Firmware 1. MOTOROLA'S CASE ABOUT THE DSP FIRMWARE 1935 There are two elements to this case: (a) a case based on the L1 Timer, Framer, framerLib Library and the HAL Serial Buffer; that is to say, it is to be inferred that since these were copied, a substantial part of the DSP Firmware of which they formed part was also copied; and (b) a case based on additional files within the DSP Firmware which are not part of the L1 Timer, Framer, framerLib Library or the HAL Serial Buffer. 2. THE CASE BASED ON THE L1 TIMER, FRAMER, FRAMERLIB LIBRARY AND THE HAL SERIAL BUFFER 1936 I accept this case. Although Motorola has failed in relation to the L1 Timer, Framer and the framerLib Library, it has succeeded in relation to the HAL Serial Buffer. I am satisfied that the header file there involved was not only material to the HAL Serial Buffer but also to the DSP Firmware. Consequently, Motorola succeeds in its infringement case in relation to the DSP Firmware in this aspect. 3. THE CASE BASED ON ADDITIONAL FILES 1937 Motorola's submissions on this aspect of its case are so minimal that I do not accept that Motorola has in fact advanced such a case. 1938 Accordingly, I reject it. To avoid the spectacle of a re-trial, I will endeavour to identify Motorola's case and the evidence on which, had it been advanced, it would have rested. As a matter of nomenclature, where Motorola has made a submission which touches on this case, however tangentially, I note it. Where no such note appears, it reflects the fact that no submission was made. 4. WHAT IS MOTOROLA'S CASE? 1939 Motorola's particulars provide a list of files it relies on in relation to the DSP Firmware. However, these are not grouped by reference to whether the files are in the L1 Timer, Framer, framerLib Library, the HAL Serial Buffer or whether instead they lie outside these works. Having determined what the files in the constituent elements are, one could deduce by striking out all files otherwise accounted for, that the residue must be Motorola's case on the non-component elements of the DSP Firmware. An alternate approach is to resort to Mr Brown's CMB-25 where he has done Motorola's work for it. 1940 Mr Brown identifies at pp 27-30 that there are 84 files in question. They can be grouped into six tranches: (a) the six header and source files for ListenerBase, EventBase and NotifierBase; (b) eight header files with names of the form HalTimer_dsp_gptimer_x.h where x is a number between 1 and 8 inclusive; (c) three header files with names of the form HalTimer_dsp_timer_x.h where x is a number between 0 and 2 inclusive; (d) the file [Redacted]; (e) 64 remaining files consisting of files with file designations .cpp or .asm; and (f) two files [Redacted] and [Redacted]. Category (a) 1941 This category is made up of the six header and source files for ListenerBase, EventBase and NotifierBase. These files also formed part of Motorola's unclearly expressed case on the Portable and Mobile Firmware. There I concluded that Motorola was entitled to succeed on the header files but not the source files. I have explained that I accept that these files were material to the Portable and Mobile Firmware. For the same reasons, I accept that they are material to the DSP Firmware. Had Motorola advanced a case about the non-component elements of the DSP Firmware, I would have concluded that it was entitled to succeed in relation to the three header files. Category (b) 1942 This category is made up of the eight header files with names in the form of HalTimer_dsp_gptimer_x.h where x is a number between 1 and 8 inclusive. Although Professor Wicker was provided with the source code for all eight files, he only gives evidence about one of them in SBW-56. This is HalTimer_dsp_gptimer_1.h. The other seven files appear in Motorola's particulars but since Professor Wicker does not give evidence about any of them they are unsupported by any evidence. I therefore reject the claim in relation to all of these files except HalTimer_dsp_gptimer_1.h. The file is mentioned in Motorola's submissions in reply in fn 17. The main text to which fn 17 is attached says: 'Other code referred to … is present in as many as 8 locations'. The footnote then says: 'See eg HalTimer_dsp_gptimer_1.h to HalTimer_dsp_gptimer_8.h'. From this one could infer that perhaps Motorola was saying that these eight header files were in fact all the same file or, at least, contained some of the same code. However, there is no evidence to that effect and, indeed, apart from this stray reference, Motorola's submissions were silent on this topic. Professor Wicker only gives evidence about one of them. The others are either redundant or there is no evidence for them. In either case, no more time need be wasted upon them. (a) Objective Similarity 1943 Professor Wicker identifies the Hytera files and lines of code involved in SBW-57 at pp 57-58. He does not provide a side by side analysis. Mr Brown provides a side by side analysis at CMB-13 at p 240. 1944 SBW-57 at p 57 suggests that the Motorola file HalTimer_dsp_gptimer_1.h was copied into three different Hytera files: RFHalTimer.h, hal_omap_rftimer.h and HalC55RFTimer.h. Mr Brown's side by side analysis only deals with RFHalTimer.h. Since I do not have access to a side by side analysis for the other two files, I am unable to assess them and I disregard Motorola's case about them. 1945 Insofar as RFHalTimer.h is concerned, Professor Wickers identifies the following lines in the Motorola and Hytera files: HalTimer_dsp_gptimer_1.h RFHalTimer.h 1 70-75 52-57 2 84-91 59-65 3 102-103, 109-113 72-79 Lines 70-75 1946 Professor Wicker says in SBW-56 at §61 that these lines are 'mostly identical'. He describes [Redacted] but says these are 'minor changes'. Mr Brown disagrees. He says that [Redacted] to the Hytera code and '=0' is a non-trivial change. I accept that the Hytera code has those alterations in it. Mr Brown says that effect of the changes is that whilst the Motorola code [Redacted], the [Redacted] in the Hytera code indicates that [Redacted]. Mr Brown's discussion is in section 5.20 of CMB-13. Professor Wicker responds to section 5.20 in SBW-61 at §45(c) but does not add to his earlier observations about the impact of [Redacted] and [Redacted]. I accept Mr Brown's evidence and therefore conclude that these lines are not objectively similar. Lines 84-91 1947 The same issue arises. I conclude that these are not objectively similar. Lines 102-103 and 109-113 1948 I have examined these lines. I do not accept that these are objectively similar. (b) Materiality 1949 I do not know what the functional code to which these relate is. As such I am unable to assess their materiality. On the face of it, I do not accept that a few declarations considered only in a vacuum are shown to be material to the DSP Firmware. (c) Conclusions on Category (b) Files 1950 Motorola's claim, had it been advanced, would have failed. Category (c) 1951 This category is made up of the three header files with names in the form of HalTimer_dsp_timer_x.h where x is a number between 0 and 2 inclusive. In SBW-56, Professor Wicker gives evidence about one of these files, HalTimer_dsp_timer_0.h, but not the other two. The case in relation to the other two fails for want of evidence. In relation to HalTimer_dsp_timer_0.h: (a) Objective Similarity 1952 Professor Wicker identifies the files and lines of code in SBW-57 at pp 58-59. He says that lines from the Motorola code have been copied into three Hytera files, RFHalTimer.h, hal_omap_rftimer.h and HalC55RFTimer.h. He does not provide these codes. However, in CMB-13 at p 240, Mr Brown proceeds on the basis that the Motorola files HalTimer_dsp_timer_0.h and HalTimer_dsp_gptimer_1.h contain the same code and Professor Wicker appears to do so as well. Consequently, the reasoning on HalTimer_dsp_gptimer_1.h applies. I conclude that Hytera lines of code are not objectively similar to the Motorola lines. (b) Materiality 1953 For the reasons given in relation to HalTimer_dsp_gptimer_1.h, I conclude that materiality is not demonstrated. (c) Conclusions on Category (c) Files 1954 Motorola's claim, had it been advanced, would have failed. Category (d) 1955 This category is made up of the file [Redacted]. Professor Wicker gives evidence about this file at SBW-56 at §62. He identifies the relevant lines as files in SBW-57 at p 59. He says that lines of the Motorola file have been copied into two Hytera files Dsphal_RfFrame.cpp and RF_Frame.cpp. Professor Wicker does not provide a side by side analysis. Mr Brown provides one in CMB-13 at p 241 but only in relation to RF_Frame.cpp. I will therefore limit my attention to that file. The lines identified by Professor Wicker in SBW-57 at p 59 are as follows: [Redacted] RF_Frame.cpp 1 40-75 42-60 (a) Objective Similarity 1956 In SBW-56 at §62, Professor Wicker thought that there were comments in the Motorola file that were not in the Hytera file but that the code which was present in the Hytera file was 'very similar' to the Motorola file. He noted that the same grammatical error appeared in both files (at line 54 of the Motorola file). Some of the values assigned to some of the variables had been changed but the variables and logic appeared to him to be the same in both. One of the variables defined the number of [Redacted] and [Redacted]. Mr Brown in CMB-13 at p 241 agreed that codes were similar and that 'in essence there is a high level of similarity'. I conclude that the Hytera lines are objectively similar to the Motorola lines. (b) Materiality 1957 Professor Wicker did not explain what [Redacted] does although in SBW-61 in section 10, he expressed the view that Motorola's code, generally, was significant to the DSP Firmware and the Portable and Mobile Firmware. This evidence did not descend into any particularity. I have not found it to be of assistance. 1958 At MCS(C) Mod II(E) at [128], Motorola referred to [Redacted] as a [Redacted]. This too is not helpful. 1959 However, this file is discussed by Mr Simms. In MES-1 at §§21-23, Mr Simms describes the operation of Framer (which I have discussed above as in the discussions of L1 Timer and Framer) which dealt with [Redacted]. In MES-14 at §13, Mr Simms explains that [Redacted]. 1960 In light of this evidence, I accept that [Redacted] is material to the operation of the DSP Firmware. (c) Conclusions on the Category (d) File 1961 Had this case been advanced, it would have succeeded. Category (e) 1962 This category is made up of the 64 remaining files consisting of files with file designations .cpp or .asm. According to Mr Brown at CMB-25 at pp 27-30, these files are discussed by Professor Wicker in SBW-60. Professor Wicker explains what SBW-60 is in SBW-56 at §91. I have previously discussed Professor Wicker's endeavours to match file and function names from the disassembled object code in the raf_arm9.lib and rfhal_c55.lib library files. SBW-60 concerns the same process applied to a different library file, DmrDspLib.lib. In SBW-60 at pp 77-129, Professor Wicker sets out the file and function name matches he identifies for these 64 files. 1963 Motorola referred to SBW-60 in MCS(C) Mod II(E) at fns 49 and 52 but not in a way which engaged with any of the files. At §148 it referred to a particular file, CarrierDetectorBase.cpp, and made a submission about it. At §149 it made a submission about the particular file, ModLimiterBase.cpp. It also referred to this file in §169 where it submitted that Motorola's files had also been copied into the DmrDspLib library, 'such as ModLimiterBase.cpp'. I have not found these submissions useful. 1964 At §147, Motorola cryptically submits that the 'DSP framework and lineup entities which were copied into Hytera's DmrDspLib library comprise the fundamental algorithms that are used in, and form part of, Motorola's digital radio protocol stack'. The only other place these framework and lineup entities are mentioned is at §146: As in the Mobile and Portable Firmware, the code copied from the DSP Firmware includes code beyond the Motorola Works pleaded within it (in this case the framerLib library and its components and the HAL Serial Buffer). In particular, that copying included the EventBase, ListenerBase and NotifierBase files referred to in 139 above, as well as the DSP framework and lineup entities. 1965 Consequently, the submissions do not throw any light on what the DSP framework or lineup entities might be although it does indicate that they are discussed in JFC-1 by Mr Corretjer. Mr Corretjer does explain what these entities are but he does not identify any particular files. He does however identify a series of directories on the standalone computer where the framework and lineup entities were kept. Comparison with those directories and the Motorola directories identified by Professor Wicker in SBW-60 reveals them to be the same. 1966 I therefore conclude that the 64 files presently under discussion are the files constituting the framework and lineup entities discussed by Mr Corretjer. (a) Objective Similarity 1967 Here the analysis is the same as I have applied to the other disassembled library files, raf_arm9.lib and rfhal_c55.lib. There is a slight difference in that some of the files in this library are not source code at all but files in assembly language. It is necessary to treat them separately. Source Code Files 1968 For the reasons I have given in relation to raf_arm9.lib and rfhal_c55.lib I do not accept that the matching of the file and function names outlined by Professor Wicker in SBW-60 allows me to conclude on the balance of probabilities, taking into account the circumstantial matters I have detailed in the EMT section, that a missing Hytera source code file is objectively similar to the corresponding Motorola file. Assembly Language Files 1969 From Mr Corretjer's evidence in JFC-1 at §17, it is apparent that the files in the DSP framework and lineup entities which end in '.asm' were composed directly in assembly language, i.e. not in a high level language like C or C++. Mr Corretjer explained at §13 that this was done where particular functions had been identified as bottlenecks. Where a bottleneck was identified, code for that function was developed in assembly language to improve its efficiency. 1970 My initial impression was that Professor Wicker's analysis of these assembly files in SBW-60 made no sense. To take the first entry for the Hytera file correlator40circular.obj: 1971 This implies that the Motorola file defines a function. If the file was in assembly language how could it define a function? However, on balance I have concluded that it is likely that the manner in which the .asm files were stored in the assembly directories reflected that each file was for a function (as indicated by Mr Corretjer) which it has been necessary to rewrite in assembly language. As such, I accept that the Motorola file may well refer to its function name even though it is in assembly language. 1972 However, this does not alter the analysis set out above. Motorola's claim in relation to these files fails too. Conclusion 1973 Motorola has not established that any of the files are objectively similar to the Motorola files. (b) Materiality 1974 Mr Corretjer was the chief architect of the DSP framework leading a team of about 25 engineers. He explained that the framework and lineup entities were processing blocks that carry out specific functions or algorithms used for the processing of digital signals. The framework entities are multi-purpose signal processing blocks used for a variety of functions. The lineup entities are specifically designed to [Redacted]. He gave examples of the framework entities including the [Redacted]. The lineup entities included [Redacted]. 1975 Mr Corretjer then explained the rather elaborate architecture for how the software for these entities was structured in directories. I do not need to dwell on this. It satisfied me that each of the files within the directories is material to the DSP Firmware. (c) Conclusion on Category (e) Files 1976 Motorola's claim in relation to these files, had it been put, would have failed. Category (f) 1977 This category is made up of the [Redacted] and [Redacted] files. Professor Wicker refers to these files in SBW-63 at pp 96 and 119. These pages form part of Professor Wicker's analysis of matching file and function names retrieved from the disassembled rfhal_c55.lib library file. I have discussed this above in relation to the framework and lineup entities. [Redacted] (a) Objective Similarity 1978 For the reasons I have given above in relation to the framework and lineup entities, I do not accept that objective similarity is established. (b) Materiality 1979 In MES-14 at §11, Mr Simms explained that this file handles the process of providing appropriate [Redacted]. As such, I accept it is material to the operation of the DSP Firmware. (c) Conclusions on [Redacted] 1980 Had this part of Motorola's case been advanced, it would have failed. [Redacted] 1981 Professor Wicker refers to this file in SBW-63 at p 119. As with the previous file, the evidence here is concerned with the matching of function and file names retrieved from the disassembled object code for the rfhal_c55.lib library file. (a) Objective Similarity 1982 For the reasons given in relation to the framework and lineup entities, objective similarity is not established. (b) Materiality 1983 I have not been able to locate any evidence about this file. I am unable to reach a conclusion on materiality. (c) Conclusions on [Redacted] 1984 Had this part of Motorola's case been advanced, it would have failed. 5. CONCLUSION ON THE DSP FIRMWARE 1985 Motorola's case on the DSP Firmware insofar as it is based on one header file in the HAL Serial Buffer succeeds. It did not advance a case fit for consumption by a court in relation to files outside the component works but nevertheless within the DSP Firmware. On the evidence, had such a case been advanced, I would have rejected most of it but upheld two elements. XII LIABILITY OF HYTERA FOR IMPORTATION INTRODUCTION 1986 Motorola has succeeded on demonstrating that a substantial part of each of: HAL Serial Buffer; DSP Firmware; Xlate; Darwin Ergonomics Platform; Portable Firmware; and Mobile Firmware was copied by Hytera into its source code. It has also proved that Hytera's source code was compiled and that the compiled code was then installed on Hytera devices made in China. On the other hand, Motorola has failed to prove that substantial parts of the EMT, UIT, L1 Timer, Framer and the framerLib Library were copied by Hytera into its source code. 1987 As I have previously noted, those actions did not infringe Motorola's Australian copyright. Any infringement arises only because those devices were imported into Australia. For Hytera to be liable, it is necessary for Motorola to prove that Hytera knew, or ought reasonably to have known, that if the devices had been made in Australia, this would have constituted an infringement of copyright: s 37(1). 1988 Although the statute is not explicit, Motorola submits, and I accept, that the time at which this hypothetical question should be asked is at the time of importation: MCS(C) Mod II(E) at [203]. The devices began to be imported in September 2013. If the requisite hypothetical knowledge is established at that date, it will follow that it is also established at all later dates. 1989 In order to address Hytera's state of mind as at September 2013, is it necessary to recall some findings of fact which have already been made and to make some new ones. RELEVANT FACTS 1990 In Chapter IX I have found that: (a) Mr GS Kok was in charge of the DMR team and had been given authority by Mr Chen to organise the structure of the DMR team, to manage that team and also to hire new personnel; (b) it has not been established that Mr Chen told Mr GS Kok that he expected him to adhere to his obligations to Motorola; (c) by 2009, the team of people for whom Mr GS Kok was responsible numbered at least 60 people; (d) the ex-Motorolans did not conceal from the DMR team that parts of Motorola's source code were being used to create Hytera's source code; (e) it is more likely than not that the entire DMR team was aware that Motorola's source code was being used to create Hytera's source code; (f) the motivation of the ex-Motorolans in using some of Motorola's source code was to get the Hytera devices to market as quickly as possible at the lowest cost and with the best battery life; and (g) the Hytera devices were brought to market in early March 2010. 1991 In Chapter VIII I have found that: (h) had Hytera continued on its original development arc, it is likely that it would have brought its devices to market no earlier than the middle of 2011; but (i) the devices would not have been competitive with Motorola's devices. 1992 From (h) and (i) a further inference may be drawn: (j) Hytera benefitted from the actions of the ex-Motorolans in at least two ways: (i) it got to market with devices which were commercially competitive with Motorola's products where otherwise it would not have done so; and (ii) it got to market by no less than 15 months earlier than it otherwise would. 1993 It is likely that Hytera obtained a third benefit from the actions of the ex-Motorolans inasmuch as it acquired knowledge of how to put together well designed radio communications software. However, this was not the subject of an allegation by Motorola and it would not be appropriate to take it into account. 1994 There are some additional matters which are also relevant: (k) by September 2013, Mr GS Kok had been promoted to the position of Senior Vice President in the Office of the President Department: Chu Jing Su-2 at §10(b); (l) the position of Senior Vice President was a senior management position. There were four Senior Vice Presidents and they ranked next after the Chief Executive Officer, Mr Chen: Xu Shan at §§22 and 24; (m) although it is implicit in Chapter IX that Mr GS Kok was aware of the fact that some of Motorola's code was being used to create some of Hytera's code, I am explicitly of the view that Mr GS Kok was the directing mind behind this activity and responsible for it; (n) Mr Chia and Mr YT Kok assisted Mr GS Kok by giving effect to his instructions; and (o) Mr Chia and Mr YT Kok occupied senior positions within the DMR team. Mr YT Kok was the head of the Shenzhen Research and Development Center Department and Mr Chia was the head of the group of engineers developing software for DMR products at Hytera: MCS(C) Mod III at [27]. 1995 At the time, therefore, that Hytera's devices were imported into Australia in September 2013, facts were known at the very highest levels of Hytera (by Mr GS Kok) that would have indicated to a reasonable person that if the devices had been made in Australia, Motorola's copyright would have been infringed. If, on the other hand, the relevant time is the time at which the copying of Motorola's code took place, then I would reach the conclusion that the persons in charge of the entire DMR project knew facts of that kind at that time. SHOULD MR GS KOK'S KNOWLEDGE AT SEPTEMBER 2013 BE ATTRIBUTED TO HYTERA? 1996 Two issues arise here. The first is whether, on ordinary principles, Mr GS Kok's knowledge as at September 2013 should be attributed to Hytera. The second is whether there is an exception to that principle where the employee in question has acted in breach of fiduciary duty where the conduct in question is reprehensible. 1997 As to the first question, in a statement approved by the High Court in Krakowski v Eurolynx Properties Ltd (1995) 183 CLR 563 at 582-583, Bright J in Brambles Holdings Ltd v Carey (1976) 15 SASR 270 at 279 said: Always, when beliefs or opinions or states of mind are attributed to a company it is necessary to specify some person or persons so closely and relevantly connected with the company that the state of mind of that person or those persons can be treated as being identified with the company so that their state of mind can be treated as being the state of mind of the company. This process is often necessary in cases in which companies are charged with offences such as conspiracy to defraud. 1998 In my opinion, Mr GS Kok was, as at September 2013, sufficiently closely and relevantly connected to Hytera that the state of his mind should be attributed to it. If the correct time is 2009 when the copying took place (rather than the time of importation) I would likewise conclude that Mr GS Kok, Mr YT Kok and Mr Chia were sufficiently closely and relevantly connected to Hytera such that their state of mind should be attributed to it also. 1999 As to the second question, Hytera submitted that the knowledge of an employee was not to be attributed to their employer where the employee had acted in breach of fiduciary duty and where the employee's conduct was reprehensible. Leaving aside legitimate quibbles as to whether this principle applies to employees or agents simpliciter and assuming, for the sake of argument, that Mr GS Kok was a fiduciary in the requisite sense, I do not accept that this principle applies in this case. 2000 Whilst there is a fraud exception to the imputation of knowledge, it does not apply where the fiduciary's activities are not totally in fraud of the principal: Grimaldi v Chameleon Mining NL (No 2) [2012] FCAFC 6; 200 FCR 296 at [284] ('Grimaldi'). In this case, the conduct by which Mr GS Kok acquired his knowledge of the facts was not totally in fraud of Hytera. Quite to the contrary, his actions resulted in Hytera having a commercially viable product (when it otherwise would not have) and having it faster than its original development arc would have entailed. Mr GS Kok intended to benefit Hytera by his actions and he was successful in this endeavour. If it be relevant, the same may be said of Mr Chia and Mr YT Kok. 2001 Although Hytera also referred me to the Full Court's decision in Oliver Hume South East Queensland Pty Ltd v Investa Residential Group Pty Ltd [2017] FCAFC 141; 259 FCR 43, it did not take me to any particular part of that judgment. However, I do not read it as being in any way contrary to Grimaldi. CONCLUSION ON LIABILITY OF HYTERA FOR IMPORTATION 2002 In that circumstance, I conclude that Mr GS Kok's knowledge as at September 2013 was Hytera's knowledge. Consequently, Hytera is liable for infringement of Motorola's copyright in the six works set out above. If the relevant time for the inquiry is 2009 when the copying of the code was taking place, I would also conclude that his knowledge should be attributed to Hytera. XIII LIABILITY OF HYTERA FOR COPYING AND COMMUNICATING 2003 Motorola made a single paragraph submission that Hytera was liable for making copies of its firmware in Australia and communicating that firmware to the public in Australia: MCS(C) Mod II(E) at [209]. It submitted that Hytera was also liable for authorising dealers to make copies of the firmware and to communicate the firmware to members of the public. COPYING AND COMMUNICATING THE FIRMWARE 2004 Motorola did not take me to any evidence to make good these allegations or any admissions made by Hytera about these matters. 2005 In §31L of its Seventh Further Amended Defence, Hytera admits that on 'certain dates' it made the firmware available for download by dealers and distributors permitted to access its dealer and distributor website. I take the reference to 'certain dates' to be a reference to the dates on which the relevant firmware version was uploaded to the website. Hytera also admits that this state of affairs continued until 6 March 2020. 2006 There does not appear to be an admission that Hytera itself made copies of the firmware in Australia although there is an allegation (dealt with next) that it authorised others to make copies of the firmware. Not having been taken any evidence, I do not find that Hytera made copies of the firmware in Australia. 2007 For reasons already given, the firmware is an adaptation of a substantial part of each of Xlate, the Darwin Ergonomics Platform, the Portable and Mobile Firmware, the HAL Serial Buffer and the DSP Firmware. As such, Hytera's firmware is an adaptation of the whole of each of those works: Copyright Act s 14. Motorola's copyright in the works included the right to communicate to the public an adaptation of each work: s 31(1)(a)(iv) read with subs-s (1)(a)(vii). 2008 Consequently, I conclude that Hytera is liable for communicating an adaptation of the works to the public by making its firmware available for download from its website by its dealers and distributors. 2009 For completeness, Hytera did not submit that there could be no act of communication because its website was located outside of Australia. It also did not submit that its dealers and distributors were not the 'public' for the purposes of the definition of 'communicate' in s 10. In saying this, I do not mean to suggest that such a submission could or should have been made. AUTHORISATION 2010 Motorola did not take me to the evidence or the pleadings. At §31M of its Seventh Further Amended Defence, Hytera admits that on the dates it made the firmware available for download by dealers and distributors, it authorised them to access and download the firmware for the purpose of installing copies of the firmware on devices when performing firmware upgrades. It says that this conduct ended on 6 March 2020. 2011 Section 36(1) makes it an infringement of a copyright to authorise the doing of an act comprised in the copyright. In this case, the relevant events are the downloading of the firmware and the installation of copies of the firmware on users' devices. There are three acts involved. The first is the act of the dealer or distributor in receiving the communication of the firmware from Hytera's website. The second is the reproduction of that communication into a new copy of the firmware. The third is the installation on users' devices of the firmware which involves making another copy of the firmware on that device. The first of these acts does not involve an infringement of Motorola's copyright for the mere receipt of a communication is not comprised in the rights in s 31(1). The second and third acts involve an infringement of Motorola's copyright. The relevant right was the right to make a copy of an adaptation of Motorola's source code: s 31(1)(a)(i) read with subs-s (1)(a)(vii). 2012 In light of Hytera's admission, I conclude that Motorola's authorisation case is made good. XIV LIABILITY OF HYTERA AUSTRALIA FOR COPYING AND COMMUNICATING 2013 In relation to Hytera Australia's liability, Hytera's Seventh Further Amended Defence includes this admission at §31N: In answer to paragraph 31N of the statement of claim, the respondents: (a) admit that the second respondent has performed the firmware upgrades that are described in: (i) paragraphs 75 and 76 of the first affidavit of Xiao (Sean) Li affirmed on 13 December 2019; (ii) paragraphs 18 to 20 of the first affidavit of Jiehao Liu affirmed on 23 May 2019; (ii) paragraph 7 of the second affidavit of Jiehao Liu affirmed on 24 July 2019; (b) admit that the second respondent has, on some occasions, performed firmware upgrades on end user devices that are delivered to the second respondent for warranty and/or repairs; (c) admit that, in the course of making the firmware upgrades admitted in subparagraph (a) above, and in the course of making some (but not all) of the firmware upgrades admitted in sub-paragraph (b) above, the second respondent reproduced one or more of the Accused Firmware Versions; (d) deny that the second respondent has since 6 March 2020 made, or will in the future make, any reproductions or copies of any of the Accused Firmware Versions; and (e) otherwise deny paragraph 31N of the statement of claim. 2014 From this I conclude that Hytera Australia has itself made copies of the firmware in Australia. For reasons already given this was an infringement of the copyright in each of Xlate, the Darwin Ergonomics Platform, the Portable and Mobile Firmware, the HAL Serial Buffer and the DSP Firmware. The relevant right was the right to reproduce the works read with the adaptation right: ss 31(1)(a)(i) and (vii). XV INJUNCTIVE RELIEF FOR COPYRIGHT INFRINGEMENT INTRODUCTION 2015 At one time it appeared that Hytera wished to contend that injunctive relief should be refused on the basis of Motorola's delay in bringing forward its allegations. However, in its closing written submissions it relied on only two matters to resist the grant of an injunction: HCS(C) Mod III at [194]. These were that: (a) Hytera had given undertakings which made the grant of relief unnecessary; and (b) an injunction in general form was not, in any event, appropriate. INJUNCTIONS AGAINST PARTICULAR CONDUCT 2016 Motorola sought particular injunctions to restrain Hytera from committing the particular infringements of copyright it alleged. The infringements I have found are: (a) the importation by Hytera of devices containing Hytera's firmware into Australia; (b) the communication by Hytera of that firmware to its dealers and distributors; (c) the authorisation by Hytera of dealers and distributors to download and copy the firmware; and (d) the copying by Hytera Australia of the firmware following download from Hytera's website and again by installation of that firmware into users' devices. 2017 For each work, the underlying conduct which gives rise to infringement is Hytera's making of an adaptation of Motorola's source code by: (a) copying a substantial part of the work into Hytera's source code; and then (b) compiling that source code into object code as firmware. The relevant works are Xlate, the Darwin Ergonomics Platform, the Portable and Mobile Firmware, the HAL Serial Buffer and the DSP Firmware. 2018 Hytera submitted that it has given undertakings not to engage in this conduct. There are two undertakings in evidence. I did not apprehend Motorola to submit that the undertakings did not have the effect of preventing Hytera from engaging in (a)-(d). Consequently, I accept Hytera's submission that an injunction in relation to the particular conduct is not necessary. GENERAL INJUNCTION AGAINST INFRINGEMENT OF COPYRIGHT 2019 Motorola also sought a more general injunction restraining Hytera and Hytera Australia from infringing its copyright in the 11 works. It is not appropriate to grant injunctive relief in relation to the EMT, UIT, L1 Timer, Framer or the framerLib Library since infringement in relation to those works has not been established. 2020 Hytera did not submit that the general injunction should be refused because there was no risk of further infringement and the debate between the parties appeared to take that as a given. I will do so as well. 2021 Motorola submitted that a general injunction should be granted citing Calidad Pty Ltd v Seiko Epson Corporation (No 2) [2019] FCAFC 168; 147 IPR 386 ('Calidad'). Hytera submitted that a general injunction was not appropriate in every case, also citing Calidad, and that it was not appropriate where certain of the works had been found not to have been infringed. 2022 This is a case where infringement of the copyright in five of the works has not been demonstrated. I would not say that the Court has found that these works were not infringed. I think it is likely that they were infringed in some way but it is just that Motorola has failed to prove objective similarity. This failure is a result of two matters: (a) in part because the ex-Motorolans disposed of much of the evidence; and (b) in part because Motorola's submissions largely failed to engage with the expert evidence including its own or to deal with what this part of the case is only about viz, lines of computer code. 2023 Calidad was a patent case but I apprehend from the fact that both parties rely on it that both accept that the principles stated in it apply to copyright litigation. I take from Calidad the following propositions: (a) the usual or conventional form of injunction granted in patent and trade mark cases is the injunction in general form (at [26], [44]); (b) this will be appropriate where the scope of the rights holder's rights are made clear by the injunction itself (at [46]); (c) this approach applies to other forms of intellectual property rights (at [44]-[45]); (d) one of those rights is copyright (at [38]-[41], [46]); (e) a general injunction may still be refused (at [47]-[48]); and (f) general principles about the grant of injunctive relief, such as proportionality, still apply (at [47]). 2024 Also relevant is what the Full Court said at [49]. In rejecting the proposition that ordinarily a general injunction ought not to be granted, the Full Court said: This approach effectively, but in our respectful view unjustifiably, elevates the position of the infringer over that of the holder of the rights in question. Where the infringer has already been found to have engaged in wrongful conduct, and is undoubtedly cognisant of the intellectual property rights in question, it is not unjust to expect that the infringer be the party at risk in respect of that person's future conduct and acts, not the party whose known rights have already been infringed and vindicated by the court's judgment. Thus, the imposition of an injunction in general form is not, in and of itself, an undue burden on the infringer. By the same token, the person whose intellectual property rights have been infringed should not be exposed to the risk of having to engage in continuing legal proceedings in order to vindicate, again, that person's established rights against an established infringer. It is not, with respect, a sufficient answer to say that the rights holder might have a claim for additional damages if further infringement be found. Further, if the established infringer is in any doubt about whether that person's future acts might infringe the intellectual property rights that have been established, or is concerned that those acts will be a matter of contention so far as the rights holder is concerned, then it is within the power of that person to seek appropriate declaratory relief. Relevant to the present case, for example, is s 125 of the Patents Act 1990 (Cth) which specifically provides for the granting of non-infringement declarations. In other cases, recourse can be had to the Court's general power to grant declaratory relief under s 21 of the Federal Court Act 1976 (Cth). 2025 The only matter put forward by Hytera was that certain of the works had been found not to have been infringed. No further elaboration was provided. I will consider the position in relation to the Darwin Ergonomics Platform (which was found to have been infringed) and one of its component programs, the EMT (which was not found to have been infringed). 2026 Addressing myself to (b) above, if an injunction in general form is granted restraining Hytera from infringing the copyright in the Darwin Ergonomics Platform, does this make clear the scope of Motorola's rights? The only way it would not make that clear is if it was thought that the effect of Motorola's failure to establish that the copyright in the EMT component had been infringed connoted that Hytera was at liberty to copy the EMT component. 2027 If I had concluded that Motorola's infringement suit in relation to the EMT component had failed because I was not satisfied that it was an original work, then there might be some force in this. However, all that I concluded was that the particular lines of Hytera source code put forward by Motorola were not objectively similar to the nominated lines of the Motorola source code. That conclusion does not give Hytera a licence to copy the EMT component. 2028 Consequently, I am satisfied that an injunction in general form does make clear the scope of Motorola's rights. Since no other reason was advanced why an injunction in general form should not be granted, and since no other occurs to me, I conclude that an injunction in general form is appropriate for both Hytera and Hytera Australia. XVI DAMAGES AND ACCOUNT OF PROFITS 2029 In light of the conclusions I have reached on infringement, Motorola is entitled to damages or, at its election, an account of profits. The issue of quantum was not ventilated during the present hearing. Hytera reserved the right to argue at the quantum hearing that Motorola's delay in notifying Hytera of its claims has caused it loss. In this context there is therefore no need to assess the delay allegations. The next step will be to determine whether Motorola wishes to pursue damages or an account of profits. XVII ADDITIONAL DAMAGES FOR COPYRIGHT INFRINGEMENT INTRODUCTION 2030 Section 115(4) of the Copyright Act provides: 115 Actions for infringement … (4) Where, in an action under this section: (a) an infringement of copyright is established; and (b) the court is satisfied that it is proper to do so, having regard to: (i) the flagrancy of the infringement; and (ia) the need to deter similar infringements of copyright; and (ib) the conduct of the defendant after the act constituting the infringement or, if relevant, after the defendant was informed that the defendant had allegedly infringed the plaintiff's copyright; and (ii) whether the infringement involved the conversion of a work or other subject‑matter from hardcopy or analog form into a digital or other electronic machine‑readable form; and (iii) any benefit shown to have accrued to the defendant by reason of the infringement; and (iv) all other relevant matters; the court may, in assessing damages for the infringement, award such additional damages as it considers appropriate in the circumstances. 2031 The infringements found fall into four categories. They are infringements where: (a) Hytera imported devices with its firmware installed on them into Australia; (b) Hytera made its firmware available for download by its dealers and distributors in Australia; (c) Hytera authorised its dealers and distributors to download and install the firmware on customers' devices; and (d) Hytera Australia copied the firmware and installed it on customers' devices. 2032 I did not apprehend from Motorola's submissions that it pursued a case on additional damages against Hytera Australia. Turning then to each of the subsections of s 115(4): FLAGRANCY: SECTION 115(4)(B)(I) 2033 As I have previously explained, there is no doubt that the ex-Motorolans set out to copy parts of Motorola's source code to assist in the production of a commercially competitive product and to expedite the development process. The conduct was deliberate and was orchestrated from the top of the DMR development team by Mr GS Kok. It was not a secret project to which only the ex-Motorolans were admitted but rather was a significant undertaking of which, if not most and probably all of the DMR team were aware. That access to the actual source codes was heavily restricted does not signify, as Hytera submitted, that the ex-Motorolans were seeking to deceive either the DMR team or Hytera. Rather, they were seeking to thwart any suit brought by Motorola against Hytera for copyright infringement. 2034 The conduct of the ex-Motorolans was, as Hytera correctly submitted, morally reprehensible. If it be material, I am satisfied that the knowledge of Mr GS Kok, Mr Chia and Mr YT Kok is to be attributed to Hytera during the period when Hytera was developing its DMR devices. Mr GS Kok had been given the task of developing the DMR devices and it was in pursuit of that task that the copying of Motorola's source code took place. Mr Chen did not give evidence that he had told Mr GS Kok that he should abide by his responsibilities to Motorola when he retained him for Hytera. 2035 Mr Chia and Mr YT Kok were responsible at a more granular level and were more aware than Mr GS Kok of the particulars of the plagiarism program. Both were senior members of Hytera's DMR team. Having regard to what their roles were I am satisfied that their knowledge is to be attributed to Motorola. 2036 However, I do not think that the question of flagrancy is to be addressed at the time that the ex-Motorolans copied Motorola's source code. Rather, it is to be addressed at the time of the infringements. In relation to the importation infringements, the relevant time is on and from September 2013 when the importation began. At that time, Mr GS Kok was one of the four officials who ranked second highest in Hytera after Mr Chen. Mr GS Kok's knowledge of how the firmware had been made was Hytera's knowledge at September 2013. 2037 There is no evidence to which I was taken about who made the decision to export the Hytera devices to Australia. I will proceed on the assumption that the Hytera personnel who made the decision to export the devices to Australia were themselves unaware of the facts known to Mr GS Kok. As I have already explained, Mr GS Kok's knowledge is to be attributed to Hytera for the purposes of s 37. Hytera knew that if the devices had been made in Australia then this would have constituted an infringement of copyright. The reason it knew that was because it knew that its DMR team had copied parts of Motorola's source code to create its firmware. The reason it knew this was because Mr GS Kok knew it. He knew it because he had organised it and because he was, by the time of the importation of the devices into Australia, the equal second highest ranking officer in Hytera. 2038 The question now is whether Mr GS Kok's knowledge is to be attributed to Hytera for the purposes of s 115(4). I do not see any principled basis on which I could conclude that Mr GS Kok's knowledge was to be attributed to Hytera for one purpose (importation (s 37)) but not for another (flagrancy (s 115(4))). Consequently, I conclude that Hytera's importation of the devices into Australia was a flagrant infringement of Motorola's copyright. In relation to all of Hytera's other infringements which relate, in substance, to the updating of the devices' firmware, I infer that these all happened after the devices entered the Australian market i.e. after September 2013. For the same reason, I therefore infer that each infringement was flagrant. 2039 There is an additional reason for reaching this conclusion from 23 May 2017. Motorola notified Hytera of its patent infringement allegations in March 2017: HCS(C) Mod III(Supp) at [43]. After the receipt of those allegations, Hytera conducted an internal investigation into the matters raised by Motorola: MCS(C) Mod III at [31]. As part of that investigation, each of Mr GS Kok, Mr YT Kok and Mr Chia were interviewed. On 23 May 2017, Mr Chia sent the Hytera chief executive officer, Mr Chen, an email. Part of the email dealt with Mr Chia's interview. The relevant portion was as follows: Fourth major item is the company lawsuite that started in Apr2017. As I am a key witness, I am feeling a lot of pressure doing and saying the right thing. I am trying to do this without any guidance provided from the company or lawyer. Before meeting the external lawyers, I was told to tell the truth of all the events that happened. However after this has happened, I was told that I should to have said too much. This is also no alignment done between all the 3 of us although I had approached GS 3 times requesting to align our stories. Bottom line, is that if there is no alignment and guidance, it is surely bound to be screwed up. Being the key witness and bearing this risk is just too high for a person that is doing this for the first time. Its is like asking a 5 year old kid to jump into water and swim without giving any guidance. He will likely die. This lawsuite is giving me the most pressure and I am lost as to what to do. As of now, there has not been a session providing me the necessary guidance. I fear that I can be personally implicated once the trial starts. In addition, due to this lawsuite, I can no longer be the face of this team as well as a public face for the G2.0 product. Also, due to this lawsuite, it is unlikely for me to get a different job to escape from this Hytera's lawsuite. I have also lost my image with my family members in Malaysia and it is likely I will not meet them next year, I currently feel that the risk to reward when deciding to join this company was not properly balance and it is now impacting many aspects of my life… Key items that are troubling me: … 4) Stress going through the lawsuite process. I do not feel protected at all. Knowing that there is a risk in going to jail and destroying my life while the company only risk loosing money is worrying me…. … I have to face all these issues every day of my work for some time to come. Among the 3 of us (GS, Sam, YT), I am the only one who is facing tremendous pressure as I have to be in the corporate office facing these disappointments everyday. The other two persons (GS and YT) is spending most of their time at home and does not need to face this uncomfortable situation everyday. The have the privilege to hide from whatever issues they face in the company.. 2040 From this email and the facts already found, four matters are open to be inferred. First, Mr Chia's interview was conducted by external lawyers. Secondly, Mr Chia told the truth to the external lawyers. Thirdly, by reason of my earlier findings, the truth included the proposition that the ex-Motorolans had copied Motorola's source code in the process of developing Hytera's firmware and had taken active steps to disguise this fact. Fourthly, the external lawyers knew that Motorola's source code had been copied. 2041 On the other hand, there is evidence which tends in the opposite direction. The employment of Mr YT Kok and Mr Chia was said to have been terminated on 23 October 2018. Mr GS Kok's employment was terminated on 9 November 2018. In each case there was an agreement regulating their termination and in each case the agreement recited that the reason for the termination was gross misconduct against Hytera by reason of a failure to co-operate with requests for information. If these clauses accurately reflect the reality of what occurred then necessarily Mr Chia's email to Mr Chen saying that he had told the external the lawyers the truth must be a deliberate untruth. 2042 The agreements and Mr Chia's email are therefore inconsistent. Hytera drew my attention to the evidence of Mr Luo in his fifth affidavit at §19. Mr Luo is the person at Hytera responsible for co-ordinating Hytera's response to Motorola's allegations: Luo-5 at §4. At §19 of his affidavit as it was sworn he had said that Mr Chia, Mr YT Kok and Mr GS Kok's employment had been terminated for failure to cooperate with Hytera's investigation. However, this part of §19 was not received into evidence. 2043 The evidentiary picture therefore consists only of the email and the termination agreements. Mr Luo was not the person responsible for terminating the employment of the ex-Motorolans. Hytera led no evidence from the person or persons who decided to terminate the employment of the ex-Motorolans. 2044 Which should be preferred, Mr Chia's email or the provision of his termination agreements? The competing hypotheses are: (1) Mr Chia did not co-operate with the investigation. Having not co-operated with the investigation he then sent an email to the chief executive officer in which he dishonestly stated that he had co-operated by telling the truth; and (2) Mr Chia did co-operate with the investigation and told the external lawyers precisely what had happened. He was then wrongly terminated for failing to co-operate with the investigation but nevertheless agreed to a clause saying that he had failed to comply with requests for information. 2045 Under the first hypothesis, there is a question in my mind as to what Mr Chia's motives were in taking this course. Under this hypothesis he had not co-operated with the investigation. This was a fact that was necessarily known to Hytera. The point of the email cannot therefore have been to persuade Mr Chen that he had co-operated as this was a venture doomed to fail. The only other explanation for Mr Chia's behaviour would appear to be that he knew he was going to be terminated for failing to co-operate and had decided to give Hytera a bloody nose by sending an email in which he said he had told the truth. Whilst this is possible, there are some problems with it. If Mr Chia had been motivated by malice then he could have said much more in his email than he did. For example, he could have given Mr Chen chapter and verse on what the ex-Motorolans had done. Under this hypothesis, there was no downside for him in doing so since he was going to be terminated for non-cooperation anyway. Another problem with this hypothesis is that the balance of Mr Chia's email seems to assume that he is going to remain at Hytera. As events transpired, he did remain at Hytera for a further 19 months, not being terminated until 23 October 2018. 2046 Under the second hypothesis, it is necessary to conclude that Hytera knew that the recited reason for Mr Chia's dismissal was false and also that Mr Chia agreed to it. Under the termination agreement, Mr Chia received a payment of 525,924 RMB which is substantial sum of money: C14.524. That payment is capable of providing the explanation for Mr Chia's motivations in agreeing to a clause which was false. I am satisfied that Mr Chia is capable of engaging in dishonest conduct from his activities in copying Motorola's source code and seeking to hide that fact. It is possible therefore that he would be willing to lie in the agreement particularly in return for a payment of 525,924 RMB. On the other hand, it is also necessary to conclude that whoever was responsible for Mr Chia's termination was also willing to lie in the same way and knowingly to cause the creation of a false document being the termination agreement. The identity of that person or persons and their motivations is not known. 2047 Under either hypothesis, Mr Chia has lied either in the email or in the agreement. Hytera has lied only under the second hypothesis. On balance I prefer the second hypothesis for three reasons. First, if the email is a deliberate attack on Hytera, it is much more muted than it could have been. Secondly, if it is an attack on Hytera then the balance of the email is a skilled artifice designed to make it look like it is not an attack (for example, by implying that he will not be able to leave Hytera). Having read Mr Chia's written work I am impressed by his skills as an engineer. However, I am not impressed by his acumen in the art of creating false document trails at which he appears to have been a rank amateur. If he was skilful in that department he would not have created documents in which he expressly referred to the reuse of Motorola's source code or the risk of being sued by Motorola. Indeed, perhaps surprisingly as an electronics engineer, his conduct seems to reveal an unawareness that electronic documents often are forever. Thirdly, if Mr Chia had failed to co-operate with the investigation prior to his email of 23 May 2017 it is strange that Hytera did not get around to terminating him until 23 October 2018, 19 months later. This inclines to me the view that this was not the reason he was terminated and therefore that the clause in his termination agreement records a falsehood from both Mr Chia's and Hytera's perspectives. 2048 I therefore conclude that Mr Chia's email is true. It follows that Mr Chia told the external lawyers how Hytera's firmware had been developed prior to 23 May 2017. This explanation would have included the fact that they had used some of Motorola's source code as the basis for parts of Hytera's firmware. 2049 I therefore infer that from some date prior to the date of Mr Chia's email, 23 May 2017, Hytera was aware that Motorola's source code had been used in the development of Hytera's firmware. Whilst it is conceivable that some kind of cordon sanitaire was in place to prevent knowledge of this kind mischievously leaching its way through to Hytera's management, there was no evidence that such a barrier was in place. In any event, the results of Hytera's internal investigation had revealed to it by June 2018 that Motorola's code had been used as Mr Luo agreed under cross-examination: T790.8-41. How Hytera was able to work this out if the ex-Motorolans were not co-operating is unclear to me. It did not have Motorola's code against which it could compare its own code and, according to it, the employees involved were refusing to speak to it. 2050 From the date of Mr Chia's interview, which was somewhere between March 2017 and 23 May 2017, and after the results of its internal investigation in June 2018, the situation on the flagrancy is therefore more serious. From that time, Hytera knew in every sense that its firmware had been developed using Motorola's source code. It is therefore not to the point that the employment of the ex-Motorolans ceased on 23 October 2018 and 9 November 2018: HCS(C) Mod III(Supp) at [45]. By then, so far as Hytera was concerned the cat was out of the bag and, indeed, over the fence. 2051 It knew what had happened. I therefore conclude that whilst it continued to import devices into Australia during this period (and to update firmware) it was engaging in a flagrant infringement of copyright quite apart from the knowledge of Mr GS Kok. However, this conclusion is surplusage. The knowledge of Mr GS Kok is sufficient for present purposes. THE NEED TO DETER SIMILAR INFRINGEMENTS OF COPYRIGHT: SECTION 115(4)(B)(IA) 2052 The infringements here are importation infringements and associated infringements arising from the supply of updated firmware. What is to be deterred here is not directly the industrial theft giving rise to the infringements but the infringements themselves. THE CONDUCT OF THE DEFENDANT AFTER THE ACT CONSTITUTING THE INFRINGEMENT: SECTION 115(4)(B)(IB) 2053 As I have already noted, Hytera continued to import the devices into Australia and to update infringing firmware even after it was aware from around 23 May 2017 that its firmware had been developed using some of Motorola's source code. It did not undertake to stop doing that until nearly two years later on 17 May 2019 when it proffered formal undertakings. 2054 Motorola submitted that Hytera did not begin to rewrite its firmware until June 2019. This was the evidence of Mr Luo at T792.34-35. On the face of it this looks unsatisfactory. Hytera's own investigation had revealed as early as June 2018 that a portion of Motorola's source code had been used in Hytera's devices: T790.8-46. And, as I have explained, it knew this even earlier after it interviewed Mr Chia. In August 2018, Motorola had been granted leave by the United States District Court of the Northern District of Illinois to add copyright infringement allegations to its suit: MCS(C) Mod III at [67(e)]. In December 2018, Motorola had identified 161 Hytera source code files which it said had been copied and in the same month copyright allegations were added to this proceeding: MCS(C) Mod III at [67(f)]. Substantially complete particulars of Motorola's claim were provided in June 2019 which was when the rewrite commenced. 2055 I was initially impressed by Motorola's submission. However, the evidence of Mr Luo persuades me that I should not be. That evidence establishes that that these proceedings have, from the outset, been burdened by heavy confidentiality obligations in relation to both Hytera's code and Motorola's code. In the lead up to the trial I was distinctly aware, as the docket judge, of the administrative complexity these confidentiality regimes imposed. 2056 The effect of these regimes has been that whilst attorneys and experts were able to inspect the codes, other personnel from Motorola and Hytera were not. This represented a significant obstacle to Hytera's efforts to rewrite its code so that it did not infringe Motorola's code. Since it could not examine Motorola's code, it could not see what it was about the lines of its code which were impugned that meant that they infringed Motorola's copyright. It was only after Hytera's experts were able to examine the codes that the rewrite could commence. I do not therefore see Hytera's rewriting of its firmware as being tardy. 2057 Neither party contended for the proposition that Hytera had begun to rewrite its code before June 2019 and to find that it did so would involve rejecting Mr Luo's evidence and Motorola's submission based on that evidence in circumstances where Hytera did not advance such a contention. There may be tactical reasons which explain the postures of the parties. It is not to Motorola's advantage to demonstrate that the rewriting commenced earlier than June 2019 since it diminishes its argument that Hytera dallied. On the other hand, it is not in Hytera's interests in resisting the proposition that the ex-Motorolans had initially copied the Motorola code to prove that it had in fact maintained their employment so that they could help it to undo what they had one; put another way, contending that the rewrite had commenced earlier than June 2019 and had involved the ex-Motorolans would have provided ammunition for an argument that the ex-Motorolans had originally copied the Motorola code. Here the thinking would be that the ex-Motorolans could only be useful to Hytera in the rewriting process because they were the ones who knew which parts of Hytera's code had been repurposed from Motorola's and they knew this because they had done it. 2058 Were the matter open for my consideration I think there is some force in the proposition that the ex-Motorolans were kept in employment by Hytera so that they could assist with the rewriting of Hytera's code. A number of matters point in that direction. The professed reason for the dismissal of Mr Chia is false. He was retained for a further 19 months after he was interviewed. There is no explanation from Hytera for why it decided to keep the ex-Motorolans employed for such a long time after their alleged disobedience to the investigation. It is also difficult to see how the investigation could have concluded that Motorola's code had been used when Hytera did not have Motorola's code and, according to it, the ex-Motorolans were not co-operating. Further, the time taken by Hytera to rewrite its firmware was exceptionally fast. On Hytera's timeline, it began rewriting its firmware in June 2019 and completed that task by 22 November 2019 at the latest when it commenced deploying that firmware. This period is under six months. Having regard to what I have seen of how the ex-Motorolans developed the code in the first place, this strikes me as such an astonishingly fast development time as to be implausible. 2059 However, since neither party advanced such a contention, it is inappropriate to make such a finding. I will proceed on the basis that the rewriting commenced in June 2019 and on the basis that Hytera did not seek to use the ex-Motorolans in the process despite my own misgivings. WHETHER THE INFRINGEMENT INVOLVED A CONVERSION FROM HARDCOPY TO DIGITAL: SECTION 115(4)(B)(II) 2060 This is not relevant to the findings of infringement which have been made. ANY BENEFIT SHOWN TO HAVE ACCRUED TO THE DEFENDANT BY REASON OF THE INFRINGEMENT: SECTION 115(4)(B)(III) 2061 As I have explained elsewhere, Hytera obtained two benefits from the actions of the ex-Motorolans: (a) a commercially viable DMR product; and (b) an accelerated date of entry into the market. However, the actions of Hytera's DMR team in creating its firmware off the back of some of Motorola's source code is not one of the infringements which I have found. Rather, the infringements relate to the importation of Hytera's devices into Australia from September 2013 together with acts relating to providing updated firmware after that date until 6 March 2020. 2062 The two benefits I have mentioned did not accrue by reason of the infringements. Indeed, they had already accrued when the products were launched in early March 2010. Put another way, Hytera did not obtain a commercially viable DMR device by importing the same device into Australia. It had already done that. Nor did the importation of the devices into Australia speed up a development process which had already been completed. 2063 On the other hand, it is possible that Hytera did obtain benefits from its entry into the Australian market. These would be market share and profits. However, there is no hard evidence before me about these matters. The best that can be said is that there were sales. From this one may infer only that it obtained some market share. ALL OTHER RELEVANT MATTERS: SECTION 115(4)(B)(IV) 2064 Hytera submitted that a number of other matters needed to be brought to account. (a) Insignificant Infringement of Copyright Established 2065 Hytera submitted that the nature of the infringements was limited and in respect of relatively insignificant parts of the pleaded and particularised works. It was said that the parts allegedly taken related to 'relatively insignificant parts of Motorola's DMR technology': HCS(C) Mod III at [13]. 2066 At the level of actual lines of code, Motorola has succeeded in demonstrating that some lines of code from Xlate and the HAL Serial Buffer were taken and that these were material to each of those programs as well as the larger programs of which they formed part of (i.e. the Darwin Ergonomics Platform, the Portable and Mobile Firmware and the DSP Firmware). 2067 Motorola's DMR technology is very complex technology. I accept that the portions of code copied from Xlate and the HAL Serial Buffer, whilst material, are a relatively small part of Motorola's overall DMR technology. Principally I conclude this because there are so many other parts of the technology. I would prefer not use Hytera's word, 'insignificant'. A better description of the situation would be that the lines copied were small but material parts of Motorola's source code and, if it be relevant, material parts of its DMR technology. (b) Reasonably Arguable Defence 2068 I accept that Hytera was reasonably entitled to put Motorola to proof on objective similarity. I also accept that: (a) its defence that Motorola's source code was not original in the infringement sense because it was derived from earlier iterations was arguable; and (b) that its defence that the knowledge of the ex-Motorolans was not to be attributed to it was reasonable. Consequently, I accept that Hytera had a reasonable defence. (c) The Infringing Conduct Was Not the Conduct of the Ex-Motorolans 2069 Here the point is that the infringing conduct is the importation of the devices into Australia from September 2013 and the provision of updated firmware in Australia. I accept that this importation activity was not the conduct of the ex-Motorolans. It was however the conduct of Hytera. Further it was the conduct of Hytera knowing how the firmware had been developed. From September 2013 to 9 November 2018 Hytera knew, through Mr GS Kok, that the importation of the devices into Australia (or the distribution of updated firmware) was an infringement since the firmware was an adaptation of a substantial part of Xlate, the Darwin Ergonomics Platform, the HAL Serial Buffer and the Portable, Mobile and DSP Firmware. From 23 May 2017 Hytera knew, independently of its knowledge through Mr GS Kok, that its firmware had been developed from Motorola's source code since Mr Chia had by then told Hytera's external lawyers the full truth of what had happened. Nevertheless, Hytera's point remains sound. The importation of the devices and the distribution of updated firmware was not the same conduct that led the creation of the firmware. (d) The Knowledge of the Ex-Motorolans Should Not Be Attributed to Hytera 2070 I have rejected this argument already. Quite apart from the position of Mr GS Kok as the equal second most senior employee of Hytera, I am satisfied that from 23 May 2017, Hytera knew what had happened after it had interviewed Mr Chia and been told the full truth. (e) No Broader Case of Conduct 2071 Here Hytera's point was that the conduct relied upon by Motorola was limited to the ex-Motorolans. I have already rejected this argument. All, or most of, the DMR team were aware that some of Motorola's code was being used to create Hytera's firmware. Further, as I have found, code was distributed to persons who were not ex-Motorolans. On the other hand, Motorola did not allege, and the evidence does not support, a contention that Mr Chen knew what was happening. It also does not support the contention that he did not know what was happening. However, Motorola's burden of proof dictates that it has not been shown that Mr Chen did know. (f) Custodians of Motorola's Source Code 2072 Hytera submitted that no Motorola source code had been found in the custody of any person at Hytera apart from Ms Peiyi Huang. I accept this is so. However, I have explained her role as the gatekeeper to the SVN server. A deliberate decision was made to confine the custody of Motorola's source code with her and tightly regulate who could work on that code and in what circumstances. I have explained the reasons for this previously. Once the full picture is appreciated, it is open to infer, and I do, that Motorola's code was distributed to other persons within the DMR team by Ms Peiyi Huang and, once worked upon, returned to her. The fact that there is very little trace of this in the documents demonstrates not that it did not happen but that the sanitising activities of the ex-Motorolans were largely successful. (g) No One Apart From the Ex-Motorolans Used Motorola Code 2073 It is true that there is no direct evidence that non-ex-Motorolans used Motorola code. However, I have found that Motorola's code was distributed to some non-ex-Motorolans by means of library files. I am unable to conceive of a reason why a non-ex-Motorolan would have been provided with a Motorola file unless it was to use it. I therefore infer that non-ex-Motorolans did use Motorola code and reject this submission. (h) Concealment of Activities by Ex-Motorolans 2074 I have previously rejected this contention. (i) Not Unexpected that the Names of Motorola's DMR Products Might Be Discussed 2075 At a high level of generality, I accept this submission. It is to be expected that one manufacturer of DMRs would discuss internally the products of another such firm. For example, it would be legitimate for Hytera to be discussing the parts count and price of Motorola's DMR products as part of an analysis of the competitiveness of its own DMR products. Professor Sun's analysis of the situation facing Hytera prior to the arrival of the ex-Motorolans falls, I think, comfortably into this category. On the other hand, it is not legitimate to be talking about a competitor's products as part of a consideration of how the intellectual property contained in them might best be purloined. Whilst I accept Hytera's submission that some of the references to Motorola's products do fall into the first category, I do not accept that the evidence permits me to find that every such reference was a legitimate one. So too, whilst it is to be expected that Hytera would inevitably have needed to have considered documents such as the ETSI DMR Standard, I do not accept that this can wash clean what the evidence otherwise clearly shows – calculated theft of someone else's computer code. Consequently, whilst I accept Hytera's submission so far as it goes, the truth is that it does not go very far. (j) Professor Rangan's Evidence in SR-22 2076 Hytera submits that I should treat SR-22 as being in the nature of a submission. Much of SR-22 is to an extent argumentative. Although from time to time I have referred to SR-22, largely for that reason, I have not relied upon it. There are two exceptions to this. First, I have relied upon Professor Rangan's view that the practice of emailing library files amongst engineers is irregular: at [1528]. Secondly, I have relied upon Professor Rangan's evidence that the development time for the Hytera firmware was far more rapid than might usually be expected: at [1572]-[1573]. In both cases, I consider Professor Rangan qualified to express those opinions. More generally, I have found it useful to consider the documents on which SR-22 is based although not Professor Rangan's views about what those documents mean. (k) Other Documents Relied Upon by Motorola 2077 As will be apparent from the infringement section, I agree with Hytera that a distinction must be drawn between distributions of Motorola's confidential information (not being computer code) and the distribution of code itself. As I have previously noted, Motorola tended to elide the distinction in a way which was analytically unhelpful. (l) Hytera's State of Development before 2008 2078 This formed part of Hytera's submission that it did not obtain a benefit from the actions of the ex-Motorolans. I have considered the state of Hytera's development at the end of 2007 in Chapter VIII. Elsewhere I have concluded that Hytera obtained two benefits from the actions of the ex-Motorolans viz a commercially viable DMR product and an earlier entry into the marketplace. (m) Hytera's Conduct after It Was Notified of Motorola's Allegations 2079 Hytera was notified of Motorola's allegations that Hytera had used its confidential information and documents and infringed its patents on 14 March 2017 when Motorola commenced a proceeding in theUS. The steps it says it took were: (i) it notified staff in relation to record preservation, locating and gathering documents and source code, locating physical sources of information and investigating records; (ii) terminated the employment of the ex-Motorolans on 23 October 2018 and 9 November 2018 'after they were unwilling to assist in Hytera's investigations'; (iii) introduced requirements for new employees and background checks to identify and highlight confidentiality and intellectual property obligations to former employers; (iv) introduced training for new recruits which emphasised these matters; (v) sought, on 4 October 2019, the assistance of Mr GS Kok, Mr YT Kok, Mr Chia and Ms Peiyi Huang to answer interrogatories although this was unsuccessful; (vi) in 2018, reprogrammed the devices to remove or disable the functionalities relevant to each patent in suit; (vii) on 17 May 2019, gave undertakings not to exploit devices installed with non-reprogrammed firmware, not to make available the non-programmed firmware and to refrain from reversing the reprogramming unless this Court finds that the non-reprogrammed firmware does not infringe Motorola's patents; (viii) took steps to prevent the risk of reprogrammed devices being used with non-reprogrammed devices; (ix) from 22 November 2019, deployed rewritten firmware after having received Motorola's particulars of copyright infringement on 2 September 2019; (x) on 9 April 2020, gave undertakings not to import or sell in Australia devices with the infringing firmware; and (xi) on 12 June 2020, gave undertakings not to provide the firmware from its portal. 2080 I accept all of these matters except (ii) although some warrant additional brief discussion. 2081 As to (ii), the employment of the ex-Motorolans was terminated on those days. In the case of Mr Chia I do not accept, for reasons I have already given, that he was terminated because he did not co-operate with the investigation. The fact that the clause in Mr Chia's termination agreement falsely records that he was terminated for not providing information persuades me that it would be unsafe to rely on the agreements in the cases of Mr GS Kok and Mr YT Kok. In their cases I make no finding about the reason they were dismissed. In Mr Chia's case, I am unable to say what the actual reason was that he was terminated but I am satisfied that it was not because he had failed to cooperate with the investigation. 2082 As to (viii) and (ix), I have already explained that I do not think that Hytera was tardy in rewriting its firmware once the role of the confidentiality regimes is brought to account. (n) Motorola's Delay 2083 Hytera submitted that Motorola delayed notifying Hytera of its allegations of copyright infringement. The consequence of this was said to be that Hytera was delayed in having the opportunity to rewrite its firmware so that it did not infringe. As a result, Hytera's exposure to monetary relief now extends for a longer period than it otherwise would. 2084 This argument would be at home as a reason for not granting equitable relief. It is also fits comfortably into a contention that Motorola's damages should be reduced to reflect the alleged cost to Hytera of the delay. However, the present argument is that it is relevant to the question of whether additional damages should be awarded having regard to the matters in s 115(4). I do not see how Motorola's conduct is relevant to that question. The question is whether what Hytera has done warrants the imposition of additional damages. Save for one circumstance, I do not see how the conduct of Motorola can be relevant to that inquiry. 2085 The one circumstance would arise if I had concluded that Hytera had delayed in rewriting its firmware. If that were to be held against it under s 115(4), then fairness would require that Hytera be given an opportunity to establish that, in truth, the delay, or part of the delay, had been occasioned by Motorola's own delay. In any event, since I have concluded that Hytera did not delay the rewriting of its firmware I do not accept that Motorola's delay has any relevance to s 115(4). CONCLUSIONS 2086 Section 115(4) requires the Court to decide whether to award additional damages after considering the matters set out in that provision. Having taken into account each of those matters above, I conclude that an award of additional damages is appropriate. Although there are some matters in Hytera's favour they do not dispel the flagrancy of the infringements. XVIII ADDITIONAL DAMAGES FOR PATENT INFRINGEMENT INTRODUCTION 2087 Motorola has succeeded in demonstrating that claims 1-6 and 10 of the 355 Patent have been infringed. It has failed on the 764 and 960 Patents. Motorola seeks additional damages for patent infringement under s 122(1A) of the Patents Act: 122 Relief for infringement of patent … (1A) A court may include an additional amount in an assessment of damages for an infringement of a patent, if the court considers it appropriate to do so having regard to: (a) the flagrancy of the infringement; and (b) the need to deter similar infringements of patents; and (c) the conduct of the party that infringed the patent that occurred: (i) after the act constituting the infringement; or (ii) after that party was informed that it had allegedly infringed the patent; and (d) any benefit shown to have accrued to that party because of the infringement; and (e) all other relevant matters. 2088 It is necessary to consider some facts: HYTERA'S SCAN FUNCTION WAS DEVELOPED USING KNOWLEDGE OF HOW MOTOROLA'S SCAN FUNCTION OPERATED Hytera's Knowledge of How Motorola's Scan Function Operated 2089 There are three matters. First, on 6 March 2009, Ms Peiyi Huang sent an email to various people including Ms Yan Xu. It attached a document which was an initial draft of the timing requirements for the scan function for the Hytera product: C14.006. Under the heading 'Digital Timing' it included this annotation: These data is accordance with Moto DMR scanning timing. It might need to be loosen for our company product as this is a very tight timing match to Moto system. 2090 An inference is open that Motorola's scan function was used by Hytera in the development of its scan function. 2091 Secondly Hytera's 'DMR Software Requirement Specification for the Scan' document (the 'Requirement Document') contains an extensive outline of how Hytera's scan function was created: SR-7 at p 383. At its front pages is a table containing information about who prepared it, who modified and who approved it. Motorola relied on an entry in this table for 9 July 2009 which was as follows: 2092 It did not rely on the entry for 17 July 2009: 2093 This rather suggests that Motorola's source code, through the vector of Ms Peiyi Huang's template (i.e. RAF library file), was used as the raw material from which Hytera's scan function was wrought. However, it also suggests substantive alterations to the code. The changing of the flow chart would have changed (and probably was intended to change) the structure of the code. Further, new parts are added, other parts deleted and some tidying up is engaged in. 2094 Motorola also relied upon a passage in the body of the Requirement Document. This was at p 389. Under the heading '1.5 Reference & Standard' there appeared a list of four documents which were for reference purposes. One was the 'DMR scan function standard document', which I take to be a reference to the 2005 DMR Standard. Another was 'Motorola DMR scan function research document'. The reference was said to be located at: 2095 Two things may be inferred from this. First, Motorola's DMR scan function research document was used as background to Hytera's Requirement Document. Secondly, it will be noted that the document was located on a server beginning with 'SVN'. I have already concluded that Hytera had such a server although it denied it. Motorola did not rely on the sentence appearing under the heading '1.2 Background' at p 389: The document is written based on the studies and analyses of the scanning functions featured by the DMR model of competitors combined with the scanning function requirement of the HYT model. 2096 I disregard this sentence since Hytera has not been heard on it. However, from the matters that Motorola did rely on in this document, it is open to infer that Hytera developed its scan function from Motorola's scan function (and, I would add, the 2005 DMR Standard). 2097 Thirdly, there is the oral evidence of Ms Yan Xu. It will be recalled that Ms Yan Xu was one of the persons working on the protocol stack. During the patent phase of the hearing she gave evidence at T163.21-24 that she was also the person who wrote the source code for Hytera's 'scan short LC feature' (a part of the scan function). At T834.45-835.5 of the copyright phase of the hearing, she agreed that she understood the reference to Motorola's scanning timing in the document referred to in [2089] as being a reference to what Motorola was doing with its devices. This adds little to what the document itself suggests. 2098 It is open to infer from these three matters that Hytera used Motorola's scan function in developing its own scan function. I draw that inference. Hytera Knew that Motorola's Scan Function Used an Activity Indicator Bit and a CACH Message As Part of a Scan Methodology 2099 Before he had finished up at Motorola, Mr Chia downloaded a document entitled 'Matrix Protocol' which, when opened, was a set of PowerPoint slides dated 8 December 2005 entitled 'MATRIX Protocol Overview: Presentation to the Schaumburg Matrix Engineering Team'. It contained a slide which contained a picture of a TDMA frame. The picture depicts a CACH message which includes an activity indicator bit. It is described underneath as 'CACH Signalling (4 CACH) – Used to improve scan times by indicating current call information'. I accept that this is a brief description of the method in claims 1-6 and 10 of the 355 Patent. The slide looks like this: 2100 Once at Hytera, Mr Chia prepared in April 2009 a presentation which contained the following slide: 2101 This too includes an activity indicator bit and a statement that the CACH contains a short LC burst for scan time improvement. It is open to infer that Mr Chia was aware of the idea of using an activity indicator bit (a first information) together with a short LC message (a second information) from Motorola's document for the purpose of improving scan time. 2102 Of course, as I have explained in the section dealing with the 355 Patent, the 2005 DMR Standard provided for an activity indicator bit and the use of CACH message but it did not do so as part of a scanning method. Hytera did not submit, but I would not have accepted even if it had, that Mr Chia's knowledge of a scanning method which used an activity indicator bit and a CACH message came from the 2005 DMR Standard. 2103 Motorola next submitted that Mr Chia had also accessed other documents relating to its scan feature prior to leaving Motorola. This evidence was garnered from Mr Chia's Compass Logs for 13 April 2008. These reveal the downloading of several documents entitled 'Scan Notes', a document entitled 'LTD Scan Summary 05Feb04', a document entitled 'Meeting Notes from Scan Task Group' and a document entitled 'Scan'. Motorola took me to one of these documents, 'Scan Notes – 09Jan04'. I accept that it discusses the CACH message although in the different context of a problem known as 'non-priority voice channel scan'. Having read the document, I doubt that it would have inspired someone to use an activity indicator bit with a CACH message to reduce scan time who was not already intimately familiar with that method. Thus I do not think that this document provides evidence that Mr Chia obtained from it his understanding that an activity indicator bit could be used with a CACH message to reduce scanning time. Not having been taken to the other documents, I draw no conclusions about them. 2104 Motorola invited me to infer that Mr Chia had taken the Motorola presentation dated 8 December 2005 for the purpose of retaining it and using it in his role at Hytera. I do so. I also infer that he did, in fact, use it for the purpose of preparing his own presentation in April 2009. I also infer that that presentation was made to members of the DMR team who were involved in the creation of the Hytera scan function. Hytera's Subscriber Units Used an Activity Indicator Bit and CACH Message to Reduce Scan Time 2105 This is not in dispute. Hytera accepted that if the 355 Patent were construed as Motorola submitted it should be, then its non-reprogrammed subscriber units and non-reprogrammed base stations infringed when used together. Conclusions 2106 Hytera used Motorola's scan function as part of the process of developing its own scan function. Mr Chia knew that Motorola's scan function used an activity indicator bit and a CACH message as part of a scanning method. Hytera's devices operate the same way. From these three matters, I infer that Hytera obtained the idea of using an activity indicator bit and a CACH message to improve scanning time from Motorola. WHETHER HYTERA'S SCAN FUNCTION SOFTWARE WAS COPIED FROM MOTOROLA'S SOURCE CODE 2107 In the patent phase of the hearing, Professor Rangan gave evidence describing the operation of Hytera's source code when a user initiated scanning: SR-4 at §116. [Redacted]. A number of other steps were then taken which do not matter for present purposes. 2108 Professor Rangan said, and I accept, that the data structure APP2PS_ScanInfo is defined in a header file, DPS_InterfaceDefForAPP.h. This header file is available and includes this text 'Copyright ©, 1988-2008, HYT Tech Co., Ltd.'. As I have previously explained, Hytera did not exist in 1988. On this basis, Motorola submitted that I should infer that the header file was likely to have originated from Motorola. Motorola did not suggest, however, that I should examine the corresponding Motorola file against this file. The Hytera file is not one of the files which Motorola claims in its copyright suit has been copied from Motorola source code: Confidential Annexure 2. 2109 All that I can infer from the copyright notice is that it is likely that the Hytera source file was drafted using material which included a Motorola file with a copyright notice in it. For completeness, it should be noted that this was the file on which Ms Yan Xu was cross-examined and in respect of which I have found her evidence to be unsatisfactory. That her evidence about that was unsatisfactory does not permit me to conclude that the file was copied, particularly where this is not alleged. 2110 Professor Rangan's discussion of APP2PS_ScanInfo occurs in a part of his evidence where he is discussing whether Hytera's devices used a pre-programmed scan list. This formed part of his discussion of whether integer 1 of claim 1 of the 355 Patent had been infringed. He was not discussing the transmission of a control message with a first information which informs the subscriber unit of activity present on the channel (integer 2), or discussing whether the first information indicates activity on the channel (integer 4), or whether the activity was of interest to the subscriber unit by comparing it with a second information (integer 5). He does discuss integers 2, 4 and 5 at §§132ff and does so by reference to many Hytera files. Motorola did not submit as part of its claim for additional damages that any of these files had been copied from its source code. 2111 It is apparent from Professor Rangan's evidence that these Hytera files are available (because he examined them) and the Motorola files are available (because a full but inaccessible list of them appears in its particulars of copyright infringement). Conclusions 2112 It is not shown that Hytera's source code for its scan function was copied from Motorola's. Consequently, the flagrancy I have found in relation to some aspects of Motorola's copyright infringement case has nothing to do with its claim for patent infringement. HYTERA'S KNOWLEDGE OF THE 355 PATENT 2113 Motorola submitted that I should infer that Hytera was aware of the 355 Patent (and its US analogue) when it was creating its scan function: MCS(C) Mod III at [100]. However, it did not take me to any evidence to support the drawing of that inference. Hytera led evidence from Mr Luo that he was unaware of the Patents (including, relevantly, the 355 Patent) until 2017. He became aware of the US patents in March 2017 and of the Australian patents in July 2017: T785.3-14. Mr Luo's role in 2008 to March 2017 related to sales and marketing and it is not obvious to me that he would have any reason to be aware of highly technical patents when planning Hytera's marketing and sales. He is presently the person in charge of Hytera's response to Motorola's litigation. I accept therefore Motorola's submission that Mr Luo's ignorance of the 355 Patent does not prove much. On the other hand, that submission does not solve the problem that there is no evidence that anyone else at Hytera knew about the 355 Patent at the time that the scan function was being developed by Hytera. I do accept that Hytera knew about the 355 Patent by July 2017 when it was relied on in this Court in the current proceeding, and that it knew about the US analogue in March 2017 when Motorola sued it on the US patent. However, Hytera then filed defences in both proceedings relating to construction and validity. CONCLUSIONS 2114 Motorola's scan function used an activity indicator bit and CACH message (corresponding with the first and second information referred to in claim 1 of the 355 Patent) to enhance scan time. The DMR team at Hytera was aware that this was how Motorola's scan function worked. Hytera's scan function also used an activity indicator bit and a CACH message to improve scan time and I am satisfied that the DMR team went down this path because this was the solution that Motorola had adopted. 2115 On the other hand, whilst Motorola's legal team had the source code for Hytera's scan function and its own source code, Motorola does not allege in its copyright suit that this part of Hytera's source code was copied from its own source code. Critically, Motorola does not submit that Hytera copied the source code which provides the mechanism by which the activity indicator bit was used with a CACH message to shorten scan time. Motorola submitted that any finding of flagrancy in the copyright allegations could be transferred across to the patent part of the case. I do not agree. The flagrancy under s 115(4) relates to flagrant infringement of copyright by copying (more precisely by importing – but for present purposes that wrinkle may be passed over). Motorola has not alleged that its source code for its scan function, the subject of the 355 Patent, was copied and I have not found that it was. Consequently, there is no finding about flagrancy in relation to this code. 2116 For completeness, as I have previously noted, Motorola did not pursue an action for breach of confidence. Whilst it is tempting to reason that the events disclosed reveal such a breach, as Hytera correctly submitted, no such case has been pursued and Hytera has not been required to meet such a case. To reason that the conduct was flagrant because it involved a breach of confidence would involve a denial of procedural fairness and would be outside the pleaded case. 2117 However, even if it had been appropriate to proceed on the basis that there had been a breach of confidence or that it was otherwise improper for Hytera to have developed its scan function in the way that it did, this would not mean that Hytera had flagrantly infringed the 355 Patent. Flagrantly to infringe the 355 Patent would have required Hytera to have known about the 355 Patent and to have proceeded with its scan function knowing that it was infringing the 355 Patent. I cannot reason that way since there is no evidence that Hytera was aware of the 355 Patent or its US analogue at the time that it developed its scan function. I am unable to conclude therefore that it created its scan function knowing that it was infringing the 355 Patent or its US analogue. 2118 I accept that Hytera did become aware that Motorola was alleging that it had infringed the US analogue of the 355 Patent when the US proceeding was commenced. However, Hytera articulated defences to that allegation and to the same allegation in this proceeding. Relevantly, these included defences that properly construed it had not infringed the 355 Patent because it only applied where the device used the first and second information to make a once and for all decision to stay on the channel. Although I have rejected that argument, I do not think it was an unreasonable defence. Further, Hytera also alleged that the 355 Patent was invalid because it lacked an inventive step. Again, whilst I have rejected that argument it was not unreasonable. As such, Hytera's conduct during this period cannot not be described as flagrant for the purposes of s 122(1A)(a): Oxworks Trading Pty Ltd v Gram Engineering Pty Ltd [2019] FCAFC 240; 154 IPR 215 at [67]-[73]. 2119 Section 122(1A) requires the Court to take into account each of the matters there set out. Given that I have found that the infringements were not flagrant, the need to deter similar infringements in s 122(1A)(b) has little content: 'similar infringements' refers back to the flagrancy of the infringement in s 122(1A)(a). Whilst the imposition of additional damages for a non-flagrant breach might indeed have a deterrent effect on all infringers, including flagrant infringers, I do not apprehend that s 122(1A) is to be approached on the basis that it might be useful to impose additional damages on the non-flagrant infringer pour encourager les autres. 2120 As for ss 122(1A)(c)-(d), these have been sufficiently canvassed elsewhere in these reasons. In relation to s 122(1A)(e) ('all other relevant matters'), Hytera's development of its scan function from Motorola's is such a matter. Even assuming that it is procedurally open to consider a breach of confidence case or otherwise to describe what happened in terms apt to attract moral opprobrium, this does not overcome the problem that Hytera did not know about the 355 Patent. Particularly when considered in light of s 122(1A)(b) ('the need to deter similar infringements of patents'), I do not see what deterrent effect awarding additional damages would have upon the audience to whom such an award would be addressed. That audience consists of persons who are infringing a patent unknowingly. By definition, they will not be deterred. By parity of reason, even if I had accepted that the source code for the scan had been copied from Motorola's code (which I have not), it would be erroneous to conclude that the fact that this might constitute a flagrant infringement of copyright implies that it also involved a flagrant infringement of the 355 Patent. There are different rights involved and Hytera's knowledge of them is not the same. It would have been obvious to Hytera (in this hypothetical scenario) that it was infringing Motorola's copyright but, absent knowledge of the 355 Patent, I cannot see how it could have been obvious to it that it was also infringing the patent. 2121 Taking all of that into account I conclude that additional damages for patent infringement should not be awarded. XIX SUPPRESSION AND NON-PUBLICATION ORDERS INTRODUCTION 2122 The parties seek suppression and non-publication orders over a number of documents produced and accepted into evidence during the proceeding. There are three applications: (1) Motorola seeks orders over a list of documents which it asserts are confidential to it. This application is supported by the affidavit of Ms Gilchrist, Motorola's solicitor, affirmed 22 October 2020 ('Motorola Application'); (2) Hytera seeks orders over a list of documents which it asserts are confidential to it. Hytera's application is supported by the affidavit of its solicitor Mr Vincent, affirmed 30 June 2021 ('Hytera Application'); and (3) Motorola and Hytera jointly seek orders over a list of documents relating to the EP Licence Agreement between them ('Joint Application'). 2123 The confidentiality of these documents has been protected by interim orders made under s 37AI of the Federal Court of Australia Act 1976 (Cth) ('FCA Act'), initially on 22 July 2020 and extended on various occasions, most recently on 25 November 2022. RELEVANT PRINCIPLES 2124 I set out the principles applicable to an application for suppression and non-publication orders at an earlier juncture in the life of this proceeding: Motorola Solutions Inc v Hytera Communications Corporation Ltd (No 2) [2018] FCA 17 ('2018 Suppression Order Reasons') at [6]-[9]. This passage was approved of by the Full Court in Steelforce Trading Pty Ltd v Parliamentary Secretary to the Minister for Industry, Innovation and Science (No 2) [2018] FCAFC 47 at [4]. 2125 At [6] of the 2018 Suppression Order Reasons I summarised the principles as follows: (1) the FCA Act contains Part VAA which relates to suppression and non-publication orders; (2) the power of the Court to make such orders is contained in s 37AF and the grounds for making them are to be found in s 37AG which includes within it that 'the order is necessary to prevent prejudice to the proper administration of justice': FCA Act s 37AG(1)(a); (3) such an order is not lightly to be made. It must be necessary to prevent prejudice to the proper administration of justice and not merely desirable: see Hogan v Australian Crime Commission [2010] HCA 21; 240 CLR 651 at 666 [39]; Australian Competition and Consumer Commission v Valve Corporation (No 5) [2016] FCA 741 at [8] per Edelman J; (4) the Court may make any other order necessary to give effect to the primary order: s 37AF(2) of the FCA Act. (5) the order, once made, must remain in place no longer than is reasonably necessary to achieve its purpose: s 37AJ(2); and (6) the Court must take into account that a primary objective of the administration of justice is to safeguard the public interest in open justice (s 37AE) but no balancing exercise need be carried out between the utility of the order and the interest which open justice assumes under the FCA Act: Australian Competition and Consumer Commission v Air New Zealand Ltd (No 12) [2013] FCA 533 at [21]. 2126 At first blush, it might be thought insufficient for the purposes of s 37AG(1)(a) that the documents in question contain information which is commercial-in-confidence. However, a long line of authority establishes that in fact commercial sensitivity can be an appropriate basis for a suppression or non-publication order: 2018 Suppression Order Reasons at [8]. The primary rationale for this is to help guard against misuse of the Court's process by commercial parties seeking to engage the machinery of litigation in order to compel disclosure of information confidential to a competitor: Australian Competition and Consumer Commission v Cement Australia Pty Ltd (No 2) [2010] FCA 1082 at [23] per Greenwood J. 2127 But the test of 'necessity' in s 37AG(1) is a high bar and, as I have outlined, is to be approached bearing in mind the primary objective of safeguarding the public interest in open justice (s 37AE) which includes the interest of non-parties in being able to access documents on the court file in accordance with the Federal Court Rules 2011 (Cth) ('FCR') and in being able to make sense of the Court's reasons for judgment. As I explained in the 2018 Suppression Order Reasons, it is accordingly relevant to consider the centrality of the information to the ultimate resolution of the proceeding and therefore the extent to which the intelligibility of the Court's reasons will suffer if the information is subject to an order under s 37AF. 2128 Motorola does not take a position on the Hytera Application and Hytera does not take a position on the Motorola Application. It is thus convenient to deal with each application in turn. MOTOROLA APPLICATION 2129 The Motorola Application concerns four categories of documents: (a) confidential source code printouts; (b) confidential technical specifications and documents; (c) documents referring to confidential source code or confidential technical specifications and documents; and (d) internal Motorola documents and correspondence. 2130 The orders proposed by Motorola treat these categories separately. It therefore makes sense to take each in turn. Confidential Source Code Printouts (Part A of Annexure SMG-151) Proposed Order 2131 Motorola seeks an order that access to and disclosure (by publication or otherwise) of these documents be restricted to Motorola, its legal representatives and experts in the proceeding, and anyone entitled to access the information under a confidentiality regime agreed between the parties. 2132 It seeks that this order apply until: (a) the earlier of: (i) the date on which Motorola publicly discloses the source code for the 11 works the subject of this proceeding; or (ii) the date that is six years after the date on which Motorola (or any licensee or assignee of the source code for the 11 works) ceases to sell or provide warranty support for communication products that use (in whole or in part) the source code for the 11 works; or (b) further order, with liberty to both parties to apply on one month's notice. Evidence 2133 The documents affected by this proposed order are those listed at Part A of Annexure SMG-151 to Ms Gilchrist's affidavit, namely: Annexures to affidavit evidence 1. Confidential Annexures DPZ-7 to DPZ-26 (CB C7.08-C7.27) 2. Confidential Annexures DJL-3 to DJL-22 (CB C7.29-C7.48) 3. Confidential Annexures MAA-4 to MAA-6 (CB C7.51-C7.53) 4. Confidential Annexures MES-9 to MES-13 (CB C7.61-C7.65) 5. Confidential Annexures BJAH-3 to BJAH-10 (CB C7.67-C7.74) 6. Confidential Annexures BJAH-13 to BJAH-15 (CB C7.75-C7.77) 7. Confidential Annexure SBW-38 (CB C4.01(b)) 8. Confidential Annexures SBW-59 and SBW-60 (CB C4.02(b) and C4.02(c)) 9. Confidential Annexures SBW-63 and SBW-64 (CB C4.03(b) and C4.03(c)) 10. Confidential Annexure SR-52 (C8.35) 11. Confidential Annexures CMB-8, CMB-10, CMB-11 and CMB-13 (CB C6.01(e), C6.01(f), C6.01(g) and C6.01(h)) Exhibits and tenders 12. Tabs C.2 and C.3 of Hytera's Tender List (CB C14.217 and C14.218) 13. Print-outs of Motorola files in Section E of Hytera's Tender List (CB C14.296-C14.334) 14. Confidential Exhibit SBW-33 in Tab F.10 of Hytera's Tender List (CB C14.459_001-083) 15. Confidential Exhibit SBW-58 in Tab F.11 of Hytera's Tender List (CB C14.460_001-153) 16. Confidential Exhibit SBW-67 in Tab F.12 of Hytera's Tender List (CB C14.461_001-023) 2134 These are principally printouts of the source code from Motorola's works as well as: documents prepared by experts in the proceeding that reproduce the contents of such printouts; and printouts of Hytera source code which Motorola alleges has been copied from its works. 2135 The 11 Motorola works are the first version of the firmware for Motorola's DMR products. Motorola first supplied these products in the US and Canada in early 2007 and continues to supply products, incorporating more recent versions of the firmware, to the present day: Gilchrist-30 at §7. 2136 In support of the application for orders over this material, Ms Gilchrist gave evidence on information and belief based on instructions given to her by Mr Zetzl, Distinguished Member of the Technical Staff at Motorola, and Mr Bartusiak, Lead IP Counsel for Motorola. That evidence was to the following effect. 2137 First, it was explained that Motorola's source code is confidential and is treated as confidential within Motorola. Aside from a limited disclosure to the US Copyright Office in order to obtain copyright registration for the Motorola works, the source code has not been publicly disclosed. 2138 Secondly, because of the way Motorola's products operate, it regards its source code as critical in differentiating its products from those of its competitors. 2139 Thirdly and by extension, loss of the source code's confidentiality would work a competitive disadvantage on Motorola and confer a competitive advantage on Motorola's trade rivals. This result was said to amount to significant prejudice to Motorola. 2140 Fourthly, Motorola continues to use the source code because a significant portion of it is employed to develop programs that underpin products which Motorola currently offers. This is expected to continue with future products. Indeed, Motorola expects that, as long as it continues to develop and sell communication products, regardless of the underlying communications standard (e.g. DMR, 5G etc.) the source code for the Motorola works will be used in some way. 2141 Fifthly, as a result, the source code is commercially valuable and will remain so for many years to come. Motorola has been in the business of developing communication products for more than 90 years and does not expect to give the game away any time soon: Gilchrist-30 at §15. Consideration 2142 I am satisfied that the source code is not merely of historical relevance but represents, rather, information the confidentiality of which is of ongoing commercial value to Motorola: cf. Australian Competition and Consumer Commission v Air New Zealand Ltd (No 3) [2012] FCA 1430 at [34]. I accept that this will continue to be the case while Motorola or its licensee/assignee distributes products underpinned by firmware that relies upon a substantial portion of the source code. 2143 Although the Motorola source code is at the heart of this proceeding, it is not the case that the intelligibility of the Court's reasons for judgment will be adversely impacted if the source code itself is not publicly accessible. Indeed, it would be a poor state of affairs if the reasons were not intelligible without verbatim reproduction of the source code which is, of course, a configuration of symbols representing gobbledygook to anyone who cannot write computer programs (i.e. most people). Nor do I think there is any reason why a non-party looking to inspect, in accordance with the FCR, other publicly-accessible information in the proceeding, such as court documents or evidence read in open court which is not subject to a claim of confidentiality, would be hindered in understanding that material if access to the source code were not permitted. 2144 I am therefore content to make the orders sought by Motorola over this category of documents subject to one modification. 2145 The modification is this. I mentioned above that the proposed order would cease to operate upon the earlier of two events. One of these was the date that is six years after Motorola or its licensees or assignees stop selling or providing warranty support for products using the source code. I am not satisfied that a six year period in those circumstances would comply with s 37AJ(2). In my view, it is more appropriate that a three year period be specified, as this represents a considerable but not excessive period of time after the source code has stopped being commercially utilised before the suppression and non-publication order ceases to operate upon it. This modification applies also to the other documents covered by this proposed order, namely those listed in Parts B and C of SMG-151, to which I return below. 2146 For completeness, I should record the fact that upon reviewing each of the documents listed in Part A, I initially doubted whether the orders should extend to the document bearing court book number C14.459_083. Documents C14.459_001 to C14.459_082 together comprise Confidential Exhibit SBW-33 to the affidavit of Professor Wicker affirmed 28 March 2019. Each of those documents are printouts of source code. By contrast, C14.459_083 appears to be an index prepared by Herbert Smith Freehills, Motorola's solicitors, which identifies the file names and directory locations of the documents from C14.459_001 to C14.459_082 but does not itself appear to contain any source code. However, as I will explain further in relation to two documents in Part C (being the confidential annexures to Motorola's Second Further Amended Particulars of Copyright Claim) it appears that the directories and file information are present in the firmware used for Motorola's DMR products and, on that basis, I am satisfied that the information ought to be covered by the order. Even if that impression be incorrect, however, I am satisfied that the names and directory locations of the source code files are commercially sensitive in their own right and are by no means the kind of information helpful for public understanding of either the matter or the reasons for judgment. I therefore conclude that C14.459_083 should be included in the orders. Confidential Technical Specifications and Documents (Part B of Annexure SMG-151) Proposed Order 2147 In respect of the documents listed at Part B of Annexure SMG-151, Motorola seeks the same order, for the same duration, as that which it seeks in respect of those documents listed in Part A. Evidence 2148 Part B of Annexure SMG-151 lists the following documents: Annexures to affidavit evidence 1. Confidential Annexures LKKS-2 to LKKS-4 (CB C7.01-C7.03) 2. Confidential Annexures DPZ-2 to DPZ-5 (CB C7.04-C7.07) 3. Confidential Annexure DJL-2 (CB C7.28) 4. Confidential Annexures MAA-2 to MAA-3 (CB C7.49-C7.50) 5. Confidential Annexures MES-2 to MES-7 (CB C7.54-C7.59) 6. Confidential Annexures SBW-36 and SBW-37 (CB C8.03 and C8.04) 7. Confidential Annexures SR-38 to SR-40 and SR-47 to SR-51 (CB C8.21-C8.23 and C8.30-C8.34) Exhibits and tenders 8. Tabs 1 to 4, 25, 27 to 29, 33, 45, 70, 71, 74, 79 to 85, 87 to 95, 110 to 118, 166, 169, 172, 175 and 192 of Motorola's Tender List (CB C14.013-C14.016, C14.036, C14.038-C14.040, C14.044, C14.056, C14.079, C14.080, C14.083, C14.088-C14.094, C14.096-C14.104, C14.119-C14.127, C14.171, C14.174, C14.177, C14.180 and C14.195) 9. Tabs 3 and 6 of Motorola's list of further tender documents (CB C14.540 and C14.543) 2149 These documents are copies of Motorola's confidential technical specifications and documents relating to the Motorola works and Motorola's DMR products, some of which were discovered by Hytera as documents in Hytera's possession, as well as Hytera documents which Motorola alleges have been copied from these Motorola documents: Gilchrist-30 at §17. 2150 Ms Gilchrist gave evidence that these documents contain and discuss the detailed design specifications for the source code and/or software components used in the Motorola works: Gilchrist-30 at §18. The documents include software management plans, documents relating to the development of the Motorola works and various presentations and memoranda setting out the architecture and requirements of the Motorola works. 2151 Some of the documents bear confidentiality markings applied by staff at Motorola. These markings were applied pursuant to internal policies covering the management of commercially sensitive material within Motorola. However, even for documents in this category which are unmarked, Ms Gilchrist gave evidence upon belief in the truth of information she received from Mr Bartusiak that all of these documents are treated by Motorola as confidential and have not been publicly disclosed. 2152 Accordingly, so Motorola contends, disclosure of these documents would reveal the design and architecture of the source code for the Motorola works, and would cause Motorola substantial prejudice in the same way as disclosure of the source code itself would do: Gilchrist-30 at §19. Consideration 2153 As is clear from the evidence of Ms Gilchrist, the justification for the order in respect of this category of documents depends on the relationship between this material and the source code itself. 2154 Having reviewed the documents, I am satisfied that the asserted relationship exists. That is, although this is historical material created during the development of the Motorola works, and in that sense has served its purpose many years ago, nonetheless it is clear that the information is commercially sensitive and will continue to be such while the source code is used in the development and distribution of Motorola's products. 2155 I also accept that these documents are confidential and have not been publicly disclosed. 2156 There is a further matter to note. Some of these documents are reasonably lengthy and, being in the nature of plans, presentations, technical specifications and the like, contain portions of text that cannot in themselves be said to be commercially sensitive – for instance, cover pages, tables of contents and timetables which do not contain substantive information. An example is the third page of document C7.01 which is a 'sign-off sheet' that states the names and titles of various participants in the project and provides space for them to sign in accordance with a 'sign-off procedure.' 2157 I have considered whether it is more appropriate that orders should apply only to parts of the documents in this category (or to some documents in part, and to others in full). I have concluded that this would not be appropriate for two reasons. First, in some cases it is unclear whether information in the tables of contents, cover pages, timetables etc. is substantive and commercially sensitive or not. Secondly, in any case, because the overwhelming majority of the information in these documents is commercially sensitive, I do not consider that the public interest in open justice would meaningfully be served by the availability of redacted copies in which only the non-substantive portions of the documents were visible. Such redacted copies could not apprise a member of the public with any useful knowledge about the matter. Given this, requiring Motorola to embark on a redactions exercise does not seem to me to be justified given the expense, time and cost already expended on this large piece of litigation. 2158 Accordingly, subject to modifying the orders to include the three year rather than six year period, I consider that the proposed orders in respect of the documents in Part B of SMG-151 should be made. Documents Referring to Confidential Source Code or Technical Specifications and Documents (Part C of Annexure SMG-151) Proposed Order 2159 In respect of the documents listed at Part C of Annexure SMG-151, Motorola seeks the same order, for the same duration, as that which it seeks in respect of those documents listed in Parts A and B. Evidence 2160 Part C of Annexure SMG-151 lists the following documents: Pleadings 1. Confidential Annexure 1 to Motorola's Second Further Amended Particulars of Copyright Claim (CB C1.03(a)) 2. Confidential Annexure 2 to Motorola's Second Further Amended Particulars of Copyright Claim (CB C1.03(b)) Submissions 3. Motorola's Outline of Opening Submissions on Copyright Issues and Additional Damages Issues (CB C2.01) 4. Hytera's Outline of Opening Submissions on Copyright Issues and Additional Damages Issues (CB C2.02) 5. Motorola's Outline of Closing Submissions – Module II Section B: The Motorola Works 6. Motorola's Outline of Closing Submissions – Module II Section C: The Accused Hytera Firmware (including Attachment 1) 7. Motorola's Outline of Closing Submissions – Module II Section D: Subsistence and ownership of copyright 8. Motorola's Outline of Closing Submissions – Module II Section E: Infringement of copyright 9. Motorola's Outline of Reply Submissions – Module II-R: Copyright Infringement 10. Motorola's Outline of Closing Submissions – Module III: Additional Damages and Other Relief 11. Hytera's Outline of Closing Submissions – Module II: Copyright 12. Hytera's Outline of Closing Submissions – Additional Note to Module II: Copyright Hearing transcripts 13. Transcript of Day 9 (7 August 2020): Copyright hot tub (T462-T505) 14. Transcript of Day 10 (10 August 2020): Copyright hot tub (T545-T606) 15. Transcript of Day 11 (11 August 2020): Copyright hot tub (T620-T682) 16. Transcript of Day 12 (12 August 2020): Copyright hot tub (T687-T772) 17. Transcript of Day 16 (19 August 2020): Motorola oral closing submissions (T909-T914 and T920-T931) 18. Transcript of Day 17 (20 August 2020): Hytera oral closing submissions (T998-T1036) 19. Transcript of Day 18 (21 August 2020): Motorola oral closing submissions (T1122-T1127) Joint expert reports 20. Confidential Joint Expert Report on Copyright Issues and Additional Damages Issues (CB C2.05) Annexures to affidavit evidence 21. Confidential Annexure LKKS-1 (CB C3.01(a)) 22. Confidential Annexure DPZ-1 (CB C3.02(a)) 23. Confidential Annexure DPZ-6 (CB C3.03(a)) 24. Corrections to Zetzl #2 (CB C3.03(b)) 25. Confidential Annexure DJL-1 (CB C3.04(a)) 26. Corrections to Ley #1 (CB C3.04(b)) 27. Confidential Annexure DJL-23 (CB C3.05(a)) 28. Confidential Annexure DJL-24 (CB C3.06(a)) 29. Confidential Annexure MAA-1 (CB C3.07(a)) 30. Confidential Annexure JFC-1 (CB C3.08(a)) 31. Confidential Annexure MES-1 (CB C3.09(a)) 32. Confidential Annexure MES-8 (CB C7.60) 33. Confidential Annexure MES-14 (CB C3.10(a)) 34. Confidential Annexure MES-15 (CB C3.11(a)) 35. Confidential Annexure BJAH-1 (CB C3.12(a)) 36. Confidential Annexure BJAH-11 (CB C3.13(a)) 37. Confidential Annexures BJAH-16, BJAH-18 to BJAH-25, BJAH-27 and BJAH-28 (CB C7.78, C7.80-C7.87, C7.89 and C7.90) 38. Confidential Annexure SAS-1 (CB C3.17(a)) 39. Confidential Annexure SAS-2 (CB C3.17(b)) 40. Confidential Annexure SAS-3 (CB C3.17(c)) 41. Confidential Annexure SAS-5 (CB C3.18(b)) 42. Confidential Annexure SBW-32 (CB C4.01(a)) 43. Confidential Annexures SBW-34 and SBW-35 (CB C8.01 and C8.02) 44. Confidential Annexure SBW-56 (CB C4.02(a)) 45. Confidential Annexure SBW-57 (CB C8.05) 46. Confidential Annexure SBW-61 (CB C4.03(a)) 47. Confidential Annexure SBW-65 (CB C4.04(a)) 48. Confidential Annexure SBW-66 (CB C4.05(a)) 49. Confidential Annexure SR-22 (CB C4.06(b)) 50. Confidential Annexure SR-32 (CB C8.15) 51. Confidential Annexure SR-41 (CB C8.24) 52. Confidential Annexures SR-44 and SR-45 (CB C8.27 and C8.28) 53. Confidential Annexure SR-53 (CB C8.36) 54. Confidential Annexure CMB-3 (CB C6.01(a)) 55. Confidential Annexures CMB-4 to CMB-6 and CMB-14 to CMB-17 (CB C6.01(b)-C6.01(d) and C6.01(i)-C6.01(l)) 56. Confidential Annexure CMB-22 (CB C6.03(a)) 57. Confidential Annexure CMB-23 (CB C10.05) 58. Confidential Annexure CMB-24 (CB C6.04(a)) 59. Confidential Annexure CMB-25 (CB C6.04(b)) 60. Corrections to CMB-25 (CB C6.04(b)(1)) 61. Confidential Annexure CMB-26 (CB C6.04(c)) 62. Confidential Annexure AG-19 (CB C6.05(b)) Exhibits and tenders 63. Tabs 127, 135, 152, 153 and 186 to 191 of Motorola's Tender List (CB C14.135, C14.143, C14.159, C14.160 and C14.189-C14.194) 64. Tab C.1 of Hytera's Tender List (CB C14.216) 65. Tabs 4 and 21 of Motorola's list of further tender documents (CB C14.541 and C14.558) 2161 Ms Gilchrist gave evidence that these documents 'describe or refer to' the information contained within the documents listed in Part A and/or Part B of Annexure SMG-151: Gilchrist-30 at §24. 2162 Accordingly, Motorola contends that these documents if disclosed would reveal the contents of the Motorola source code or Motorola confidential technical specifications and documents. It therefore says that access to and disclosure of these documents should be restricted for the same reasons set out above: at §25. 2163 Ms Gilchrist noted, however, that documents CMB-22 and CMB-23 stand in a slightly different position. Those documents discuss and disclose in part the content of other Motorola code (i.e. not the source code the subject of Part A of SMG-151). Ms Gilchrist gave evidence on information and belief from Mr Bartusiak that this code is confidential and is treated as such within Motorola and has not been publicly disclosed, and will continue to be used commercially by Motorola for many years to come. Accordingly, Motorola says these documents should be treated the same way as the others. Consideration 2164 Part C contains a large number of documents of quite different types. Contrary to Ms Gilchrist's evidence, it is far from apparent to me that it is appropriate they all be dealt with in the same manner. It is useful to consider the Part C documents in tranches according to the headings used in Ms Gilchrist's affidavit: Pleadings 2165 The two documents in this category are the confidential annexures to Motorola's Second Further Amended Particulars of Copyright Claim. As foreshadowed above while discussing document C14.459_083 in Part A, these two documents are tables containing file names and directory locations for the Motorola code (and the Hytera code alleged to contain portions of the Motorola code). I am satisfied that the text itself is information which is commercially sensitive and which should be subject to the suppression and non-publication order. Submissions 2166 The second category of documents in Part C comprises the written outlines of submissions filed by each party on the copyright case. 2167 I am not satisfied that the entirety of the submissions contain information which, if disclosed, would risk causing commercial prejudice to Motorola: Seven Network v Cricket Australia (No 2) [2021] FCA 1032 at [37]. 2168 Indeed, this is obvious when one has regard to Motorola's outline of opening submissions (CB C2.01) which contains coloured shading over certain parts of the document concerning confidential material. Substantial portions of the submissions are not shaded and do not contain material the disclosure of which would appear to cause prejudice to Motorola. 2169 Unlike the documents in Part B, I consider that the public interest in open justice would meaningfully be served by the availability of redacted copies of the written submissions for inspection by non-parties. Accordingly, I decline to make the orders sought in respect of these documents. However, they can remain subject to interim confidentiality orders while Motorola submits modified short minutes of order which, if made, would apply only to the confidential and commercially sensitive portions of the submissions. Motorola should also submit proposed redacted versions of the submissions, which can be placed on the court file. Hearing Transcripts 2170 The passages of the transcript identified in Part C are marked 'Transcript in Confidence' and record portions of the hearing that were conducted in closed court. 2171 In particular, the transcript passages record confidential expert hot tubs and confidential sections of the parties' closing submissions. 2172 I am satisfied that these transcript passages should be subject to the s 37AF orders. Confidential Joint Expert Report 2173 This document is the confidential joint report of the experts who gave evidence on the copyright case. The document contains much commercially sensitive information including portions of source code. I consider that it should be subject to the s 37AF orders. Annexures to Affidavit Evidence 2174 I am satisfied that each of these confidential annexures contain, either entirely or in major part, information of the same kind as that which is found in the Part A or Part B documents. That is, they contain extracts of the source code or information relating to the development of the Motorola works and/or the source code and/or firmware for those programs. Accordingly, these documents should also be subject to the s 37AF orders. Exhibits and Tenders 2175 These documents should be treated the same way as the annexures, for the same reasons. 2176 For completeness, I note that I considered whether the final document in this category, i.e. that bearing court book number C14.558, stood in a different position. This is a letter from the Respondents' solicitors to Motorola's solicitors. It forms part of an exchange of barbs regarding the adequacy of Motorola's pleading on the copyright case and the sufficiency with which the material allegations in that case had been particularised. There are certainly portions of the letter which do not contain any material confidential to Motorola. However, it seems that the majority of pages (including the annexure) do contain such information, so I am satisfied that the document as a whole should be treated the same way as the other exhibits, tenders and annexures in Part C. Unlike the written submissions referred to above and having regard to s 37AE, I do not think the availability of a redacted version of this document could meaningfully assist a non-party in understanding the matter or the reasons for the judgment. Internal Motorola Documents and Correspondence (Part D of Annexure SMG-151) Proposed Order 2177 The documents listed in Part D of Annexure SMG-151 stand in a unique position and Motorola seeks a slightly different order in respect of them. 2178 Specifically, Motorola seeks that the suppression and non-publication order in respect of these documents shall operate: (a) in relation to items 2, 3 and 8 of the documents listed in Part D of Annexure SMG-151 to Gilchrist-30, the date on which the Applicant publicly discloses the information in those documents, or further order; and (b) in relation to items 1 and 4-7 of the documents listed in Part D of Annexure SMG-151 to Gilchrist-30, until 4.00 pm on the date that is 15 years after the final day of the trial on liability in this proceeding, or further order. Evidence 2179 The documents listed in Part D of Annexure SMG-151 are: Submissions 1. Hytera's Outline of Closing Submissions – Module III: Additional Damages and Other Relief Annexures to affidavit evidence 2. Confidential Annexure MH-1 (CB C3.14(a)) 3. Confidential Annexure MH-2 (CB C3.15(a)) 4. Confidential Annexure CMB-1 (Binotti) (CB C3.16(a)) 5. Confidential Annexures CMB-2 to CMB-9 and CMB-11 (Binotti) (CB C7.91-C7.98 and C7.100) Exhibits and tenders 6. Tabs 96 to 107 of Motorola's Tender List (CB C14.105-C14.116) 7. Tabs D.1, D.7, D.9, D.18, D.21, D.34, D.35, D.45, D.48, D.55, D.59, D.61, D.62, D.64, D.69, D.71, D.86, D.91, D.92, D.93, D.94, D.95, D.100, D.120, D.133, D.142, D.144, D.145, D.146, D.147, D.148, D.149, D.150, D.151, D.152, D.155 and D.158 of Hytera's Tender List (CB C14.219 to C14.223, C14.225, C14.226, C14.228, C14.229, C14.232 to C14.234, C14.236, C14.237, C14.239, C14.241, C14.247, C14.251 to C14.255, C14.258, C14.264, C14.274, C14.280 to C14.289, C14.292 and C14.295) 8. First Notice to Admit dated 26 February 2020 and First Notice of Dispute dated 11 March 2020 (CB C1.09 and C1.10) 2180 The reason the proposed order is different than that proposed for Parts A to C is that these documents do not relate to the source code and technical specifications etc. which underpin the Motorola works. They contain information said to be confidential and commercially sensitive in a broader sense. The material consists of internal Motorola documents and correspondence, or documents which describe the contents of internal Motorola documents and correspondence: Gilchrist-30 at §27. 2181 In her affidavit, Ms Gilchrist gave various examples of the kinds of information which these documents contain: information from Motorola's employment records relating to the personal details of Motorola employees (MH-1 and MH-2, and item 8); copies of agreements with Motorola's contractor suppliers, all of which bear confidentiality markings applied in accordance with the internal policies I referred to above (CMB-4 to CMB-9); copies of Motorola procurement policies and current standard form employee IP assignment agreement, as well as information regarding Motorola's practices for its employees and contractors (CMB-1, CMB-2, CMB-3 and CMB-11); copies of Motorola's intra-group research and development and licence agreements (item 6). With one exception, all of these agreements include obligations prohibiting disclosure of the terms of the agreement to third parties; and Motorola documents and correspondence regarding internal investigations within Motorola and market/competitor analysis (items 1 and 7). 2182 In support of the proposed s 37AF orders, Ms Gilchrist gave evidence based on information and belief from Mr Bartusiak and from Ms Binotti, Lead Counsel for Labor and Employment at Motorola, to the following effect. 2183 First, it was said that these documents have not been publicly disclosed and describe commercially sensitive information about Motorola's internal processes: §29(a). 2184 Secondly, Motorola considers that the information will remain commercially sensitive for at least another 15 years and likely much longer than that: §29(b). 2185 Thirdly, if the documents are disclosed or otherwise made publicly available, this will cause commercial prejudice to Motorola in the conduct of its DMR business in Australia and other countries because the information is capable of being used by Motorola's competitors to obtain details about Motorola's internal processes and thereby to erode Motorola's competitive advantage: §29(c). 2186 Lastly, there is also the prospect that disclosure of some the documents in Part D would cause Motorola to breach privacy obligations owed to third parties in the US, including its employees in that country: §30. Consideration 2187 It is convenient to consider the documents under the headings Ms Gilchrist used in her affidavit. I consider the duration of the proposed order at the end. Submissions 2188 The first document in the Part D list is Hytera's outline of closing submissions on Module III: Additional Damages and Other Relief. I accept that some parts of the submissions contain information confidential to Motorola in the manner described, for example at various points between §30 and §54 and between §136 and §144. However, there are substantial parts of the submissions which cannot be said to contain information commercially sensitive to Motorola. Accordingly, as with the written submissions in the Part C documents, Motorola should submit revised short minutes of order that, if made, would apply only to part of these submissions. Proposed redacted copies which can be filed should also be prepared. I return to this topic below under the heading 'Conclusions and Disposition on Suppression Order Applications'. Annexures to Affidavit Evidence 2189 These documents contain information regarding confidential arrangements between Motorola and its employees, contractors and contract labour service providers. This information is relevant but by no means central to the resolution of the key issues in dispute in the proceeding. I accept it would be commercially prejudicial to Motorola for the confidentiality of this material to be lost. Accordingly, I am satisfied that orders under s 37AF should apply to this material. Exhibits and Tenders 2190 These documents principally contain information in the nature of data and business analytics, employee information, competitor analysis and trade intelligence and internal investigations regarding employee movements and perceived corporate espionage. With two exceptions, I consider that these should be subject to the s 37AF orders. 2191 The two exceptions are these: C14.247 and C14.252. Those documents are meeting invitations and are essentially insubstantial. Although the titles of the invitation suggest the discussion at the meeting was likely to be consequential, I do not see any reason for the invitations themselves to be subject to the orders. For instance, there was no evidence from Motorola that these two documents should be suppressed because they contain the names of meeting invitees. 2192 As such, the revised short minute of order should exclude these two documents from its coverage. Duration of Order 2193 As set out above, Motorola seeks that: the order in respect of items 2, 3 and 8 of Part D apply until Motorola publicly discloses the information in those documents, or further order; and, the order in respect of items 1 and 4-7 apply until the date that is 15 years after the end of the liability trial in the proceeding, or further order. 2194 The reason for the different treatment is this. Items 2, 3 and 8 contain personal information of Motorola's US employees. Motorola's evidence was that this information attracts privacy obligations in the US and will do so while the information is not publicly disclosed. No detail was provided of these privacy obligations or how exactly they operate upon the information in question. This was unfortunate because such detail would have been helpful. That said, I have no reason to doubt the evidence of Ms Gilchrist on this matter, which relied on information provided by Ms Binotti, Motorola's Lead Counsel for Labor and Employment based in the US. In the circumstances, therefore, I am satisfied that the duration of this order is consistent with s 37AJ of the FCA Act. 2195 However, in respect of items 1 and 4-7 of Part D, there are two difficulties. 2196 First, I see no reason why there should be no provision for the order to cease operating in the event of public disclosure as there is with the other orders. That is, the order over these documents should, subject to further order, apply until the earlier of: (a) the date on which the information is publicly disclosed; or (b) the date that is a specified time after the end of the liability trial. Secondly, for the purposes of (b), 15 years appears to me to be an excessive length of time. The opinion of Mr Bartusiak recorded in Ms Gilchrist's affidavit is insufficient to persuade me that s 37AJ would be satisfied if a 15-year period were included in the orders. I can, however, see that the information in items 1 and 4-7 is of the sort that will remain sensitive to Motorola in a way which, unlike the documents in Parts A to C, is not tethered to its commercial use of any particular piece of information or its offering for sale of any particular product or class of products. 2197 In the circumstances, having regard to the duty which s 37AJ imposes on the Court, I consider that an eight year period is more appropriate. There is nothing to prevent Motorola applying to extend the operation of the orders as the expiration date approaches. HYTERA APPLICATION 2198 Hytera seeks suppression and non-publication orders over the following kinds of documents: Development Documents and Development Source Code (Part A of Annexure MAV-145); Other Hytera source code (Part B of Annexure MAV-145); Hytera Technical Specifications (Part C of Annexure MAV-145); Circuit layouts relating to Hytera devices (Part D of Annexure MAV-145); Document disclosing the values of certain operation codes (Part E of Annexure MAV-145); Price Information in Picking Slips (Part G of Annexure MAV-145); Other confidential Hytera business information (Part H of Annexure MAV-145); Personal Information (Part I of Annexure MAV-145); and Other confidential documents filed with the Court (Part J of Annexure MAV-145). 2199 Missing from this list are documents relating to the EP Licence Agreement (Part F of Annexure MAV-145) which is the subject of the Joint Application considered below. 2200 In support of its application, Hytera relied upon the affidavit of Mr Vincent, its solicitor in the proceeding, affirmed 30 June 2021. In parts of his affidavit, Mr Vincent gave evidence based on his belief in the truth of information he received from: Mr Brown, an independent expert called by Hytera in the proceeding; Professor Sun, Vice-President of Hytera Communications Corporation Limited, the First Respondent; Mr Jun Ping Luo, Director of the Brand Communications and Marketing Department at the First Respondent; Mr Zeping Duan, in-house legal counsel at the First Respondent; and Mr Xiao (Sean) Li, Technical Director at Hytera Australia, the Second Respondent. 2201 It is useful to consider each of the categories in turn. Development Documents and Development Source Code (Part A of Annexure MAV-145) Proposed Order 2202 Hytera proposed these orders which, if made, would apply equally to the documents in Parts A, B, C, D, E and H of Annexure MAV-145: 1. Pursuant to section 37AF of the Federal Court of Australia Act 1976 (Cth), and subject to any restrictions imposed by the confidentiality regime agreed between the parties dated 10 April 2018 (Confidentiality Regime) and/or the confidentiality regime agreed between the parties dated 24 May 2019 (MSI Code Confidentiality Regime) (as applicable), access to and disclosure (by publication or otherwise) of the following be restricted to the Respondents (and their experts) and the legal representatives of the Respondents, and those persons to whom access is allowed under the terms of the Confidentiality Regime: (a) the documents identified as "confidential in full" in Parts A, B, C, D, E and H of Annexure MAV-145 to the thirty eighth affidavit of Mark Andrew Vincent dated 30 June 2021 (Vincent #38); and (b) the unredacted versions of the documents identified as "confidential in part" in Part A, B, C, D, E and H of Annexure MAV-145. 2. Order 1 shall operate until 4 pm on the date that is five years after the final day of the trial on liability in this proceeding, or further order. 2203 There are two preliminary matters worth noting. First, as proposed orders 1 and 2 demonstrate, Hytera seeks that the suppression and non-publication order apply to some documents in full and others in part. By proposed order 9 (not extracted above) it is contemplated that Hytera would file redacted copies of the documents that are partly suppressed. As a general proposition, this approach is to be encouraged, for the availability on the court file of redacted copies (rather than nothing at all) is consistent with the primary objective in s 37AE. The Court is grateful to Hytera for preparing versions of documents with temporary markings indicating where the permanent redactions will be applied if the proposed orders are made. 2204 Secondly, Mr Vincent gave evidence that some of the documents the subject of the Hytera Application are confidential for multiple reasons. Accordingly, those documents appear in multiple parts of Annexure MAV-145. Unless it is necessary to do so, I will not identify below whether documents appear in one or multiple parts. Evidence 2205 The documents listed in Part A of Annexure MAV-145 are as follows (note: '_EN' signifies an English-language translation of the original document): # Court Book Reference Confidentiality Claim (Full/Part) 1. CB C14.214 In full CB C14.458_002 CB C14.458_003 (_EN) 2. CB C14.458_004 In part CB C14.458_005 (_EN) 3. CB C14.458_012 In full CB C14.458_013 (_EN) 4. CB C14.204 In part CB C14.458_028 CB C14.458_029 (_EN) 5. CB C14.458_038 In part CB C14.458_039 (_EN) 6. CB C14.211 In full CB C14.458_042 CB C14.458_043 (_EN) 7. CB C14.212 In full CB C14.458_044 CB C14.458_045 (_EN) 8. CB C14.206 In full CB C14.458_060 CB C14.458_061 (_EN) 9. CB C14.458_062 In part CB C14.458.063 (_EN) 10. CB C14.458_066 In part CB C14.458_067 (_EN) 11. CB C14.458_076 In full CB C14.458_077 (_EN) 12. CB C14.458_082 In full CB C14.458_083 (_EN) 13. CB C14.458_090 In part CB C14.458_091 (_EN) 14. CB C14.458_092 In part CB C14.458_093 (_EN) 15. CB C14.458_115 In part CB C14.458_116 (_EN) 16. CB C14.458_126 In part CB C14.458_127 (_EN) 17. CB C14.553 In full 18. CB C6.05(a) In part 2206 Part A includes source code extracts and other technical documents relating to Hytera's DMR technology: Vincent-38 at §16. Mr Vincent gave evidence that all of the documents from 1 to 17 above were created by engineers employed by Hytera working under Professor Sun's supervision to develop technology for DMR products: §18. 2207 The material is said to be confidential and to be of ongoing commercial utility for Hytera given its relevance to the operation of the DMR products which it currently offers: §22(a). It is further said to be the result of an expensive and time-consuming development process: §22(c). 2208 Given the nature of DMR products, there are security risks which developers and operators must manage. In particular, it is possible to 'hack' some DMR products and interfere with or undermine their operation. Mr Vincent gave evidence that the information contained within the documents in Part A was of a sort that would make Hytera's products more attractive targets for would-be hackers: §§15 and 21. 2209 Consequently, Hytera's position is that it would suffer significant prejudice if the confidential information in the Part A documents was to become publicly known. Consideration 2210 I have considered each of the Part A documents. For the same reasons I gave in respect of Part A and Part B of the Motorola Application, I am satisfied that it is necessary that these documents be subject to the orders under s 37AF on the basis that Hytera would suffer commercial prejudice if the information were to be publicly disclosed. 2211 I am also satisfied that, in respect of the documents that will be suppressed in part, the redactions proposed by Hytera are appropriate. 2212 Hytera proposes that the order operate upon these documents until the date that is five years after the final day of the trial on liability in this proceeding or further order. Having regard to s 37AJ and the nature of the information, I consider that this duration is appropriate. Other Hytera Source Code (Part B of Annexure MAV-145) Proposed Order 2213 The proposed order set out under Part A covers Part B also. Evidence 2214 The documents listed in Part B of Annexure MAV-145 are: Part B.1 – Annexures and exhibits # Court Book Reference Confidentiality Claim (Full/Part) 19. CB C14.460_003 In part 20. CB C14.460_007 In part 21. CB C14.460_008 In part 22. CB C14.460_009 In part 23. CB C14.460_062 In part 24. CB C14.460_063 In part 25. CB 14.01 (Note: this document is also in category C) In part 26. CB 16.28 In full 27. CB 16.31 In full 28. CB C.2.04 (Note: this document is also in category F.2) In part 29. CB 2.19 In part CB 16.29 30. CB 5.01(a) (Note: this document is also in category C.1) In part 31. CB 5.04(a) In part 32. CB 5.05(a) (Note: this document is also in category C) In part 33. CB 5.05(b) (Note: this document is also in category C) In part 34. CB 5.08(a) In part 35. CB 6.05(a) In part 36. CB 6.05(b) In part 37. CB 6.05(c) In part 38. CB 6.06(a) In part 39. CB 6.06(b) In part 40. CB 6.07(b) In part 41. CB 6.07(c) In part 42. CB 6.07(d) In part 43. CB 6.07(e) In part 44. CB 7.02(a) In part 45. CB 7.05(b) In full 46. CB 7.05(c) In full 47. CB 7.05(d) In full 48. CB 7.07(b) In full 49. CB 7.07(c) In full 50. CB 7.08(a) In part 51. CB C14.530 In full 52. CB 02A.3 – Motorola Closing Submissions Module III (Additional damages for copyright and patents) In part 53. CB 02A.S3 – Motorola Closing Submissions Module III-S (Further submissions on additional damages) In part Part B.2 – Confidential parts of submissions and transcript referring to documents in Part B.1 54. CB 3.01 In part 55. CB 3.02 In part 56. Hytera Closing Submissions on 764 Patent dated 15 August 2019 In part 57. Hytera Closing Submissions on 960 Patent dated 15 August 2019 In part 58. Motorola Closing Submissions on 355 Patent dated 14 August 2019 In part 59. Motorola Closing Submissions on 764 Patent dated 14 August 2019 In part 60. Motorola Closing Submissions on 960 Patent dated 14 August 2019 In part 61. Motorola Reply Submissions on 764 Patent dated 16 August 2019 In part 62. Transcript in confidence of hearing 1 August 2019 In part 63. Transcript in confidence of hearing 2 August 2019 In part 64. Transcript in confidence of hearing 15 August 2019 In part 65. Transcript in confidence of hearing 16 August 2019 In part 66. Transcript in confidence of hearing 30 July 2019 In part 67. Transcript in confidence of hearing 6 August 2019 In part 2215 Mr Vincent gave the following evidence in support of Hytera's application over these documents. 2216 First, he explained that the documents in Part B.1 comprise (§28): confidential annexures and exhibits containing printouts or extracts of Hytera source code, other than Development Source Code (i.e. the subject of Part A), that were admitted into evidence ('Other Hytera Source Code'); and confidential annexures to affidavits filed in the proceeding which refer to or describe Other Hytera Source Code (including names of functions from the source code and descriptions of them) or the operation of Hytera devices at a source code level in a manner that Hytera regards as confidential. 2217 Secondly, the Other Hytera Source Code includes extracts which Motorola alleges were copied from it but also extracts which are not alleged to have been copied: §§29-30. 2218 Thirdly, the security risk posed by hackers applies to this source code in various ways, for example if apprised of it a hacker could (§31): exploit a 'buffer overflow' which may enable the hacker to write new memory outside of the device's intended buffer and, by that means, cause the device to perform unexpected or unintended operations; attempt to facilitate eavesdropping or flood a communications network; or attempt to render communications devices or a communications network inoperable. 2219 Fourthly, existing and potential future Hytera products rely or will rely on this source code or substantial portions of it: §32(a). 2220 Fifthly, trade rivals, if apprised of the source code, could use it to Hytera's commercial disadvantage, including by circumventing the work necessary to implement 'pseudo-trunking in direct mode', which is said to confer a competitive advantage on Hytera's products: §33. 2221 Sixthly, the source code or references to it is/are found in the documents in Part B2, being written submissions and transcripts of closed sessions of the hearing in this matter: §36. 2222 Consequently, Hytera says that it would suffer prejudice if the material contained in Part B were not subject to an order under s 37AF. Consideration 2223 The considerations applicable to this category are largely the same as those applicable to Part A. Accordingly, I accept that the orders should be made. I further accept that the proposed duration and the proposed redactions in respect of the documents that are partly confidential, are appropriate. Hytera Technical Specifications (Part C of Annexure MAV-145) Proposed Order 2224 The proposed order set out under Part A covers Part C also. Evidence 2225 The documents listed in Part C of Annexure MAV-145 are: # Court Book Reference Confidentiality Claim (Full/Part) 68. CB 13.01 In part 69. CB 14.01 (Note: this document is also in category B.1) In part 70. CB 5.01(a) (Note: this document is also in category B.1) In part 71. CB 5.05(a) (Note: this document is also in category B.1) In part 72. CB 5.05(b) (Note: this document is also in category B.1) In part 73. CB 8.04 In full 74. CB 8.05 In full 75. CB 8.06 In full 76. CB 8.07 In full 77. CB 8.09 In full 78. CB 9.05 In full 79. CB 9.06 In full 80. CB 9.11 In full 81. CB 9.12 In full 82. CB 9.13 In full 83. CB 9.18 In full 84. CB 9.19 In full 2226 Mr Vincent explained that the documents in Part C are technical specifications and design manuals which Hytera regards as commercially sensitive. This is because they contain detailed technical information concerning hardware and software components of Hytera's products: §40(a). 2227 More specifically, his evidence was that the documents contain confidential information that includes one or more of the following: specifications of the framework for the design, specific implementation and/or testing process for certain features of devices; specifications for data structure design; the process of certain applications; how certain applications interface with other layers of the devices; the operational characteristics of devices; schematics and design diagrams; parameter definitions; and unresolved problems or questions that need to be resolved in the course of development. 2228 Hytera further says that these documents are kept confidential and have not been publicly disclosed, and are likely to remain confidential and sensitive for a period of at least five years after the liability trial in this matter: §§40(b) and 41. Consideration 2229 I am satisfied that the information contained within the Part C documents is commercially sensitive and that it is necessary to prevent prejudice to Hytera that it be subject to the orders proposed. I am content with the duration of the order and the proposed redactions. 2230 For completeness, I should note that significant portions of text in these documents are not in English. Although such portions are not intelligible to me, I am satisfied from the context of the documents and Mr Vincent's evidence that the information not recorded in English is of the same nature as the rest. Circuit Layouts Relating to Hytera Devices (Part D of Annexure MAV-145) Proposed Order 2231 The proposed order set out under Part A covers Part D also. Evidence 2232 The documents listed in Part D of Annexure MAV-145 are: # Court Book Reference Confidentiality Claim (Full/Part) 85. CB 14.01 In part 86. CB 9.08 In full 87. CB 9.17 In full 2233 These documents contain information about particular circuit layouts employed in Hytera devices: Vincent-38 at §43. 2234 Mr Vincent gave evidence that these documents are confidential and treated as such within Hytera. He gave evidence, further, that public disclosure of the information would be commercially prejudicial to Hytera by placing into the hands of its trade rivals information about its circuit layouts which they would not otherwise have and may look to exploit: §44. 2235 Given the use in currently-offered Hytera devices of componentry which makes use of these circuit layouts, and the prospect that future products might also rely on them, the commercial sensitivity of these documents will endure for a number of years: §§44-45. Consideration 2236 Virtually all of the content in CB 9.08 and CB 9.17 is circuit layouts. I accept that if this information were publicly disclosed, commercial prejudice would accrue to Hytera including because of its potential value in the hands of competitors. I am satisfied, therefore, that the orders should be made. 2237 In the case of CB 14.01, which is confidential annexure EV-10 to the affidavit of Professor Viterbo affirmed 31 January 2019, I am satisfied that the proposed redactions are appropriate. 2238 As with the foregoing Parts of Annexure MAV-145, the proposed duration of the order is appropriate for the purposes of s 37AJ. Document Disclosing the Values of Certain Operation Codes (Part E of Annexure MAV-145) Proposed Order 2239 The proposed order set out under Part A covers Part E also. Evidence 2240 There is only one document in Part E, C14.011, which Hytera asserts is confidential in part. 2241 What that document contains is the values of the opcodes assigned to various operations capable of being performed by Hytera DMR devices: Vincent-38 at §47. 2242 The sensitivity of this information inheres not in its potential value to trade rivals but rather to its potential range of misuses were it to fall into the hands of hackers: §48. 2243 The opcodes are in use in existing Hytera DMR devices and depending on the nature and timing of updates made to the source code underpinning those devices, this security risk may endure for a number of years: §49. Consideration 2244 I am satisfied that this document should be partially suppressed in the manner suggested by Hytera for the duration that it seeks. Price Information in Picking Slips (Part G of Annexure MAV-145) Proposed Order 2245 Hytera seeks the following orders in respect of the document listed in Part G: 3. Pursuant to section 37AF of the Federal Court of Australia Act 1976 (Cth), and subject to any restrictions imposed by the Confidentiality Regime and/or the MSI Code Confidentiality Regime (as applicable), access to and disclosure (by publication or otherwise) of the unredacted versions of the documents identified as "confidential in part" in Part G of Annexure MAV-145 to Vincent #38 be restricted to the Respondents (and their experts) and the legal representatives of the Respondents, and those persons to whom access is allowed under the terms of the Confidentiality Regime. 4. Order 3 shall operate until 4 pm on the date that is three years after the final day of the trial on liability in this proceeding, or further order. Evidence 2246 There is only one document listed in Part G, C9.16, which Hytera asserts is confidential in part. 2247 The document is described as a 'picking slip' but in reality is a bundle of invoices. The invoices record information relating to sales of Hytera DMR products to Hytera's Australian distributor and dealers: Vincent-38 at §58. 2248 The information is confidential in part – Hytera proposes that the prices on the invoices be suppressed and that a copy with the prices redacted be filed. 2249 Hytera points to the value of pricing information to its competitors as the source of the commercial prejudice which it says it would suffer if the information were publicly disclosed: §60. Consideration 2250 I accept that pricing information is sensitive, especially at the distribution/dealership level because it can readily be used by competitors to determine advantageous discounts on their own products in order to entice distributors and dealers to purchase from them rather than Hytera. 2251 In general, I am reluctant to order suppression of information relating only to historical transactions. However, I accept that this pricing information will remain sensitive at least in the medium term and therefore that an order for the duration proposed by Hytera (three years post trial) is appropriate. Other Confidential Hytera Business Information (Part H of Annexure MAV-145) Proposed Order 2252 The proposed order set out under Part A covers Part E also. Evidence 2253 There are four documents in Part H, all of which Hytera asserts are confidential in full: CB 7.10A(a), CB 9.16, CB 9.18 and CB 9.19. 2254 This information is not said to be confidential because of its technical nature or its relevance to the digital security of Hytera's products. Rather, it is said to be confidential information pertaining to Hytera's business practices more broadly, including competitor analysis, business performance data, sales forecasts, product strategy and so forth. The information is said to be treated as confidential by Hytera and the prospect of its being disclosed is said to represent a risk to Hytera's competitive advantages: Vincent-38 at §64. Consideration 2255 The information contained in the Part H documents is akin to that contained in Motorola's Part D documents and it is appropriate that it be treated consistently. 2256 Having reviewed each of the four documents, notwithstanding that there are some portions which are not in English, it is clear that substantially all of the information they contain is commercially sensitive in the manner claimed. I therefore think it appropriate that the orders proposed by Hytera be made. Personal Information (Part I of Annexure MAV-145) Proposed Order 2257 Hytera seeks the following orders in respect of the documents listed in Part I: 5. Pursuant to section 37AF of the Federal Court of Australia Act 1976 (Cth), and subject to any restrictions imposed by the Confidentiality Regime and/or the MSI Code Confidentiality Regime (as applicable), access to and disclosure (by publication or otherwise) of the unredacted versions of the documents identified in Part I of Annexure MAV-145 to Vincent #38 be restricted to the Respondents (and their experts) and the legal representatives of the Respondents, and those persons to whom access is allowed under the terms of the Confidentiality Regime. 6. Order 5 shall operate until further order. Evidence 2258 The documents listed in Part I of Annexure MAV-145 are: Part I.1 – Human resources records and communications of a personal nature # Court Book Reference Confidentiality Claim (Full/Part) 114. CB C9.08 In part 115. CB C14.034 In part 116. CB C14.081 In part 117. CB C14.522 In part 118. CB C14.523 In part 119. CB C14.524 In part 120. CB C14.525 In part 121. CB C14.527 In part Part I.2 – Email addresses and telephone numbers of Hytera employees and third parties (All documents in Part I.2 are designated "confidential in part". Hytera seeks suppression orders restricting access to, and disclosure of, the email addresses and telephone numbers of current and former Hytera personnel and third parties contained in these documents). # Court Book Reference # Court Book Reference # Court Book Reference 122. CB C8.08 123. CB C8.09 124. CB C8.10 125. CB C8.12 126. CB C8.14 127. CB C8.20 128. CB C8.24 129. CB C8.25 130. CB C8.26 131. CB C8.27 132. CB C8.29 133. CB C13.02 134. CB C13.03 135. CB C13.04 136. CB C13.06 137. CB C13.09 138. CB C13.18 139. CB C13.19 140. CB C13.26 141. CB C13.28 142. CB C13.30 143. CB C13.31 144. CB C13.32 145. CB C13.33 146. CB C14.003 147. CB C14.004 148. CB C14.005 149. CB C14.007 150. CB C14.009 151. CB C14.011 152. CB C14.017 153. CB C14.019 154. CB C14.021 155. CB C14.023 156. CB C14.032 157. CB C14.037 158. CB C14.048 159. CB C14.049 160. CB C14.050 161. CB C14.051 162. CB C14.052 163. CB C14.053 164. CB C14.055 165. CB C14.057 166. CB C14.058 167. CB C14.059 168. CB C14.060 169. CB C14.061 170. CB C14.062 171. CB C14.063 172. CB C14.065 173. CB C14.067 174. CB C14.068 175. CB C14.069 176. CB C14.070 177. CB C14.071 178. CB C14.072 179. CB C14.073 180. CB C14.074 181. CB C14.075 182. CB C14.076 183. CB C14.077 184. CB C14.078 185. CB C14.082 186. CB C14.084 187. CB C14.087 188. CB C14.095 189. CB C14.128 190. CB C14.131 191. CB C14.133 192. CB C14.163 193. CB C14.164 194. CB C14.165 195. CB C14.166 196. CB C14.167 197. CB C14.168 198. CB C14.169 199. CB C14.170 200. CB C14.172 201. CB C14.173 202. CB C14.175 203. CB C14.176 204. CB C14.178 205. CB C14.179 206. CB C14.181 207. CB C14.182 208. CB C14.183 209. CB C14.184 210. CB C14.187 211. CB C14.196 212. CB C14.197 213. CB C14.201 214. CB C14.469 215. CB C14.539 216. CB C14.541 217. CB C14.542 218. CB C14.544 219. CB C14.545 220. CB C14.546 221. CB C14.547 222. CB C14.548 223. CB C14.550 224. CB C14.552 2259 Documents listed in Part I.1 contain personal information concerning current and former Hytera employees as well as some third parties: Vincent-38 at §66. Mr Vincent gave evidence on information and belief from Mr Zeping Duan, Hytera's in-house counsel, that Hytera is subject to various obligations in overseas jurisdictions, including China and the United Kingdom, concerning the maintenance of the privacy of this information: §§67-69. 2260 Documents in Part I.2 are said to be confidential in part. Hytera seeks orders suppressing certain information within them, principally in the nature of email addresses and phone numbers of current and former Hytera employees: §72. 2261 Hytera proposes that redacted copies of these documents be filed. Consideration 2262 As with the personal employee information the subject of the Motorola Application, I am satisfied that the orders sought by Hytera should be made. 2263 Having reviewed the proposed redactions for the documents in Part I.1, I consider that they are appropriate. 2264 The Court was not provided with proposed redactions for the (more numerous) set of documents listed in Part I.2. However, on the basis of Mr Vincent's evidence that what is proposed to be redacted is telephone numbers and email addresses, I am content with that course. 2265 Proposed order 6 provides for no self-executing expiry of proposed order 5. However, as with the equivalent documents in Part D of the Motorola Application, given the nature of the information (bolstered in this case by the fact that the orders apply to parts of the documents rather than the documents as a whole) I am satisfied that the orders are consistent with s 37AJ. Other Confidential Documents Filed with the Court (Part J of Annexure MAV-145) Proposed Order 2266 Hytera seeks the following orders over the documents listed in Part J: 7. Pursuant to section 37AF of the Federal Court of Australia Act 1976 (Cth), and subject to any restrictions imposed by the Confidentiality Regime and/or the MSI Code Confidentiality Regime (as applicable), access to and disclosure (by publication or otherwise) of the following documents is restricted to the Respondents (and their experts) and the legal representatives of the Respondents, and those persons to whom access is allowed under the terms of the Confidentiality Regime: (a). the documents identified as "confidential in full" in Part J of Annexure MAV-145 to Vincent #38); and (b). the unredacted versions of the documents identified as "confidential in part" in Part J of Annexure MAV-145 to Vincent #38. 8. Order 7 shall operate until further order. Documents 2267 There are two documents in Part J: Confidential Annexure CM-5 to the third affidavit of Chen Ma dated 21 January 2019, filed with the Court on the same date (in full); and Bundle of correspondence on issues before Justice Perram on 6 September 2018, being Sch 1, Pt 2 to the letter from MinterEllison to Herbert Smith Freehills dated 22 August 2018 (in part, page 30 only). Consideration 2268 The first document relates to order 2 of the orders I made on 28 November 2018. That order was in these terms: 2. If the Respondents intend to withhold or redact any documents on the basis of the Chinese State Secrets Law, by 25 January 2019, the Respondents are to file an affidavit given by Mr Chen Ma, or such other independent expert as is engaged by Hytera for the purpose of reviewing documents for State Secrets information, which: (a) verifies that, in the expert's opinion, one or more discoverable documents are subject to the Chinese State Secrets Law; (b) identifies the number (to the extent permissible under the Chinese State Secrets Law) of such documents; (c) explains (to the extent permissible under the Chinese State Secrets Law) the basis for that opinion; and (d) contains a log of each of those documents which includes date, author, and recipient information, as well as information sufficiently describing the contents of any material alleged to be subject to the Chinese State Secrets Law to allow it to be identified as such (to the extent permissible under the Chinese State Secrets Law). To the extent the expert considers that it is not permissible, under the Chinese State Secrets Law, to comply with any aspect of the requirements for this log in relation to any particular document(s), the expert must use best endeavours to explain the reason it is not permissible. 2269 CM-5 is a document withheld by Hytera for the reason mentioned in the order: Vincent-38 at §73. It was an exhibit to the third affidavit of Chen Ma. The document is titled 'State Secrets Document Log'. Hytera asserts that it is confidential because it identifies documents subject to the Chinese State Secrets Law and also because it contains the email addresses of Hytera employees: Vincent-38 at §73(a). 2270 I accept that a s 37AF order should be made in respect of this document. 2271 The second document contains a page, page 30, which Hytera says should be suppressed because it identifies and discloses metadata details of documents subject to a claim for legal professional privilege and also because it discloses the email addresses of Hytera employees: §73(b). I also accept that the order sought should be made in respect of this document. 2272 In each case, although the order is not expressed to be time-limited, I am satisfied that the duration is appropriate for the purposes of s 37AJ having regard to the nature of the information and the reasons for which it is suppressed, in particular the legal obligations necessitating the maintenance of its confidentiality. JOINT APPLICATION: EP LICENCE AGREEMENT BETWEEN MOTOROLA AND HYTERA Proposed Order 2273 The parties jointly seek the following orders: 1. Pursuant to section 37AF of the Federal Court of Australia Act 1976 (Cth), access to and disclosure (by publication or otherwise) of the following documents is restricted to the parties (and their experts) and the legal representatives of the parties, and those persons to whom access is allowed by the agreement of the parties: (a) the documents listed in Part 1 of Annexure A to these orders; and (b) the unredacted versions of the documents listed in Part 2 of Annexure A to these orders. 2. Order 1 shall operate until the earlier of the date on which the terms of the EP Licence (as that term is defined in the thirty eighth affidavit of Mark Andrew Vincent dated 30 June 2021) are publicly disclosed, or the date that is 3 years after the date on which the EP Licence ceases to be in force, or further order. 3. The parties have liberty to apply to the Court to extend the date referred to in Order 2 provided any such application is filed with the Court at least one month prior to its expiry. 4. Order 1 is made on the ground that it is necessary to prevent prejudice to the proper administration of justice. Documents 2274 Part 1 of Annexure A to the proposed orders lists these documents: Pleadings 1. Confidential Annexure A to Hytera's Seventh Further Amended Defence (CB C1.05(a)) 2. Confidential Annexure 1 to Motorola's Third Further Amended Reply (CB C1.06(a)) 3. Confidential Annexure A to Hytera's Second Further Amended Defence (CB 2.03(a)) 4. Confidential Annexure 1 to Motorola's Second Further Amended Reply (CB 2.04(a)) 5. Confidential Annexure 1 to Motorola's Reply dated 7 November 2017 6. Confidential Annexure 1 to Motorola's Amended Reply dated 11 December 2017 7. Confidential Annexure 1 to Motorola's Further Amended Reply dated 11 April 2019 8. Confidential Annexure A to Hytera's Defence dated 12 October 2017 9. Confidential Annexure A to Hytera's Amended Defence dated 20 October 2017 10. Confidential Annexure A to Hytera's Further Amended Defence dated 19 February 2019 11. Confidential Annexure A to Hytera's Third Further Amended Defence dated 18 December 2019 12. Confidential Annexure A to Hytera's Fourth Further Amended Defence dated 22 January 2020 13. Confidential Annexure A to Hytera's Fifth Further Amended Defence dated 5 June 2020 14. Confidential Annexure A to Hytera's Sixth Further Amended Defence dated 25 June 2020 Annexures to affidavit evidence 15. Confidential Annexures RKC-10 and RKC-11 to third affidavit of Robert Cooper dated 22 December 2017 and filed with the court on 28 December 2017 Exhibits and tenders 16. Tabs H.1 and H.2 of Hytera's Tender List (CB C14.463 and C14.464) 2275 Part 2 of Annexure A to the proposed orders lists these documents: Submissions 17. Hytera's Outline of Opening Submissions on Patent Issues (CB C2.04) 18. Motorola's Outline of Closing Submissions – Module I: Remaining Patent Issues (CB C02A.1) 19. Hytera's Outline of Closing Submissions – Module I: Patents (CB C02B.1). Evidence 2276 The information contained in these documents discloses, either directly or in summary form, the contents of the EP Licence Agreement between Motorola (initially its predecessor entity Motorola, Inc.) and Hytera. 2277 Both Ms Gilchrist on behalf of Motorola and Mr Vincent on behalf of Hytera gave evidence in support of the orders sought. 2278 Ms Gilchrist's evidence was to the following effect. 2279 First, Ms Gilchrist noted that the Court has previously considered the confidentiality of the terms of the EP Licence Agreement in the 2018 Suppression Order Reasons: Gilchrist-30 at §32. On that occasion, Hytera sought orders under s 37AF which would have applied to various documents disclosing the terms of the EP Licence Agreement, for a duration of 10 years. Motorola did not make a cognate application but supported the application by Hytera. I did not accede to Hytera's application but did make orders under s 37AF which applied for three years. I return to the significance of this below. 2280 Secondly, Ms Gilchrist gave evidence on information and belief from Mr Bartusiak that (§33): [Redacted]; [Redacted]; Motorola has other licence agreements with third parties each of which has different features and some of which include obligations to license essential IP rights on fair, reasonable and non-discriminatory ('FRAND') terms; and consequently, disclosure of the terms of the EP Licence Agreement while it remains in force will prejudice Motorola by impacting adversely its future licensing negotiations with third parties and, potentially, by creating disputes under existing licence agreements because of the FRAND obligations which those other agreements contain. 2281 Motorola estimates that the EP Licence Agreement is likely to remain in force for at least another 20 years, and likely much longer than that: Gilchrist-30 at §33(d). 2282 Mr Vincent's evidence on information and belief from Mr Duan was to the following effect. 2283 First, neither the EP Licence Agreement nor its terms have been publicly disclosed: §56(a). 2284 Secondly, disclosure would cause Hytera prejudice in future licensing negotiations with third parties because (§56(b)): third parties would know licence terms to which Hytera was prepared to agree including royalty rates that Hytera was prepared to pay; Hytera would not know corresponding information about those with whom it is negotiating; and this information asymmetry would put Hytera in a position of distinct competitive disadvantage in such negotiations. 2285 Thirdly, in Mr Duan's view, prejudice would be likely to accrue if the terms of the EP Licence Agreement were disclosed at any time while it remained in force: §57. This view was based on: the nature and lifespan of the DMR technology that is the subject of the agreement; the fact that the life cycle for a professional telecommunications standard can be more than 30 years; and the additional circumstances identified in Confidential Annexure RKC-11. This is an annexure to the third affidavit of Robert Cooper sworn 22 December 2017 in support of the application the subject of the 2018 Suppression Order Reasons. Seeing as it is one of the documents now sought to be suppressed, I will not set out its contents, but will observe that it is consistent with and offers further support for the matters in Mr Vincent's affidavit which I have just summarised. Consideration 2286 In the 2018 Suppression Order Reasons, I accepted Hytera's explanation of the confidentiality and commercial sensitivity of the terms of the EP Licence Agreement and the prejudice which would flow if orders under s 37AF were not made: [15]. I adhere to the views I expressed there. 2287 Owing to the progress of the litigation since the 2018 Suppression Order Reasons, a number of other documents have come into existence which reveal the terms of the EP Licence Agreement. This explains why the list of documents presently at issue is considerably longer than the list I set out at [4] of the 2018 Suppression Order Reasons. 2288 With respect to those documents that were not covered in the 2018 Suppression Order Reasons, I make three comments. 2289 First, items 1-14 are different versions of Confidential Annexure 1 to Motorola's reply and Confidential Annexure A to Hytera's defence. The confidential annexures contain a recitation, in direct or summary form, of the terms of the EP Licence Agreement. Items 5-14 are not in the court book and not otherwise before me, however, because these relate to earlier versions of the pleadings I infer that it was not thought necessary to include them in the court book (which was sensible given the number of amended versions of the pleadings). From a review of items 1-4, it appears that the only amendments made to Confidential Annexure 1 and Confidential Annexure A were to update the numerical references to the pleadings. For example, where Confidential Annexure A once referred to Hytera's 'fifth further amended defence', this was updated to refer to Hytera's 'sixth further amended defence'. On that basis, I am content to treat items 5-14 the same way as items 1-4 even though only the latter were before me on the present application. 2290 Secondly, the entire content of the two documents at item 16 (C14.463 and C14.464) comprises the terms of the EP Licence Agreement including amendments. 2291 Thirdly, in the case of the submissions at items 17-19, the parties seek orders that small portions of these which quote or paraphrase the terms of the EP Licence Agreement be suppressed. Having reviewed the proposed redactions in Annexure MAV-146 to Mr Vincent's affidavit, I consider that the proposed redactions are appropriate. 2292 I am therefore satisfied, as I was in 2018, that this information should be subject to orders under s 37AF. 2293 The more difficult question, again as it was in 2018, is the proposed duration of the order and the requirements of s 37AJ. 2294 At [16]-[18] of the 2018 Suppression Order Reasons I said that the evidence which Hytera put on in support of its then-application was insufficient to persuade me that a 10-year duration was appropriate. I instead made an order which ran for three years and indicated that it was open to the parties to seek a longer term at a future time. The Joint Application is the means by which the parties have now taken up that invitation. 2295 On that occasion, I identified two main problems with Hytera's evidence. First, there was no direct evidence of the nature and lifespan of the DMR technology covered by the EP Licence Agreement. Secondly, that there was no evidence in support of the proposition that the life cycle of a professional telecommunication standard, central to the agreement, is generally longer lasting than 30 years. I made these observations while noting that the fact that a proposed order is agreed is a relevant consideration on applications of this kind: citing Australian Broadcasting Commission v Parish (1980) 29 ALR 228 at 254 per Deane J; LHRC v Deputy Commissioner of Taxation (No 4) [2015] FCA 70; 326 ALR 150 at [25] per Perry J. 2296 In one respect, the evidence on the Joint Application is not improved: both Motorola and Hytera have chosen to lead evidence on information and belief rather than direct evidence. However, in important other respects, the evidence is more detailed and more persuasive than it was in 2018. In particular: both parties have cogently explained why the relevant risk of prejudice will continue to exist while the EP Licence Agreement remains in force, given the licence negotiation dynamics which obtain in the market and which involve third parties; and the duration of the licence is itself explained by the parties' shared expectation that the DMR technology to which it relates will continue to be commercially exploited for many years, indeed decades, and the licence is designed to operate for the life of extant patents (which confer up to 20-year monopolies) and to be capable of amendment to accommodate new patent rights which may be granted in future. 2297 Despite some renewed assurance on information and belief that professional telecommunications standards – like the one upon which the EP Licence Agreement is based – typically run for around 30 years, this evidence was again quite vague and I am not any more certain of the accuracy of that proposition than I was in 2018. However, given the matters just articulated, I am less troubled by this point. 2298 In the circumstances, I accept that it is reasonably necessary given the purpose for which the order is to be made that it apply for the life of the EP Licence Agreement plus a short additional period after it ceases to operate (unless its terms are earlier disclosed publicly in which case the order will expire at that time). However, I do not accept that a period of three years after the EP Licence Agreement ceases to operate is reasonably necessary. I consider that a one-year period is more appropriate as this is a reasonable time post-expiry for the parties to consider the position and come back before the Court with a renewed application if they wish for the suppression period to be extended. 2299 Accordingly, proposed order 2 of the Joint Application should be amended to read: Order 1 shall operate until the earlier of the date on which the terms of the EP Licence (as that term is defined in the thirty eighth affidavit of Mark Andrew Vincent dated 30 June 2021) are publicly disclosed, or the date that is 1 year after the date on which the EP Licence ceases to be in force, or further order. 2300 There is a final matter to note. In Part E of Annexure SMG-151 to Ms Gilchrist's affidavit, i.e. the Part that now relates to the Joint Application, there is a document listed which is not covered in the annexure to the proposed orders the subject of the Joint Application. This is the Consolidated Particulars to Paragraph 36 and Confidential Annexure A to Hytera's Seventh Further Amended Defence (CB C1.05(b)). Having reviewed that document, I cannot fathom why it was omitted from the jointly proposed orders. If this was a mistake, the parties may include it in the revised short minutes which I will require them to submit. 'OVERLAP' DOCUMENTS 2301 At the time of submitting the orders sought in each of the three applications, the parties drew to the Court's attention an issue concerning what they described as the 'overlap documents'. 2302 The overlap documents are so named because they are dealt with in both the Hytera Application and the Motorola Application. The parties are concerned to ensure that, if orders made pursuant to either of the applications are subsequently vacated, this will not affect the orders made pursuant to the other application which bear upon the same documents. 2303 The parties floated the idea of formulating a notation in each set of orders. Although I do not think a notation is strictly necessary – each set of orders will take effect according to its terms unless and until set aside, varied or vacated – I do consider that a notation will assist court staff, practitioners and the public to understand the relationship between the three applications and the effect of the orders the Court will make. 2304 As such, I will direct that the parties confer and formulate an agreed notation to be included in revised short minutes of order for each of the Hytera Application and Motorola Application. CONCLUSION AND DISPOSITION ON SUPPRESSION ORDER APPLICATIONS 2305 With respect to the Hytera Application, Hytera should submit a revised short minute of order which includes the agreed notation for the overlap documents. I will then make the orders sought. 2306 With respect to the Joint Application, the parties should confer and submit an agreed revised short minute of order giving effect to the above reasons. 2307 With respect to the Motorola Application, Motorola should submit a revised short minute of order giving effect to the above reasons which includes the agreed notation for the overlap documents and is accompanied by proposed redacted copies of the written submissions. XX FINAL MATTERS OUTLINE 2308 In this Chapter I deal with: (a) declaratory relief; (b) the tender of certain translations; (c) costs; (d) confidentiality orders; (e) the non-publication of the judgment and the preparation of a set of redacted reasons; (f) a further hearing on quantum and leave to appeal; and (g) the orders to be made. DECLARATORY RELIEF 2309 Neither party made submissions about declaratory relief. In principle, I accept that the declarations should be made in relation to the invalid patents. Apart from that I see little utility in any other declarations. The Court's conclusion will be apparent from the other forms of relief granted. TENDER OF TRANSLATIONS 2310 Motorola sought to tender translations of PTX-0422, PTX-0620 and PTX-2203. Hytera did not object to the tender: HCS(C) Mod III(Supp) at [90]. The translations will be admitted into evidence. COSTS 2311 In my view, given that an appeal is likely to be pursued, it would wasteful to enter upon the question of costs until the final outcome of the proceeding is known. However, if either party wishes to be heard on whether costs should be determined at this stage, this may discussed at the next case management hearing. I will fix a case management hearing for 9.30 am on 15 February 2023. CONFIDENTIALITY ORDERS 2312 I have dealt with these in the previous Chapter. Directions as there indicated should be included in the short minutes of orders. NON-PUBLICATION OF REASONS 2313 Prior to delivery of these reasons, I asked the parties to confer on appropriate orders limiting the publication of these reasons for judgment. They formulated a set of orders which I will include in the orders I will now make. FURTHER HEARING ON QUANTUM AND LEAVE TO APPEAL 2314 Both parties should have leave to appeal and, if necessary, leave to cross-appeal. If either or both exercise that entitlement, it would seem pointless to embark on the next question which is Motorola's election between remedies. However, if necessary I will hear the parties on the future course of the remedies proceedings. ORDERS 2315 Prior to the delivery of these reasons for judgment, I requested the parties to submit draft orders which would prevent their publication until such time as the parties had had an opportunity to consider whether parts of the reasons might need to be redacted. A set of orders were agreed between the parties which achieve that outcome. I have varied those orders to permit the first eight paragraphs (which do not contain any confidential information) to be made publicly available immediately. I will also order the parties to confer with a view to drafting a minute of order giving effect to the conclusions I have reached including in relation to confidentiality. Pending the outcome of that process, I have extended the interim confidentiality arrangements to 1 March 2023. I therefore make the orders which appear at the beginning of these reasons. I certify that the preceding two thousand three hundred and fifteen (2315) numbered paragraphs are a true copy of the Reasons for Judgment of the Honourable Justice Perram. Associate: Dated: 23 December 2022