TMA Capital Australia Pty Ltd v UbiPark Pty Ltd

INTRODUCTION 1 This is an appeal from the decisions of the primary judge in UbiPark Pty Ltd v TMA Capital Australia Pty Ltd (No 2) [2023] FCA 885 (J) and UbiPark Pty Ltd v TMA Capital Australia Pty Ltd (No 3) [2023] FCA 1079. The former decision contained the primary judge's substantive findings in the proceeding below while the latter dealt with the form of the final orders and costs. 2 These proceedings concern a patent for a system, method and computer program for controlling access to carparks. The first appellant (TMA Capital Australia Pty Ltd) is the registered owner of Australian Patent No. 2019213335 entitled "System, method and computer program for an access control system" (the Patent). The second (TMA Technology (Australia) Pty Ltd) and third (Zipby Pty Ltd) appellants are members of the same corporate group. We shall refer to the appellants together as TMA. 3 The respondent (UbiPark Pty Ltd) supplies a carpark entry system which allows entry and exit from a carpark (the UbiPark System), involving, amongst others, the use of a software application or "app" (the UbiPark App, or App) which the user of the carpark downloads and installs on their smartphone (collectively, the UbiPark Technology). 4 In the proceedings below, UbiPark commenced an unjustified threats action against TMA Capital. UbiPark was successful in obtaining an interlocutory injunction preventing TMA Capital from making threats. 5 For clarity, we note UbiPark initially commenced the proceedings below against TMA Capital. By a Notice of Cross-Claim filed 15 December 2021, TMA Capital, TMA Tech Pty Ltd and Zipby commenced a cross-claim against UbiPark and Mr Mosstyn Howell, the Chief Executive Officer of UbiPark. TMA's cross-claim alleged infringement of certain claims of the Patent, and contravention of s 18 of the Australian Consumer Law, being Sch 2 to the Competition and Consumer Act 2010 (Cth) (the ACL). The primary judge later granted leave on 7 June 2022 to substitute TMA Technology as the second cross-claimant, in place of TMA Tech Pty Ltd. Further his Honour made orders for TMA Technology and Zipby to be added as respondents to the main cause of action. 6 Subsequently, UbiPark amended its claim to include a revocation ground on the basis that the claims relied on in the infringement action were invalid. 7 The primary judge dismissed UbiPark's invalidity claim and TMA's infringement claims. The primary judge also dismissed the ACL claims as they depended upon the success of the infringement claims. His Honour further found the unjustified threats claim to be established against TMA Capital, but not against TMA Technology or Zipby. 8 TMA appeals from the infringement and ACL findings. TMA contends that the ACL findings follow the infringement result. UbiPark filed a Notice of Contention which raised a further construction issue and a pleading issue directed towards s 117 of the Patents Act 1990 (Cth). There was no challenge to the primary judge's findings on validity or the unjustified threats claim. 9 The appeal raises three principal issues of construction, which are identified in grounds 1 and 2 of the Notice of Appeal. The primary judge resolved those issues of construction by reference to claim 1 of the Patent. 10 The integers of claim 1 were reproduced at J[12] and are again reproduced here for convenience. Claim 1 is an independent claim to a "system" and is as follows (with integer numbers added): 1. A system including: [1.1] a communication system; and [1.2] a computer program executable by a mobile communication device associated with an entity, the entity being a user which is associated with a vehicle for parking within a restricted area, the restricted area being a vehicular parking area, [1.3] wherein the mobile communication device is configured to: [1.3.1] receive one or more entry signals from the communication system when the entity approaches an entry point of a restricted area; [1.3.2] determine a received signal strength of the one or more entry signals; [1.3.3] determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request; [1.3.4] in response to the one or more entry criteria being satisfied, generate and transfer, to the communication system, the entry request; [1.3.5] receive, from the communication system, authorisation data indicative of the entity being granted access to enter the restricted area by an access control system; [1.3.6] receive one or more exit signals from the communication system when the entity approaches an exit point of the restricted area; [1.3.7] determine a received signal strength of the one or more exit signals; [1.3.8] determine if one or more exit criteria have been satisfied based on the received signal strength of the one or more exit signals in order to generate and transfer an exit request; and [1.3.9] in response to the one or more exit criteria being satisfied, generate and transfer, to the communication system the exit request indicative of the authorisation data in order to exit the restricted area. 11 Integers 1.3.1 to 1.3.5 relate to the procedure for entering the carpark, whilst integers 1.3.6 to 1.3.9 relate to the procedure for exiting the carpark. There is a degree of overlap between the entry and exit set of integers, such that in most cases, the construction of an entry integer will apply to the corresponding exit integer. These reasons will focus on the entry set of integers, unless it is noted otherwise. 12 Claims 11 and 16 are independent claims to a "computer program" and a "mobile communication device", but they are otherwise in substantially the same form as claim 1. Claim 4 was not pressed at the appeal hearing.

GROUNDS OF APPEAL AND CONTENTION 13 The three construction issues on appeal overlap with the construction issues at trial. The primary judge summarised the three main construction issues in relation to claim 1 at J[13]: (a) The first issue relates to integers 1.3.3 and 1.3.8, but it is bound up with the parties' contentions relating to integers 1.3.1, 1.3.2, 1.3.6 and 1.3.7. The contentions of each party are, in summary: (i) The TMA parties contend that a mobile communication device (which I will refer to as a "smartphone" for ease of expression, but which is not limited to a smartphone) "receives" entry signals from the communication system within the meaning of integer 1.3.1 at the time the signal impinges on the smartphone's radio antenna, whether or not the signal is strong enough to be decoded. In relation to integer 1.3.2, the TMA parties contend that a received signal strength can be "determined" directly (by measuring the power level of the signal) or indirectly (by detecting the presence of valid communicated data modulated onto the radio frequency of the signal by the beacon, which is decoded by the radio receiver). The TMA parties contend that integer 1.3.3 requires that the received signal strength of the entry signal is used in some way to determine whether a condition of entry to the car park is satisfied. Corresponding submissions are made for integers 1.3.6, 1.3.7 and 1.3.8. (ii) UbiPark contends that integer 1.3.1 means that the user's smartphone picks up a signal that it is able to read information from, and that it is able to recognise comes from a beacon located at the entry of a relevant car park (the entry signal). UbiPark contends that integer 1.3.2 requires that the smartphone measures the strength of the signal from that entry beacon. UbiPark contends that integer 1.3.3 requires that the user's smartphone performs a comparison against one or more criteria of the received signal strength that the smartphone's receiver measures for the entry signal, or some calculation based on that measured value. Corresponding submissions are made for integers 1.3.6, 1.3.7 and 1.3.8. (b) The second issue relates to integers 1.3.4 and 1.3.9. The TMA parties contend that integer 1.3.4 may be satisfied, whether the request is transferred automatically (that is, without any user interaction with their smartphone) or upon user interaction with their smartphone (for example, a user tapping on a button on the smartphone's screen). UbiPark contends that integer 1.3.4 means that, if and when the criteria in integer 1.3.3 are satisfied, such that it can be inferred that the user's vehicle is in position at the front of the queue for the relevant barrier, the smartphone sends an entry request for that barrier to be opened. (c) The third issue relates to integers 1.3.5 and 1.3.9. The TMA parties contend that "authorisation data" is data that is indicative of the fact that the access control system has granted the entity access to the restricted area; the specification describes "authorisation data" as fulfilling the role of a "virtual ticket" that is stored on the user's smartphone. In relation to integer 1.3.9, the TMA parties contend that by being "indicative of" the "authorisation data", it is not necessary for the exit request to contain the data or elements of it; it is sufficient if the exit request corresponds with the authorisation data in some way. UbiPark contends that the "authorisation data" referred to in integer 1.3.5 need not specifically identify the user, but it must be specific to that particular user's parking session, as would be the case for a paper ticket; that is, it must be a unique identifier. 14 By its first ground of appeal, TMA contends the primary judge erred in construing the phrases "determine a received signal strength of the one or more entry signals" and "determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request" as used in integers 1.3.2 and 1.3.3 of claim 1 of the Patent. By its second ground, TMA contends the primary judge erred in construing the phrase "in response to the one or more entry criteria being satisfied, generate and transfer, to the communication system, the entry request" as used in integer 1.3.4 of claim 1. Issues (a) and (b) at [12] above correspond to appeal grounds one and two. 15 By its first ground of contention, UbiPark contends that the primary judge ought to have found that the use of the UbiPark App did not involve use of "authorisation data", as required by integers 1.3.5 and 1.3.9 of claim 1 (and the corresponding integers of claims 11 and 16). Issue (c) at [12] above corresponds to the first ground of contention. 16 By its second ground of contention, UbiPark contends that integer 1.3.5 is not present in the UbiPark Technology. 17 The third ground of appeal challenges the primary judge's finding that integers 1.3.3, 1.3.4 and 1.3.9 of claim 1 were not present in the UbiPark Technology. TMA contends that on the construction of those integers propounded by it, those integers are present in the UbiPark Technology. TMA further contends that even on the primary judge's construction of integer 1.3.3, that integer is present in the UbiPark Technology. 18 The fourth ground of appeal challenges the primary judge's findings that claims 11 and 16 were not infringed as the integers of those claims corresponding to integers 1.3.3, 1.3.4 and 1.3.9 were not present in the UbiPark Technology. 19 The fifth ground of appeal challenges the primary judge's dismissal of the ACL claim. TMA contends that success on the ACL claim follows success on the infringement claim. 20 The third ground of contention challenges the adequacy/sufficiency of TMA's pleading of its direct infringement case and its indirect infringement case based on s 117(2)(b) of the Act.

THE PATENT 21 The Patent is directed to a method of facilitating entry into and exit from a secured area, in particular a carpark. The primary judge described the Patent in detail at J[17]−[39]. 22 The Background section of the Patent discusses the "numerous" problems associated with existing physical ticketing systems for carparks. The invention described and claimed in the Patent is intended to alleviate one or more of the problems described. These problems include some drivers finding it difficult to collect the ticket from the ticket machine at the entry point or insert a ticket for reading with the ticket reader at the exit point without exiting the vehicle; drivers being distracted whilst attempting to hold or find the ticket while driving within the parking station which may result in accidents. Furthermore, if the ticket is lost the driver is generally required to pay full fare in order to exit the parking station. Additionally, at busy times, there can be a significant queue at the ticket machines due to time spent by the driver collecting and inserting the ticket. 23 The Patent also discusses similar problems of driver distraction and queuing associated with access control systems to residential or commercial building carparks which utilise hand operated radio transmitters or proximity cards. There is also often a delay involved in ordering new transmitters or cards for new carpark users, and delay resulting from users trying to find the transmitter or card in their bag or wallet. 24 The broadest description of the invention is found in the first broad aspect of the system invention set out at [0009] under the heading "Summary". That embodiment relates to access to a restricted area and is not limited to vehicle carparks. Embodiments of the first aspect are described from [0010] to [0021]. In certain embodiments, discussed at [0021], the mobile communication device is said to be configured to automatically transfer at least one of the entry request and the exit request without user interaction (emphasis added). TMA contrast the description of this embodiment with that of the broader embodiment in [0009] which does not include such a limitation in their argument in relation to their second ground of appeal. 25 The Detailed Description of Example Embodiments commences at [0048] and continues to [00142]. The "virtual ticketing system" ([0057]) can include an app ("computer program" at [0059]) that runs on a smartphone ("mobile communication device" at [0059]) that then interacts with the "access control system" for the carpark. 26 TMA took the Court to the embodiments described at [0060], [00108] and [00141] which they submitted were embodiments where some form of user intervention prior to the generation of the entry/exit request was contemplated. They submitted that whilst a preference was expressed for no user intervention, that was a preference, not a requirement. TMA contended that the existence of embodiments which contemplated user intervention favoured a broader construction of integer 1.3.4, than was adopted by the primary judge. 27 The specification has 15 figures and ends with 20 claims; of which claims 1, 11 (a computer program, or app), and 16 (a mobile communication device, or smartphone) are independent claims. 28 Both parties made reference to claim 10 in their arguments as to the construction of integer 1.3.4. Claim 10 is as follows: The system according to any one of claims 1 to 9, wherein the mobile communication device is configured to automatically transfer at least one of the entry request and the exit request without user interaction.

COMMON GENERAL KNOWLEDGE 29 The primary judge set out his findings as to common general knowledge at J[67], which was based on the evidence of Mr Geoffrey Sizer, TMA's independent expert witness. This included the concepts of received signal strength indicator (RSSI) and decoding, both of which were relevant to the construction arguments. 30 The RSSI value is determined by the radio receiver hardware on the smartphone. The smartphone will be able to determine the RSSI value, but that value has no meaning if the smartphone does not know the nature of the source of the signal. Accordingly, the RSSI value only has meaning after the decoding process has occurred: J[67(g)]. 31 The scale to measure signal strength (eg, RSSI) is decibels relative to a milliwatt (dBm). The signals are extremely low amounts of energy, below a microwatt. Very low levels of energy are sufficient to be able to receive and decode the signal: J[67(h)]. Mr Sizer's evidence was that dBm is a logarithmic scale (from -100 to zero) and because the signals are relatively weak, the RSSI values are always negative numbers, in other words, less than zero. The stronger the signal, the closer the value is to zero: J[120(b)]. As the distance between the transmitter and the receiver increases, the strength or power of the signal decreases. Under perfect conditions the decrease would be inversely proportional to the distance squared. 32 Decoding is a product of the rules of Bluetooth signal transmission. It means that a pattern of digital bits is derived from the signal. The pattern of bits must meet certain rules in terms of being a valid Bluetooth signal. The decoding process includes an error-checking process. If the decoding process determines that the signal is not strong enough to be error free, it will reject it as a signal and it will not relay that signal to the other sections of the software: J[67(i)]. 33 Each Bluetooth transmission source (or beacon) has a unique identifier (UUID) that is encoded and associated with the Bluetooth transmission signal from that source: J[67(j)].

PRIMARY JUDGE'S CONSTRUCTION 34 There was no criticism of the principles of construction set out by the primary judge at J[55]−[63], nor his identification of the person skilled in the art at J[66] or his findings as to the relevant common general knowledge at J[67]. 35 It was not suggested that any of the words in the integers in dispute were other than ordinary English words. None had a technical meaning or a special or unusual meaning in the area of technology that is the subject of the Patent.

5.1 Integer 1.3.3 36 The primary judge commenced his consideration of integer 1.3.3 with the construction of the two preceding integers, commencing with integer 1.3.1, and noted at J[105] that the experts disagreed in their joint report about the meaning of the word "receive" in that integer. His Honour observed that the difference between the experts was not as to technical matters, but rather as to what aspects of the process amount to receiving an entry signal within the meaning of claim 1. The primary judge summarised the experts' oral evidence that emerged during the concurrent session at J[107]. Ultimately, at J[108], the primary judge construed "receive one or more entry signals" in integer 1.3.1 as requiring that the entry signal (eg, a Bluetooth signal from a beacon) is received by the smartphone when it impinges on the device and influences it in a perceptible way. 37 The primary judge then moved to consider integer 1.3.2, noting at J[109] that it was common ground between the experts that the integer encompasses (at least) a smartphone measuring the strength of an entry or exit signal that has been received (eg, measuring the RSSI of a Bluetooth signal). The difference between the experts was whether the integer also encompasses the ability to correctly decode a Bluetooth signal. 38 After summarising the experts' evidence in the concurrent session, the primary judge deferred the construction of integer 1.3.2 until after he had considered the evidence relating to integer 1.3.3: J[111]. 39 At J[113], the primary judge construed both integers in the following manner: (a) integer 1.3.2 encompasses measuring the strength of an entry signal that has been received (eg, measuring the RSSI of a Bluetooth signal); it does not also encompass the ability of a smartphone to correctly decode a received signal (thereby determining that the strength of the signal is at or above a threshold value for the smartphone to be able to correctly decode it); and (b) integer 1.3.3 requires a comparison to be made between one or more entry criteria and the received signal strength that the smartphone measures for the entry signal, or some calculation to be undertaken based on that measured value; it is not sufficient that the smartphone merely uses the received signal strength in some way to determine whether a condition of entry to the carpark is satisfied. 40 The primary judge explained his construction at J[114] as follows: I consider that the construction of these integers set out above accords with the ordinary meaning of the words used in the integers, having regard to their context. The ordinary meaning of the words "determine a received signal strength of the one or more entry signals" is measuring the strength of the signal. The words do not naturally convey the ability to correctly decode the signal and thus indirectly determine that the signal strength is sufficient to enable correct decoding. Further, the ordinary meaning of the words "determine if one or more entry criteria have been satisfied based on the received signal strength …" is that set out above. The words do not naturally convey merely using the received signal strength in some way to determine whether a condition of entry to the car park is satisfied. Further, the construction of these integers set out above is consistent with, and furthers, the purpose of the invention, which is generally directed to determining when the user's car is in the correct position for the entry barrier to open. Measuring the strength of an entry signal (eg, the RSSI value in the case of a Bluetooth signal) assists in achieving this objective. On the other hand, determining that the entry signal is able to be correctly decoded (which indicates that the signal is strong enough to be correctly decoded) provides only limited assistance in meeting that objective. As Mr Sizer accepted, various factors, in practical terms, could translate to quite different distances for two different individuals, in terms of how far away they may be when their smartphone can decode the signal. 41 At J[115], the primary judge observed that the construction he had adopted for integers 1.3.2 and 1.3.3 involved an acceptance of UbiPark's position and that his construction did not correspond with the views of either expert.

5.2 Integer 1.3.4 42 The primary judge commenced his consideration of integer 1.3.4 by observing at J[133] that the experts agreed that insofar as the integer refers to what happens if the entry criteria are satisfied, it means that the entry request is transferred to the communication system by the smartphone subject to the one or more entry criteria being satisfied. Beyond that, the experts disagreed as to the construction of the integer. 43 After summarising the evidence that emerged during the experts' concurrent session, the primary judge at J[135] construed integer 1.3.4 to mean that, if and when the one or more entry criteria referred to in integer 1.3.3 have been satisfied, the smartphone sends an entry request for the barrier to be opened. His Honour rejected TMA's contention that integer 1.3.4 is satisfied both in circumstances where the entry request is transferred automatically (that is, without any user interaction with their smartphone) and in circumstances where there is user interaction with their smartphone (for example, a user tapping on a button on the smartphone's screen). 44 The primary judge explained at J[137] that the words of the integer are to be read in context. The context includes parts of the specification that suggest that the invention is not limited to an automated system: see [0021] (set out at J[22]), [0060] (set out at J[25]), [00108] (set out at J[30]) and [00141] (set out at J[33]). His Honour noted that that the focus of the specification generally is on methods for analysing the strength of the signal from the entry/exit beacon or beacons in order to determine when to send the entry/exit request to open the barrier, without the need for the user to interact with their smartphone. 45 The primary judge continued that the context also includes claim 10 (set out at [28] above). Claim 10 is a dependent claim that adds an integer or requirement that the smartphone is configured "to automatically transfer at least one of the entry request and the exit request without user interaction". The primary judge considered that the clear implication from claim 10 is that claims 1 to 9 are not limited to the automatic transfer of an entry request and exit request; otherwise, claim 10 would add nothing. Whilst observing "[t]his strongly suggests that some form of user interaction is within the scope of claims 1 to 9", the primary judge explained that, reading the words of the integer in context, he was unable to see how the words "in response to" can bear the meaning proposed by TMA. According to the primary judge, the words "in response to" in integer 1.3.4 requite a direct relationship between: (a) satisfaction of the one or more entry criteria referred to in integer 1.3.3; and (b) the generation and transfer of the entry request. 46 The primary judge gave as an example, where there is a sequence of steps (A, B and C) and each step in the sequence is required to occur before an event (D) happens, the event (D) happens "in response to" the last step in the sequence (C) or the whole series of steps in the sequence (A, B and C); the event (D) does not happen "in response to" the penultimate step in the sequence (B). In this example, satisfaction of step B will not necessarily lead to the event (D) happening. If step C does not also occur, the event (D) will not happen. Applying the logic of that example to the present case, in circumstances where an entry request will only be transferred if (a) there is satisfaction of the one or more entry criteria referred to in integer 1.3.3 and (b) the user presses a button on the screen of their smartphone, the entry request is generated and transferred "in response to" the user pressing the button on their smartphone; it is not generated and transferred "in response to" satisfaction of the one or more entry criteria. If the criteria are satisfied, but the user does not press the button, the entry request will not be generated and transferred. 47 The primary judge acknowledged at J[139] that his construction appeared to produce redundancy in respect of claim 10. However, in his Honour's opinion, the matters he referred to at J[138] were "so strong that they outweigh that consideration".

5.3 Integers 1.3.5 and 1.3.9 48 The primary judge noted at J[149] that TMA's expert, Mr Sizer, had set out two possible interpretations of the words "indicative of the entity being granted access to enter the restricted area by an access control system" (when considered in isolation from the remainder of claim 1). These were: (a) The first interpretation is that the authorisation data is indicative of the fact that the access control system has granted the entity access to the restricted area. In other words, the authorisation data is a sign that the entity has been permitted entry to the restricted area. (b) The second interpretation is that the authorisation data is indicative of the entity, by being related to the entity in some way. In other words, the authorisation data is a sign that the entity exists, or perhaps of who they are. 49 The experts agreed that the first interpretation is a valid interpretation of integer 1.3.5, in that it allows for the provision of a "virtual ticket" as described in the Patent at [0062]. The experts disagreed as to whether the second interpretation was a valid interpretation for the purposes of integer 1.3.5. 50 At J[153], the primary judge considered that the first interpretation should be accepted and the second rejected, on the basis that the first interpretation accords with the ordinary meaning of the words, read in context, while the second did not. The primary judge found that properly construed, the words "indicative of the entity being granted access to enter the restricted area by an access control system" in integer 1.3.5 mean that the authorisation data is indicative of the fact that the access control system has granted the entity access to the restricted area. His Honour noted that the authorisation data is indicative of the entity "being granted access", as distinct from having prior approval to enter the carpark. 51 The primary judge then turned to construe the words "indicative of the authorisation data" in integer 1.3.9. At J[155], the primary judge construed those words to mean that the exit request corresponds in some way with the authorisation data that is indicative of the entity being granted access to enter the restricted area. This construction accorded with the experts' construction.

THE UBIPARK TECHNOLOGY 52 The primary judge's description of the UbiPark Technology set out at J[79]−[101] was largely based on the description provided by Mr William Van De Camp, UbiPark's Chief Technology Officer, supplemented to some extent by the evidence of TMA's expert, Mr Sizer. The UbiPark Technology includes the UbiPark servers, the UbiPark App on a user's smartphone, and at least one Bluetooth beacon at each of the entry and exit lanes of a carpark utilising the UbiPark Technology. 53 The primary judge was satisfied that integers 1.3.1 and 1.3.2 were present in UbiPark's Technology for the reason set out at J[126]. The primary judge was not satisfied that the remaining integers were present for the reasons set out below. 54 At J[121], the primary judge observed that the experts agreed that the UbiPark Technology makes use of the received signal strength of entry/exit signals from Bluetooth beacons, in determining whether a user is permitted to enter/exit the carpark. His Honour noted that the experts were unable to agree about where the determination (of whether the entry criteria are satisfied) occurs: the smartphone or the UbiPark servers. The primary judge then summarised the evidence on that issue, and at J[122], the points that emerged from the concurrent evidence session. Relevantly, at J[123], the primary judge summarised the evidence as follows: (a) For all car parks, it is a necessary part of the process that the UbiPark App is able to correctly decode a signal received from a Bluetooth beacon located at a UbiPark Car Park. This is implicit in the fact that, as set out in the outline of UbiPark's technology, signal is being received; and, each time the app receives a Bluetooth signal with a new UUID, it sends that new UUID to the UbiPark servers. (b) For all car parks, the UbiPark App carries out a "closest lane" calculation based on the RSSI values of the signals that have been received from the Bluetooth beacons at the car park; it is an implicit prerequisite to this calculation that the smartphone has received at least one signal for which there is an RSSI value (which, in practice, will always be less than zero); if the "closest lane" calculation cannot be performed, the process will not continue. (c) Where the Detection Type is set to "Closest" (that is, the configuration for the Perth Airport car park and the Adelaide car park trial), the closest lane (as so calculated) will be displayed on the entry message screen. Where the Detection Type is set to "All" (i.e. all other car parks), the entry message screen will display all entry lanes for the car park; in this situation, the calculation of the closest lane referred to in (b) above has no practical role beyond allowing the process to continue. (d) The Min RSSI field is blank for all car parks and defaults to zero. The UbiPark technology (I will assume, the UbiPark App) performs a test of whether the measured value of the RSSI is equal to or greater than the Min RSSI. In practice, the measured RSSI value will always be less than zero, therefore this test will never be passed. However, this does not stop the process from continuing. This is because the entry message screen will be displayed after the number of seconds set for Min Detection Secs (usually only a few seconds). (e) It follows from (d), that the UbiPark technology, as implemented in practice, does not involve a comparison between a predetermined minimum RSSI value (eg, -70 dBm) and the measured RSSI value to determine whether the measured value exceeds the stipulated minimum.

6.1 Integer 1.3.3 (and 1.3.8) 55 The primary judge was not satisfied that all the elements of integer 1.3.3 were present in the UbiPark Technology. His Honour explained his reasons for this finding from J[125], commencing by noting that he would proceed on the basis that it is not necessary for the "computer program" (here, the UbiPark App) to configure the smartphone to do the things referred to in integers 1.3.1, 1.3.2 and 1.3.3, because this raises an issue of construction that was not the subject of complete argument at the hearing. 56 In particular, at J[126], the primary judge was not satisfied that the smartphone is configured to "determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals in order to generate and transfer an entry request" (integer 1.3.3). This would be the case if, for example, the Min RSSI field was set to a predetermined negative number and the process involved checking whether the measured RSSI was greater than that number. However, for all carparks, that field is left blank and defaults to zero. This means that the minimum RSSI test that is carried out will never be passed. Further, that test has no practical consequence as the entry message screen will be displayed after the time set for "Min Detection Secs", which represents the duration in seconds that the UbiPark App will wait before displaying a lane selection screen, (usually, a few seconds) has elapsed. 57 The primary judge did not consider that the ability of the smartphone to correctly decode the entry signal (while a necessary step in the process used by the UbiPark Technology) constituted determining the received signal strength of the entry signal; nor does it involve determining if one or more entry criteria have been satisfied based on the received signal strength: J[129]. 58 In response to TMA's contention that of the entry beacons associated with a lane, at least one beacon must have an RSSI value of less than zero, the primary judge observed at J[130] that: …while it is necessary for there to be a value for RSSI that is less than zero for the "closest lane" calculation to be carried out, and that calculation must be performed for the process to continue, it is artificial to regard the existence of a value for RSSI that is less than zero as an entry criterion. In substance, the UbiPark App is using the RSSI value (or values) to calculate which lane is the closest lane. While this test cannot be performed unless there is an RSSI value (which, if it exists, will always be less than zero), the existence of a value for RSSI is merely a prerequisite to the conduct of a calculation directed to determination of the closest lane. Putting this another way, the calculation uses the RSSI value as a closest lane criterion rather than as an entry criterion. 59 At J[131], the primary judge further observed that: …while the "Min RSSI" test could theoretically constitute a determination of whether one or more entry criteria have been satisfied "based on the received signal strength" (for the reasons set out above), in practice the "Min RSSI" field is left blank for all car parks and defaults to zero. It therefore does not operate as such a test.… I am not satisfied that the "Max Detection Secs" test involves a determination "based on the received signal strength" of the one or more entry signals. The test essentially involves the passing of a period of time (usually, a few seconds). It is not concerned with the received signal strength (albeit that a signal needs to have been recently received and decoded).

6.2 Integer 1.3.4 (and 1.3.9) 60 In considering whether integer 1.3.4 was present in the UbiPark Technology, the primary judge proceeded on the basis that the request to enter that is sent by the UbiPark App to the UbiPark servers constitutes an "entry request", and similarly, the request to exit sent by the UbiPark App constitutes an "exit request". The primary judge found that the integer (and the corresponding "in response" part of integer 1.3.9) was not present, noting at J[146] that: It is clear from the outline of Ubi Park's technology (set out above) that, in all cases, the user must press a button on the entry message screen before an entry request is sent by the UbiPark App to the UbiPark servers. If the user does not press the button, the entry request is not sent. In these circumstances, the entry request is sent "in response to" the user pressing the button; it is not sent "in response to" the one or more entry criteria referred to in integer 1.3.3 being satisfied. This conclusion follows largely, if not wholly, from my conclusion on the construction issue regarding integer 1.3.4.

6.3 Integer 1.3.5 (and 1.3.9) 61 At J[159], the primary judge held that integer 1.3.5 was present in the UbiPark Technology observing that: … The response from the UbiPark servers includes a Boolean field (true or false) and the "appSettings.InCarPark" data element is set directly from this response. I consider that the response from the UbiPark servers constitutes "authorisation data indicative of the entity being granted access to enter the restricted area". While the response is merely a Boolean field and does not contain information that is specific to the user or the parking session, it is sent in response to a request from the user's smartphone for the user's current status (i.e. whether or not they are in the car park). In this context, I consider that the information constitutes authorisation data indicative of the user having been granted access to enter the car park. In some senses, it functions as a virtual ticket for that user; it indicates that they have been granted access to enter the car park. 62 The primary judge then turned to whether the "authorisation data" part of integer 1.3.9 was present in the UbiPark Technology, noting at J[161] that the experts were unable to agree whether the exit request in the UbiPark Technology was "indicative of authorisation data". His Honour concluded at J[163] that the exit request was "indicative of authorisation data" for the purposes of integer 1.3.9 noting that: … Although the exit request does not contain data that is specific to the user or the parking session, the exit request will not be sent unless the "appSettings.InCarPark" data element has the value "true". In these circumstances, in my opinion, the exit request is indicative of (corresponds in some way with) the authorisation data (namely, the Boolean information previously provided by the UbiPark servers to the UbiPark App). It is not necessary for the entry request to contain the authorisation data or elements of it.

7.1 Appeal ground 1 - construction - integers 1.3.2 and 1.3.3 63 TMA challenges the primary judge's construction of the phrases containing the word "determine" in integers 1.3.2 (determine a received signal strength of the one or more entry signals) and 1.3.3 (determine if one or more entry criteria have been satisfied based on signal strength), and the corresponding phrases in integers 1.3.7 and 1.3.8. Although the primary judge found that integer 1.3.2 was present in the UbiPark Technology, TMA contends that his Honour's construction of the integer infected his construction of integer 1.3.3. 64 Commencing with integer 1.3.2, TMA submits that the construction adopted by the primary judge of the phrase "determine a received signal strength of the one or more entry signals" at J[113(a)] and [114] as involving measuring the strength of the signal did not correspond with the views of either of the experts. That fact was expressly acknowledged by the primary judge in his consideration. 65 TMA describes the primary judge's construction as "overly narrow", "not reflective of the proper characterisation of the features of the integers" and "impermissibly importing a gloss on the meaning of the integer". TMA contends that the integer should include the determination of RSSI by indirect means (such the received signal being of sufficient strength to decode) and direct means (measurement of signal strength). 66 TMA correctly accepts that the primary judge was not required to adopt the experts' constructions but submits that the experts' constructions are a powerful indicator in support of the construction propounded by them. TMA maintains that the language of the Patent was to be construed from the perspective of a person skilled in the relevant art, and the common views expressed by the two experts were significant in this regard. 67 TMA relies on the ordinary meaning of "determine" which is not "measure". Both parties agreed the relevant definition is "to ascertain after reasoning or observation": Macquarie Dictionary (online). TMA contends that the distinction is important. A "received signal strength" of an entry (or exit) signal can be determined (or ascertained) without any direct measurement of its power. It can be determined indirectly by the fact that the signal can be successfully decoded, meaning that the signal is at or above a threshold value: J[109(a)]. The Patent does not place constraints on or restrict the method used to "determine" the received signal strength in accordance with the claim. According to TMA, claim 1 requires the determination of a received signal strength, not the measurement of a received signal strength. 68 TMA submits the primary judge effectively substituted the word "measure" for "determine", and that properly construed this integer encompasses both indirect and direct determination of signal strength.

7.2 Consideration 69 It was common ground between the experts that integer 1.3.2 encompassed (at least) a smartphone measuring the strength (power level) of an entry or exit signal that has been received. Typically, this is referred to as the RSSI, which is made available to the software as a numerical value. It was a matter of common general knowledge at the priority date that smartphones have built in ability to measure the RSSI: J[67(b)] and J[67(g)]. 70 TMA's contention that "determine" in this integer includes indirect determination (via decoding) assumes that there is a threshold value above which the signal can be decoded by a smartphone. Decoding the signal above a threshold value provides a de facto determination of received signal strength, without the measurement of any RSSI value. However, there was evidence that the signal strength at which a particular smartphone might decode an entry signal can be impacted by the sensitivity of the particular smartphone's antenna (whether it is a new or old smartphone) and to a lesser extent by the levels of surrounding "noise" or interference from similar frequencies and by weather conditions. 71 The practical significance of a "threshold value" for a specific phone would be of limited utility. Mr Sizer accepted that various factors (such as differences in the sensitivities of receivers, the physical environment around the phone, location of the smartphone within the user's car, whether or not there is a line of sight), in practical terms, could translate to quite different distances for two different individuals, in terms of how far away they may be when their smartphone can decode the signal: J[110(c)]. Each of these factors will impact the distance at which a particular smartphone may become capable of decoding the entry signal. Consequently, for a given smartphone at a given carpark, the point at which the "entry signal" is decoded will not correspond with any "prescribed range of locations" within that carpark, or in relation to a barrier or barriers. 72 There is nothing in the specification that links determining the signal strength with working out when the signal can be decoded. TMA did not take us to any part of the specification which supported their broader construction. There are clear indications in the specification that the patentee did not intend such a broad construction. The description of the broadest aspect of the invention at [0009] refers to the mobile communication device being configured to "receive" one or more entry signals, and requiring that an entry request be generated in response to "receiving at least some of the one or more entry signals". "Receive" does not suggest decoding of the signal. 73 The specification at [0064] and [0073] refers to the varying signal receiving characteristics of a wide variety of mobile communications devices, and a variety of locations of the smartphone within the vehicle that can impact upon the received signal strength, noting that "in some instances it may not be possible to predefine the entry criteria … solely dependent upon a predefined threshold received signal strength". 74 During oral submissions, UbiPark's senior counsel gave several examples of "determine" being used in the sense of "measure", including "determining" the speed of a vehicle, the height of a building or the length of a desk. Whilst the height of a building might be able to be measured directly, it could also be measured indirectly as part of the side of a triangle, each "determination" resulting in a numerical value. In contrast, the height of a building is not "determined" by observing that it is taller than another building. 75 Mr Howard Elliott, UbiPark's independent expert witness, considered that in the context of the Patent, "signal strength" is inferred to be a numerical value not a Boolean measure (true/false). The Patent describes using the "received signal strength" to determine other values such as scaled power values (at [0026], [0074], [0077] and [000126]) which are clearly numeric: J[109(b)]. 76 TMA's construction of "determine" results in a binary, rather than a numerical result; the signal can be decoded, or it cannot. We agree with the primary judge that integer 1.3.2 requires the measurement of the received signal strength, in the sense of measuring a numerical value, rather than the indirect determination, via the ability of the smartphone to decode the signal (ie, that the signal strength is above a certain threshold value or not). 77 Turning to integer 1.3.3, TMA observed that debate before the primary judge centred on the words "based on". TMA contends that the primary judge's construction was again, an overly narrow one that did not reflect the breadth of the disclosure, and which impermissibly imported requirements that are not found in the claim language. Even on that narrow construction, TMA contends that, contrary to the primary judge's finding, integer 1.3.3 is present in the UbiPark Technology. The latter contention is discussed further under the third ground of appeal. 78 Integer 1.3.3 requires the determination of whether one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals. 79 TMA contends that it is sufficient for the purposes of integer 1.3.3 for the smartphone merely to use the RSSI "in some way" to determine whether a condition of entry to the carpark is satisfied. The nature of the relationship between the received signal strength and the entry criteria is not limited by the claim. According to TMA a comparison or calculation based on a measured value is not required. All that is required is that the received signal strength of the entry (or exit) signal be used as a criterion to determine whether the user is within a prescribed range of locations relative to the entry point of the carpark. If the received signal is of sufficient strength, whether or not the value of the signal is directly measured, (or indirectly via being decoded) the smartphone determines that that entry criterion has been satisfied. 80 TMA submits that the satisfaction of an entry criterion in this manner is based on the received signal strength of the entry (or exit) signal. As the parties' experts agreed, if an entry criterion is the receipt of an entry signal, then the entry criterion makes use of the received signal strength of the entry signal in some way: J[112]. According to TMA, the primary judge's reliance on the suggested purpose of the invention in support of his construction discloses error. The relevant question is not whether measuring the strength of an entry signal would be better from a practical perspective. The receipt of an entry signal is plainly still capable of meeting that objective, even if it is not as efficient or precise as the use of direct measurement of a numerical value. 81 Integer 1.3.3 expressly ties the determination of whether one or more entry criteria is satisfied to the received signal strength as the determination must be based on the received signal strength. We agree with the primary judge that integer 1.3.3 requires a comparison to be made between one or more entry criteria and the received signal strength of the entry signal measured by the smartphone, or some calculation undertaken based on that measured value. It is not sufficient that the smartphone uses the contents of the successfully decoded signal (via which TMA contends the signal strength was indirectly measured) to determine whether a condition of carpark entry is satisfied. The integer requires the determination of whether one or more entry criteria have been satisfied to be based on the received signal strength, not the contents of the signal that has been received. 82 We do not accept the construction advanced by TMA under this ground and accordingly, it must fail.

7.3 Appeal ground 2 - construction - integers 1.3.4 (and 1.3.9) 83 In the context of claim 1, an entry request is generated and transferred to the communication system "in response to" one or more entry criteria being satisfied. TMA challenges the primary judge's "narrow" construction that this integer requires that the entry (or exit) request be transferred automatically, without any user interaction with their smartphone, such as the pressing of a button. 84 The words of the claim are to be read in context. TMA submits that the relevant context includes those parts of the specification at [0021], [0060], [00108] and [00141], which describe embodiments of the invention which are not limited to a wholly automated system, and claim 10. TMA submits that claim 10, which adds a limitation that "the mobile communication device is configured to automatically transfer at least one of the entry request and the exit request without user interaction", provides powerful support for their construction of integer 1.3.4, which they noted was also consistent with that of the experts. 85 The primary judge acknowledged at J[137] that the "clear implication" from the existence of claim 10 was that claims 1 to 9 are not limited to the automatic transfer of an entry request and exit request; otherwise claim 10 would add nothing. His Honour concluded "[t]his strongly suggests that some form of user interaction is within the scope of claims 1 to 9". Despite acknowledging at J[138] the "strong contra-indicators", the primary judge concluded that the words "in response to" required a direct relationship between the satisfaction of one or more of the entry criteria (of 1.3.3) and the generation of the entry request. His Honour was unable to see how the words "in response to" could bear a broader meaning which permitted the inclusion of some other additional or intervening feature or step as part of the process. 86 The primary judge recognised at J[139] that his construction appeared to produce redundancy in respect of claim 10, and that it was inconsistent with the common views of the experts. However, his Honour considered that the factors weighing in support of his conclusion outweighed the potential redundancy. TMA submits that the collective weight of the experts' evidence, and the "strong contra-indicators" comprising a context in which the specification describes embodiments of the invention not limited to an automated system, and dependent claim 10 which specifically limits the claimed invention to an automatic transfer without user interaction, weighs strongly in favour of TMA's construction. 87 On TMA's construction, the integer is satisfied as long as one or more entry criteria is satisfied and an entry request is generated after that point, whether or not further steps, such as user intervention, are interposed between satisfaction of an entry criteria and generation of the entry request. In effect TMA's construction substitutes "as a consequence of" in place of "in response to". 88 A focus only on the words of integer 1.3.4 overlooks the elements of the larger system of which this integer is a part. The system has three components: the communication system, a computer program, and a mobile communication device. It must be recalled that according to integer 1.3, it is the mobile communication device that is configured to generate and transfer to the communication system, the entry request in response to one or more entry criteria being satisfied. On TMA's construction, the integer would also encompass the intervention of the user of the mobile communication device generating the entry request. 89 TMA relies on the asserted redundancy of claim 10 (dependent on any one of claims 1 to 9), which includes a limitation wherein the mobile communication device is configured to "automatically transfer" at least one of the entry request and the exit request without user interaction, as a factor supporting their construction. A claim is to be construed in the context of the specification as a whole - including all of the claims. Nevertheless, as the Full Court said in Davies v Lazer Safe Pty Ltd [2019] FCAFC 65 at [65] (per Greenwood, White and Burley JJ), if the plain meaning of a claim has the effect that one or more dependent claims are redundant, then the consequence of redundancy does not drive the construction of the claim itself. 90 We consider that the plain meaning of integer 1.3.4 is that if and when one or more entry criteria have been satisfied, the smartphone generates and sends the entry request, without further intervention or interposed steps. The plain meaning of the ordinary English words used in the integer must take primacy over the potential for redundancy of dependent claims and the views of the experts. We agree with the primary judge that the words "in response to" require a direct relationship between (a) the satisfaction of the one or more entry criteria in integer 1.3.3 and (b) the generation and transfer of the entry request, without the interposing of any additional steps. 91 Accordingly, this ground of appeal fails.

8. INFRINGEMENT 92 Both the Notice of Appeal and the Notice of Contention raised issues with the infringement findings.

8.1 Appeal ground 3 - infringement - integers 1.3.3 and 1.3.4 93 Given that we have upheld the primary judge's construction of integer 1.3.3, we need only consider that part of ground 3, whereby TMA challenges the primary judge's finding that integer 1.3.3 was absent from the UbiPark Technology. There was no equivalent contention in relation to integer 1.3.4. As we have upheld the primary judge's construction of integer 1.3.4, his Honour's finding that this integer is not present in the UbiPark Technology is not challenged on appeal.

8.1.1 Appeal ground 3(B) 94 At J[123], the primary judge summarised the relevant evidence. The UbiPark App: (a) constantly scans for new UUIDs that identify a new Bluetooth signal; (b) decodes the signal received from Bluetooth beacons to recognise that it is a new UUID signal; and (c) sends new UUID signals to the UbiPark servers. 95 The evidence of Mr Van De Camp as set out at J[118] was that a module within the UbiPark App provides the RSSI value for each Bluetooth signal received by the user's smartphone. The UbiPark App carries out a "closest lane" calculation based on the RSSI values of the signals that have been received from the Bluetooth beacons at the carpark. The primary judge observed at J[123(b)] that it was an implicit prerequisite to this calculation that the smartphone has received at least one signal for which there is an RSSI, and that in practice, that value will always be less than zero (as a result of the negative logarithmic scale). If the "closest lane" calculation cannot be performed the process will not continue. 96 The Min RSSI field, being another field in the "Lane Configuration Document" which sets out the way in which UbiPark configures groups of lanes in respect of several carparks, is left blank for all carparks and defaults to zero. The UbiPark Technology (the primary judge assumed, the App) performs a test of whether the measured value of the RSSI is equal to or greater than the Min RSSI as discussed at [55] above. 97 The primary judge concluded at J[123(e)] that the UbiPark Technology, as implemented in practice, does not involve a comparison between a predetermined minimum RSSI value (eg, -70 dBm) and a measured RSSI value to determine whether the measured value exceeds the stipulated minimum. 98 The primary judge found at J[129] that the ability of the smartphone to correctly decode the entry signal (while a necessary step in the process used by UbiPark's Technology) does not constitute determining the received signal strength of the entry signal; nor does it involve determining if one or more entry criteria have been satisfied based on the received signal strength. 99 The primary judge considered at J[130] that in relation to the UbiPark Technology, it was artificial to regard the existence of a value for RSSI as less than zero as an entry criterion. The UbiPark App uses an RSSI value (or values) to calculate which lane is the "closest lane". The UbiPark App carries out a calculation to determine the "closest lane" based on the RSSI values of the signals received from Bluetooth beacons at the carpark, or, as the primary judge expressed it, the calculation uses the RSSI value as a "closest lane" criterion rather than as an entry criterion. TMA submits that this characterisation involved error. 100 TMA submits that in the UbiPark App, the "closest lane" must be found for the entry (and exit) process to continue. If no beacon is found, the user of the UbiPark App will not be presented with an invitation to select their lane for entry. Determination of the "closest lane" depends on: (a) the receipt of entry signals of a sufficient strength for them to be correctly decoded; and (b) the determination of a non-zero RSSI value. 101 TMA contends that the satisfaction of the "closest lane" test is a necessary pre-condition or prerequisite to the continuation of the entry process. It is thus an entry criterion which must be met, and it is based on a calculated, non-zero RSSI value. If there is no measured RSSI value, no beacon is found and the entry process will not continue. The fact that the test of whether the measured RSSI value be greater than or equal to zero will never be passed is beside the point. The comparison of the measured RSSI value with the default Min RSSI (set at zero) must be made. It is a pre-condition for entry, and as such it is an entry criterion, and one which is satisfied based on the RSSI value of an entry signal received from a nearby beacon. 102 TMA further contends that integer 1.3.3 is present in the UbiPark Technology, even on the primary judge's construction. The determination of one or more entry criteria have been satisfied based on the received signal strength: a numerical RSSI value that passes a test which is conducted in the software to check that that RSSI value is less than zero. This test has to be passed in order for the process to move forward, and if it does not, the user will never be able to enter or exit the carpark. 103 The primary judge characterised the existence of a value for RSSI in this test as "merely a prerequisite to the conduct of a calculation directed to determine the closest lane", describing the calculation using the RSSI value as "a closest lane criterion rather than an entry criterion": J[130]. The primary judge noted at J[126] that he would be satisfied that integer 1.3.3 was present if the Min RSSI field was set to a predetermined negative number. In that case, the user's smartphone would be configured to determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals. 104 We do not see a relevant distinction between the "closest lane" calculation wherein the Min RSSI field is set to a predetermined minimum which must be exceeded, or the where the value must be above zero, but never will be. In both cases without the prerequisite being satisfied, the comparison step being undertaken using a measured RSSI value, there would be no entry, as the process would not continue. If no signal with a measurable RSSI value is received, the entry process will not begin. It is only when the determination of "closest lane" test is conducted, but inevitably failed, that the next step of the entry process - the steps relating to "Min Detection Secs", and "Max Detection Secs" which sets the maximum amount of time in seconds that the UbiPark App will wait before displaying a lane selection screen - is carried out and the lane selection message is displayed, then the user is able to enter (or exit) the carpark. 105 We consider that one entry criterion which is a necessary precondition for the entry process to progress is the receipt of a signal from the carpark beacon with a measurable RSSI value that can be entered in the "closest lane" test. Even though failure of this test will inevitably occur, without that step being undertaken, the user will not gain entry to the carpark. On that basis, we consider that integer 1.3.3 is present in the UbiPark Technology. 106 Accordingly, we find that TMA is successful in relation to ground 3B.

8.1.2 Appeal ground 3(C) 107 Consequent upon the primary judge's acceptance at J[126] that integer 1.3.3 would be present if the Min RSSI field was set to a predetermined negative number, as the user's smartphone would be configured to determine if one or more entry criteria have been satisfied based on the received signal strength of the one or more entry signals, TMA submits that it is clear on the primary judge's findings that the UbiPark Technology is capable of being configured in a manner which would include integer 1.3.3. This would occur where a negative value is specified in the Min RSSI field. Further, there is no restriction or impediment on UbiPark setting a predetermined negative number in the Min RSSI field for the UbiPark App. The evidence at trial was that this would simply involve specifying that numbers at the UbiPark server, which would not involve any change being made by a user of the UbiPark App and which would not involve any change to the underlying software for the UbiPark App. 108 TMA noted that there was no evidence that UbiPark removed the Min RSSI test from its technology. Nor had UbiPark undertaken not to set a predetermined negative value in the Min RSSI field. As a result, TMA contends that the UbiPark Technology is, and remains, capable of utilising a measured RSSI in a manner consistent with the primary judge's construction of integer 1.3.3. 109 Given our finding as to the presence of integer 1.3.3 in the existing UbiPark Technology, it is not necessary for us to consider the third element of TMA's third ground of appeal.

8.2 Appeal ground 4 - claims 4, 11 and 16 110 The fourth ground of appeal relating to the infringement of claim 4 was not pressed at the hearing. TMA observed that as claim 4 was dependent on claim 1 and the parties agreed that as there was no challenge to its validity, it was not necessary for the Court to determine the issues concerning claim 4. 111 TMA made brief written submissions in relation to claims 11 and 16 noting that if the Court accepted its construction of the disputed integers, it would follow that all of the integers of claim 1 are present in the UbiPark Technology. TMA asserts that given the common features of claims 11 and 16, the same applies to those claims. 112 UbiPark submits that TMA did not prove that the App per se had the integers of claim 11. UbiPark maintains that TMA advanced its case below by reference to how the App might be used in respect of a particular implementation or configuration of software located on servers in respect of each specific carpark, and in doing so, did not engage with the requirements of s 117(2) of the Act. Further, UbiPark contends that the same points arise in relation to claim 16, which is to a phone that has been configured to operate in a particular way. There was no evidence that UbiPark supplies phones to anyone. 113 In any event, given that we have upheld the primary judge's finding that the UbiPark Technology does not infringe claim 1, we consider that for the same reasons the primary judge's finding as to the non-infringement of claims 11 and 16 should remain undisturbed.

8.3 Infringement conclusion 114 Whilst TMA has succeeded in establishing that integer 1.3.3 is present in the UbiPark Technology, it has not been successful in its challenge to the primary judge's finding that integer 1.3.4 was not present. Accordingly, the primary judge's finding that the UbiPark Technology did not infringe claim 1 of the Patent is undisturbed.

8.4 Notice of Contention ground 1 - integer 1.3.5 - authorisation data 115 UbiPark contends that the specification describes "authorisation data" as being akin to, or functioning as, a "virtual ticket", and that to operate as such the "authorisation data" must include a unique element. UbiPark submits that, contrary to the primary judge's construction, a mere Boolean value (true/false) would not contain enough information to function as a virtual ticket, as it does not contain any unique element. 116 According to UbiPark, the unique element must be information that is unique for a specific parking session, even if it does not identify the user or their vehicle. Without a unique element, the "authorisation data" would not function as a virtual ticket as contemplated by the Patent (eg, [0062] and [0111]). The specification also contemplates the ability to transfer the "authorisation data" to a different user to let them remove the vehicle ([00118]) and the optional printing of a physical ticket. 117 Neither party contended that "authorisation data" was a term of art or had any special technical meaning. 118 According to UbiPark, the primary judge erred in concluding that the Boolean value was "indicative of the user" in the sense required by claim 1, which requires that the "authorisation data" be "indicative of the entity". 119 Properly construed we consider that the primary judge was correct to find that "authorisation data" is indicative of the fact that the access control system has granted the entity access to the restricted area or carpark. UbiPark's contention that the "authorisation data" must be "indicative of the entity" rather than indicative of the fact that the entity has been granted access, is not what the plain words of the integer require. At its simplest "authorisation data" indicative of entry being granted to a carpark encompasses a Boolean value indicating that access to enter the restricted area has been granted to the smartphone user, or holder of the virtual ticket. That is not to say in a more complex system that the authorisation data may well also include additional information such as information about the user, the vehicle or the time of entry to the carpark. 120 As we accept the primary judge's construction of "authorisation data", this ground of contention fails.

8.5 Notice of Contention ground 2 - integer 1.3.9 121 UbiPark contends that the primary judge ought to have construed "indicative of the authorisation data" in integer 1.3.9 as requiring that the "exit request" contain information that relates in some way to the "authorisation data" received by the mobile communication device during entry. Again, UbiPark submits that this requires some unique element linking the exit request to the entry request be exchanged. 122 Following from the reasons we discussed in relation to integer 1.3.5, we do not consider that this integer requires a unique element. The primary judge accepted the experts' agreed construction that an exit request is "indicative of the authorisation data" if the exit request corresponds in some way with the authorisation data received by the smartphone from the communication system during entry. That requirement can be met by the authorisation data being indicative of the entity being granted access to enter the restricted area. Accordingly, this ground of contention also fails.

9. THE ACL CASE 123 Under its fifth ground of appeal, TMA advanced that the primary judge erred in finding that UbiPark had not engaged in misleading or deceptive conduct in contravention of s 18 of the ACL, culminating from the earlier four grounds of appeal propounded by it. 124 Given our findings on the grounds of appeal and contention relating to construction and infringement, it is unnecessary to consider TMA's contentions in relation to the ACL case.

10. INDIRECT INFRINGEMENT 125 Under its third ground of contention, UbiPark asserts that the primary judge ought to have found that TMA did not plead or prove the necessary elements for either a direct or an indirect infringement case in respect of any of the four asserted claims. His Honour briefly noted at J[174], it was not necessary for him to consider this because TMA had not proven infringement in any event. Notwithstanding that result, UbiPark presses its contention that the primary judge ought to have considered and ruled upon these issues. 126 Given our conclusion affirming the primary judge's finding that the UbiPark Technology did not infringe claim 1 of the Patent, it is unnecessary for us to consider UbiPark's contention that TMA's pleaded case on infringement was insufficient to establish direct or indirect infringement.

11. CONCLUSION 127 While TMA has been successful in relation to appeal ground 3B, our findings overall on appeal have not disturbed the primary judge's findings below. TMA has failed to establish any other of its grounds of appeal. Similarly, UbiPark has also failed to establish any ground of contention advanced by it. 128 As such, the appeal ought to be dismissed with costs. I certify that the preceding one hundred and twenty-eight (128) numbered paragraphs are a true copy of the Reasons for Judgment of the Honourable Justices Nicholas, Rofe and O'Sullivan.